リリース ノート

  • [アーティクル]

更新日: 2015 年 6 月 19 日

適用先:Azure

このトピックでは、Microsoft Azure Active Directory Access Control (Access Control サービスまたは ACS とも呼ばれます) の各リリースの新機能について説明し、製品の各リリースが先行製品とどのように異なるかについて説明し、以前のリリースで記述されたコードに影響を与える可能性のある重大な変更について説明します。

  • 2015 年 3 月 – ACS 名前空間を Google OpenID Connect へ移行

  • 2014 年 6 月 – Google ID プロバイダー サポート

  • 2013 年 7 月の更新プログラムのリリース ノート

  • 2012 年 12 月の更新プログラムのリリース ノート

  • 2012 年 9 月の更新プログラムのリリース ノート

  • 2012 年 6 月の更新プログラムのリリース ノート

  • 2012 年 5 月の更新プログラムのリリース ノート

  • 2012 年 1 月の更新プログラムのリリース ノート

  • 2011 年 7 月の更新プログラムのリリース ノート

2015 年 3 月 – ACS 名前空間を Google OpenID Connect へ移行

ACS では、ACS 名前空間の所有者が Google ID プロバイダーの構成を OpenID 2.0 から OpenID Connect へ移行するときに利用できる機能が実装されました。 顧客は、2015 年 6 月 1 日までに ACS 名前空間を OpenID Connect へ移行し、OpenID Connect の識別子を使用するために、2017 年 1 月 1 日までにバックエンド コードを移行する必要があります。 それぞれの期限までに適切なアクションを実行できなければ、アプリケーションが中断されることになります。 詳細なガイダンスについては、「ACS 名前空間を Google OpenID Connectに移行する」を参照してください。

2014 年 6 月 – Google ID プロバイダー サポート

2014 年 5 月 19 日現在、新しい ACS 名前空間では ID プロバイダーとして Google を使用することはできません。 2014 年 5 月 19 日より前に Google を使用していた登録済みの ACS 名前空間には影響はありません。 この新しい制限が課せられるのは、Google が ACS の基礎となる OpenID 2.0 のサポートをしだいに減らし、新しいアプリケーションの登録を終了したためです。 Google を使用する既存の ACS 名前空間は、2015 年 4 月 20 日まで引き続き機能します。 アプリケーションで Google アカウントのサポートが必要な場合は、アプリケーションを直接登録することをお勧めします。

ユーザーが Google アカウントを使用して新しい ACS 名前空間にサインインしようとすると、HTTP 400 エラー ページにリダイレクトされます。

New ACS namespace and Google error

2013 年 7 月の更新プログラムのリリース ノート

すべてのユーザーに対して可用性とパフォーマンスを高めるために、ACS は名前空間ごとに 1 秒あたり 30 トークン要求の制限を実装しました。 名前空間が長期にわたりこの制限を越えた場合、ACS は一定期間その名前空間からのトークン要求を拒否し、HTTP 429 / ACS90055 "Too many requests" エラーを返します。 詳細については、「 ACS サービスの制限事項 」と 「ACS エラー コード」を参照してください。

2012 年 12 月の更新プログラムのリリース ノート

新機能

ACS の 2012 年 12 月の更新プログラムには、次の新機能が含まれています。

WS-Federation プロトコルを使用したフェデレーション シングル サインアウトのサポート

ACS を使用して、WS-Federation プロトコルを使用して ID プロバイダーとのシングル サインオン (SSO) を有効にする Web アプリケーションで、シングル サインアウト機能を利用できるようになりました。 ユーザーが Web アプリケーションからサインアウトすると、ACS は、ID プロバイダーからユーザーを自動的にサインアウトし、同じ ID プロバイダーを使用する他の証明書利用者アプリケーションからユーザーをサインアウトできます。

この機能は、Active Directory フェデレーション サービス (AD FS) 2.0 や Windows Live ID (Microsoft アカウント) など、WS-Federation ID プロバイダーに対して有効になります。 シングル サインアウトを有効にするために、ACS は、WS-Federation プロトコル エンドポイントに対して次のタスクを実行します。

  • ACS は ID プロバイダーからの wsignoutcleanup1.0 メッセージを認識し、 wsignoutcleanup1.0 メッセージを証明書利用者アプリケーションに送信して応答します。

  • ACS は証明書利用者アプリケーションから wsignout1.0 メッセージと wreply メッセージを認識し、 Wsignout1.0 メッセージを ID プロバイダーに送信し 、wsignoutcleanup1.0 メッセージを証明書利用者アプリケーションに送信することで応答します。

詳細については、「コード サンプル: ASP.NET MVC 4 with Federated Sign-out and passive Authentication for ASP.NET in WIF」を参照してください。

ACS 1.0 のサポート停止

アクセス制御サービス 1.0 のサポートは、アクセス制御サービス 1.0 からアクセス制御サービス 2.0 の移行のサポートを含め、このリリースで終了します。

新しい Azure 管理ポータルでAccess Control名前空間に移動する

新しい Azure 管理ポータル (https://manage.WindowsAzure.com) には、Access Control名前空間を作成および管理する、使い慣れた ACS 管理ポータルへのルートが含まれています。

ACS 管理ポータルに移動するには、

  1. Microsoft Azure管理ポータル (https://manage.WindowsAzure.com) に移動し、サインインし、[Active Directory] をクリックします。 (トラブルシューティングのヒント: "Active Directory" 項目が見つからないか、使用できません)

  2. Access Control名前空間をクリックし、[管理] をクリックします。

アクセス制御名前空間を作成するには、[新規] をクリックして [App サービス] をクリックし、[アクセス制御] をクリックしてから [簡易作成] をクリックします。 または、[アクセス制御名前空間]、[新規] を順にクリックします。

Microsoft Azure 管理ポータルでの ACS 管理タスクの詳細については、[Active Directory] をクリックし、[ヘルプ (?)] をクリックしてご覧ください。 または、[Active Directory]、[アクセス制御名前空間]、[ヘルプ] を順にクリックします。

サービス バスのAccess Control名前空間への移動

Service Bus名前空間を作成すると、ポータルによってサービス バスのAccess Control名前空間が自動的に作成されます。

サービス バスのAccess Control名前空間を構成して管理するには、次の手順を実行します。

  1. Azure 管理ポータルにログインします。

  2. [サービス バス] をクリックし、サービス バスを選択します。

  3. [アクセス キー] をクリックし、[ACS 管理ポータルを開く] をクリックします。

Access Control名前空間がサービス バスに関連付けられていることを確認するには、Access Control サービス ページの上部にあるサービス名前空間フィールドを参照してください。 名前空間名は、サービス バス名とサフィックス "-sb" で構成されます。

詳細については、「方法: Service BusのAccess Control名前空間を管理する」を参照してください。

WS-Federation ID プロバイダー キーを表示し、パスワードを非表示にする ACS 管理ポータルの拡張機能

このリリースには、ACS 2.0 管理ポータルでの証明書、キー、およびパスワードの表示と操作に関連する 1 組の拡張機能が含まれています。

  • 署名証明書を [WS-Federation ID プロバイダーの編集] セクションで表示可能 – 以前は、ID プロバイダーから発行されたトークンの書名を検証するために使用された WS-Federation メタデータからインポートされた証明書は、ACS 管理ポータルで表示できませんでした。 現在、[WS-Federation ID プロバイダーの編集] セクションに、有効期限やステータスを含め、インポートされた証明書に関する情報が表示されます。 これらの証明書は、今では、新しい [保存時に WS-Federation メタデータ URL からのデータを再インポートする] チェックボックスを使用して更新できます。

  • パスワードと対称署名キーが既定で非表示 – パスワードおよび対称キーが意図せず開示されるのを防ぐために、これらの値は現在、ポータル全体を通じて編集画面では既定で非表示となっています。 パスワードまたは対称キーの値を意図的に表示するには (たとえば、アプリケーションへのコピーを可能にするため)、[パスワードの表示] または [キーの表示] をクリックする必要があります。

Access Control名前空間を使用してディレクトリ テナントをフェデレーションする機能

Azure Active Directoryテナントは、Access Control名前空間の ID プロバイダーとして使用できるようになりました。 これにより、Web アプリケーションがディレクトリ テナントからの組織 ID と、Facebook、Google、Yahoo!、Microsoft アカウント、その他の OpenID プロバイダーなどのソーシャル プロバイダーからのコンシューマー ID の両方を受け入れるようにするなど、多くのシナリオが可能になります。 このシナリオを実装する方法の詳細な手順については、この記事「ACS 名前空間での ID プロバイダーとしてのAzure Active Directory テナントのプロビジョニング」を参照してください。

証明書利用者アプリケーションの SAML 2.0 プロトコル サポート (Developer Preview)

ACS は、現在、証明書利用者アプリケーションへのトークンの発行用として SAML 2.0 プロトコルをサポートしています。 SAML 2.0 プロトコルのサポート機能は開発者プレビューとしてリリースされています。つまり、SAML 2.0 プロトコル実装の詳細は変更される可能性があります。 詳細については、「開発者プレビュー: SAMLProtocol」を参照してください。

既知の問題

2012 年 12 月のMicrosoft Azure Active Directory Access Control (Access Control サービスまたは ACS とも呼ばれます) の更新プログラムでは、次の既知の問題が特定されました。

Azure Co-Administratorsでは、Access Control名前空間を管理できるようになりました。 ただし、既存の共同管理者を既存のAccess Control名前空間に反映するには、アクションが必要です。

2012 年 11 月の更新プログラムの前に、既定では、プライマリ Azure サービス管理者のみがサブスクリプションで作成された名前空間Access Control管理できるという問題を解決しました。 Azure 共同管理者がAccess Control名前空間の ACS 管理ポータルにアクセスしようとすると、次のいずれかの ACS エラー コードが表示されます。

  • ACS50000: トークンの発行中にエラーが発生しました。

  • ACS60000: 発行者 'uri:WindowsLiveID' を使用する証明書利用者のルールの処理中にエラーが発生しました

  • ACS60001: ルール処理中に出力要求が生成されませんでした。

この問題は、Azure サービス管理者または共同管理者によって作成された新しいAccess Control名前空間で解決されました。 ただし、修正前から既存の名前空間を使用しているお客様は、共同管理者データをそれらの名前空間に反映するために、次の回避策を実行する必要があります。

  1. サービス管理者またはアカウント管理者の資格情報を使用して、Azure portal (https://windows.azure.com/) にサインインします。

  2. 「Azure サブスクリプションのCo-Administratorsを追加および削除する方法 ()」のガイダンスを使用して、共同管理者を削除して再追加します。https://msdn.microsoft.com/library/windowsazure/gg456328.aspx

  3. Azure ポータルをサインアウトし、共同管理者の資格情報を使用して Azure ポータルにサインインします。 その後、Access Control名前空間を管理できるようになります。

2012 年 9 月の更新プログラムのリリース ノート

2012 年 9 月、Microsoft Azure Active Directory Access Control (Access Control サービスまたは ACS とも呼ばれます) は、次の変更を含む更新プログラムを受信しました。

ACS によって作成された WS-Federation メタデータで発行されたエンティティ ID は、現在、常に小文字である

Access Control名前空間によって発行されたWS-Federation メタデータの "entityID" 属性が常に小文字になりました。 以前のリリースでは、Azure ポータルで名前空間が作成されたときに入力された文字が使用されていました。 "entityID" 属性は証明書利用者アプリケーションにAccess Control名前空間を識別し、属性の例を次に示します。

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

この変更は、ACS 発行トークンのAccess Control名前空間の文字ケース (常に小文字) が証明書利用者によってインポートされたAccess Control名前空間の文字ケースと一致しない可能性のあるトークン検証の問題に対処するために必要でした。 Windows Identity Foundation を使用している証明書利用者には、大文字小文字の区別の問題による影響はありません。

ACS にアップロードされた X.509 証明書の公開キー サイズが 4096 ビットに制限された

ACS 管理ポータルまたは管理サービスを介してAccess Control名前空間にアップロードされたすべての X.509 証明書は、公開キー サイズが 4096 ビット以下である必要があります。 これには、トークンの署名、トークンの暗号化、トークンの暗号化解除に使用される証明書が含まれます。

Windows では、証明書の公開キーのサイズは、証明書 (.CER) ファイルを開くか、[詳細] タブをクリックして "公開キー" フィールドの値をチェックすることで確認できます。 セキュリティで保護された sha256RSA 署名アルゴリズムを使用する証明書では、公開キーは 2048 ビットです。

4096 ビットを超えるキーを持つ既存の証明書は、引き続き ACS で動作しますが、これらの証明書は、準拠している証明書と置き換えるまで、ACS で再度保存することはできません。

ACS が X.509 証明書を使用してトークンに署名する際の "プライマリ キー" 選択アルゴリズムへのマイナーな変更

ACS 管理ポータルおよび管理サービスには、トークン署名証明書の "プライマリにする" フィールドがあり、これが選択されている場合、ACS はその証明書を使用してトークンに署名します。 このリリースでは、構成済みのトークン署名証明書に [プライマリの作成] フィールドがチェックされていない場合、Access Control名前空間は、有効な最も早い開始日を持つ既存の非プライマリ トークン署名証明書を使用してトークンに署名します。 プライマリ証明書が存在するが、無効であるか期限切れの場合、ACS はプライマリ以外のトークン署名証明書を使用してトークンに署名しません。

JWT ベータ: グローバル名前空間証明書またはキーを使用して JWT トークンに署名するときの署名動作の変更

2012 年 6 月に JSON Web Token (JWT) 形式のサポート機能のベータ版がリリースされたときに、ACS は次の優先順位で、各証明書利用者アプリケーションに発行された各 JWT トークンに署名するためにどのキーを使用する必要があるかを判別していました。

  • 証明書利用者に割り当てられた対称署名キー (使用可能な場合)

  • 証明書利用者に割り当てられた X.509 署名証明書 (使用可能な場合)

  • Access Control名前空間に割り当てられた対称署名キー

  • Access Control名前空間に割り当てられた X.509 署名証明書

このリリースの時点では、JWT トークンの署名用に名前空間全体の対称キーはサポートされません。 以下に、JWT トークンに署名するための新しい優先順位を示します。

  • 証明書利用者に割り当てられた対称署名キー (使用可能な場合)

  • 証明書利用者に割り当てられた X.509 署名証明書 (使用可能な場合)

  • Access Control名前空間に割り当てられた X.509 署名証明書

2012 年 6 月の更新プログラムのリリース ノート

2012 年 6 月、ACS は次の新機能を含む更新プログラムを受け取っています。

JWT 形式が証明書利用者アプリケーションに対応 (ベータ版)

この更新プログラムでは、ACS での JSON Web トークン (JWT) BETA 形式のサポートが導入されています。 JWT は軽量の JSON でエンコードされたトークン形式であり、X.509 証明書または対称キーを使用して署名でき、ACS によって次のいずれかのプロトコルを介して証明書利用者アプリケーションに発行できます。

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

JWT トークン形式は、 ACS 管理ポータルの [証明書利用者アプリケーション] セクションで選択可能なオプションになり、 ACS 管理サービスを通じて構成することもできます。

JWT トークン形式の詳細については、 JSON Web トークンの仕様を参照してください。 JWT トークンの特長を示す ACS コード サンプルは間もなく公開予定です。

重要

JWT のサポートは ACS で "ベータ版" としてマークされています。つまり、JWT 実装のすべての詳細は変更される可能性があります。 開発者は、このトークン形式を試してみることをお勧めします。 ただし、動作が予告なく変更される可能性があるため、JWT は運用サービスでは使用しないでください。

2012 年 5 月の更新プログラムのリリース ノート

2012 年 5 月上旬、ACS は次の変更を含む更新プログラムを受け取いました。

管理サービスを介して公開されるエンティティ ID プロパティへの変更

ACS 管理サービスは、ACS Management Service API リファレンスの説明に従って、現在、サポートされている各エンティティの種類の ID プロパティを公開しています。 これらの ID プロパティは、ACS によって自動的に設定および管理されます。

このサービスの更新では、ACS は別のデータベース スキーマに移行されるため、管理サービスを介して公開されるこれらの ID はすべてのエンティティの種類に対して変更されます。

管理サービスを介して特定のエンティティをクエリするために、これらの ID にハードコードされた依存関係を格納または取り込むことはまれで、一般にお勧めしません。 代わりに、RelyingParty、ServiceIdentity、RuleGroup、Issuer のエンティティの種類では名前プロパティを使用してクエリし、他のエンティティの種類では親エンティティ ID (ルールの場合は RuleGroupId、ID プロバイダーの場合は IssuerId など) を使用してクエリすることをお勧めします。

ルール処理のためのデータベース照合順序の変更

国際言語のサポートを拡大し、セキュリティを強化するために、ACS のこのリリースでは、SQL_Latin1_General_CP1_CI_ASからLatin1_General_100_BIN2への入力要求の比較に使用される基になる SQL データベース照合順序が更新されます。 この変更により、ACS は追加の文字セットと文字セットの組み合わせをサポートできます。 複数の文字セットを使用した文字列を含む入力方向の要求に依存しているアプリケーションは、SQL_Latin1_General_CP1_CI_AS によってサポートされず、異なる要求や追加の要求をこの新しい照合順序の結果と見なす可能性があります。 この新機能の利用を希望するお客様は、お使いのアプリケーションに新しい SQL 照合順序との互換性があるか検証することをお勧めします。

2012 年 1 月の更新プログラムのリリース ノート

2012 年 1 月 25 日、ACS 2.0 は次の変更を含む更新プログラムを受信しました。

  • 失敗した認証要求への ACS エラー応答の変更

  • 失敗した認証要求に対する OAuth 2.0 エラー コードの変更

失敗した認証要求への ACS エラー応答の変更

以前のリリースでは、クライアントが存在しない発行者 (エラー コード: ACS50026) または正しくない資格情報 (エラー コード: ACS50006) で認証された場合、ACS は異なるエラー コードで応答しました。 以前は、これらのエラー コードは、クライアントが無効なサービス ID 名、または無効な ID プロバイダーから発行された SWT または SAML トークンを使用して認証を試みたときに作成されました。

ACS は、SWT、SAML、およびユーザー名/パスワードの場合に認証に失敗した場合に、それぞれエラー コード ACS50008、ACS50009、または ACS50012 を返します。 詳細については、以下の表を参照してください。

認証の応答 変更前 クリック後

存在しない発行者

ACS50026 IssuerNotFound

ACS50008 InvalidSwt、

ACS50009 InvalidSaml、OR

ACS50012 AuthenticationFailed

間違った資格情報

ACS50006 InvalidSignature

失敗した認証要求に対する OAuth 2.0 エラー コードの変更

また、以前のリリースでは、クライアントが存在しない発行者 (invalid_client) または正しくない資格情報 (invalid_grant) で認証されたときに、ACS は異なる OAuth 2.0 エラー コードで応答しました。 この動作も更新され、OAuth 2.0 要求の形式が正しくない場合、クライアントが認証に失敗した場合、または認証用に指定されたアサーションの形式が正しくないか無効である場合、invalid_client および認証コードの形式が正しくないか無効である場合にinvalid_grant、ACS はinvalid_requestを返します。 詳細については、以下の表を参照してください。

認証の応答 例 変更前 クリック後

存在しない発行者

invalid_client

invalid_client

間違った資格情報

SWT が正しくないキーで署名されています。クライアント ID と資格情報は、ACS で構成されているものと一致します。

invalid_grant

認証に失敗しました

対象ユーザー URI の検証に失敗しました。証明書の検証に失敗しました。サービス ID からのアサーションに自己署名付き要求が含まれています。

invalid_grant

間違った形式のアサーション

SWT に署名が見つかりません。SAML アサーションは有効な XML ではありません。

invalid_request

間違った形式の承認コード

invalid_grant

invalid_grant

無効な承認コード

invalid_grant

間違った形式の OAuth2 要求

invalid_request

invalid_request

2011 年 7 月の更新プログラムリリース ノート

ACS 2.0 の 2011 年 7 月の更新プログラムのリリース ノートには、次のものが含まれています。

  • 前提条件

  • 新機能

  • [変更点]

  • の既知の問題

  • 既知の問題

前提条件

すべてのAccess Control名前空間は、2011 年 7 月の更新プログラムを自動的に受け取ります。 この更新プログラムには、新規または既存のお客様の ACS 前提条件に対する変更は含まれています。 現在の ACS の前提条件の詳細については、「ACS の 前提条件」を参照してください。

新機能

ACS への 2011 年 7 月の更新プログラムには、次の新機能が含まれています。

1. ルールが最大 2 つの入力方向の要求をサポートする

ACS ルール エンジンでは、1 つの入力要求ではなく、最大 2 つの入力要求を構成できる新しい種類の規則がサポートされるようになりました。 2 つの入力方向の要求を処理するルールは、複雑なユーザー承認機能を実行するために必要なルールの総数を削減するために使用できます。

ACS 管理ポータルで、新しいルールで 2 つ目の入力要求を指定するには、ルール エディターで [ 2 つ目の入力要求を追加 ] をクリックします。 管理サービスでは、2 つの入力方向の要求を処理するルールは、ConditionalRule エンティティの種類を使用して構成できます。 1 つの入力方向の要求を処理するルールは、下位互換性を維持するために、引き続き Rule エンティティの種類を使用して構成できます。

2 つの入力要求を含むルールの詳細については、「 ルール グループとルール」を参照してください。

2. 11 言語でのローカライズ

ACS 管理ポータルと証明書利用者アプリケーション用の ACS ホスト型ログイン ページでは、英語、フランス語、ドイツ語、イタリア語、日本語、韓国語、ロシア語、スペイン語、ポルトガル語 (ブラジル)、簡体字中国語、繁体字中国語など、11 の言語でローカライズがサポートされるようになりました。 キーの実効日および有効期限を設定し表示するための代替日付形式を使用する [英語 (インターナショナル)] オプションも使用できます。 これらのユーザー インターフェイスに表示される記述言語は、次の 3 とおりの方法のいずれかで変更できます。

  • 言語セレクター – ACS 管理ポータルでは、ポータルの右上隅に表示される新しい言語セレクター メニューを使用して、表示される言語を即座に変更できます。

  • URL – ACS 管理ポータルに表示される言語は、要求 URL の末尾に "lang" パラメーターを追加することで変更できます。 このパラメーターに指定可能な値は、サポートされる言語に対応する ISO 639-1/3166 言語コードです。 値の例として、en、de、es、fr、it、ja、ko、ru、pt-br、zh-cn、zh-tw があります。 表示される言語をフランス語に設定するパラメーターを含む ACS 管理ポータル URL の例を次に示します。

    https://your-namespace.accesscontrol.windows.net/?lang=fr

  • Web ブラウザーの基本設定 – "lang" URL パラメーターまたは言語セレクターを使用して言語設定を設定したことがない場合、ACS 管理ポータルと ACS ホストログイン ページは、Web ブラウザー設定で設定された言語設定に基づいて表示する既定の言語を決定します。

[変更点]

以下は、このリリースで大きく変更されたサービスの動作です。

1. すべての OAuth 2.0 応答のエンコーディングは現在 UTF-8 である

ACS の最初のリリースでは、OAuth 2.0 エンドポイントからのすべての HTTP 応答の文字エンコード セットは US-ASCII でした。 2011 年 7 月の更新プログラムにより、現在、すべての HTTP 応答の文字エンコーディング UTF-8 に設定され、拡張文字セットがサポートされています。

既知の問題

以下は、このリリースでの既知の問題です。

ルール エディターが、ID プロバイダーに関連付けられていないカスタム発行者を表示できない

現在、ACS 管理ポータルのルール エディターでは、ID プロバイダーまたは ACS に関連付けられている要求発行者のみを表示できます。 ID プロバイダーまたは ACS のいずれにも対応していない発行者を参照するルールがロードされると、次のエラーが表示されます。

  • ACS80001: この規則は、管理ポータルでサポートされていない要求発行者の種類を使用するように構成されています。 管理サービスを使用して、このルールを表示および編集してください。

ACS に関連付けられている ID プロバイダーなしで発行者を存在できるシナリオは、次の 2 つあります。

  • OAuth 2.0 委任シナリオでは、ACS 管理サービスを使用してAccess Control名前空間に発行者レコードが作成され、この発行者には関連付けられた ID プロバイダーがありません。

  • 同じ名前のサービス ID を使用して ACS で認証しながら、OAuth WRAP プロトコルを介してトークン要求で要求をアサートする目的で発行者が作成された場合。

Quotas (クォータ)

このリリースの時点で、ACS では、特定のAccess Control名前空間に対して作成できる ID プロバイダー、証明書利用者アプリケーション、ルール グループ、ルール、サービス ID、要求の種類、委任レコード、発行者、キー、アドレスの数に制限は適用されません。

サービスの制限事項

サービスの制限の詳細については、「 ACS サービスの制限事項」を参照してください。