方法:Azure Access Control Service からの移行

Azure Active Directory (Azure AD) のサービスである Microsoft Azure Access Control (ACS) は、2018 年 11 月 7 日に終了する予定です。 現在 Access Control を使用しているアプリケーションとサービスは、それまでに別の認証メカニズムへと完全移行する必要があります。 この記事では、現在のお客様を対象に、Access Control の使用の廃止を計画する際の推奨事項を紹介します。 現在 Access Control を使用していない場合は、何もする必要はありません。

概要

Access Control は、Web アプリケーションや Web サービスにアクセスするユーザーの認証と承認を容易にする、クラウド認証サービスです。 これにより、認証や承認に関する多くの機能について、コーディングの必要がなくなります。 Access Control は主に、Microsoft .NET クライアント、ASP.NET Web アプリケーション、および Windows Communication Foundation (WCF) Web サービスの開発者や設計者によって使用されます。

Access Control のユース ケースは、主に次の 3 つのカテゴリに分けることができます。

• 特定の Microsoft クラウド サービス (Azure Service Bus、Dynamics CRM など) に対する認証。 クライアント アプリケーションは、Access Control から取得したトークンによってこれらのサービスに対する認証を受け、さまざまなアクションを実行します。
• Web アプリケーション (カスタムとパッケージ (SharePoint など) の両方) に対する認証の追加。 Web アプリケーションで Access Control の "パッシブ" 認証を使用すると、Microsoft アカウント (以前の Live ID) だけでなく、Google、Facebook、Yahoo、Azure AD、および Active Directory フェデレーション サービス (AD FS) のアカウントを使用してサインインできるようになります。
• Access Control によって発行されるトークンを使用したカスタム Web サービスのセキュリティ保護。 Web サービスで "アクティブ" 認証を使用すると、Access Control を使用して認証された既知のクライアントに対してのみ、アクセスを許可できるようになります。

これらの各ユース ケースと推奨される移行方法については、以下のセクションで説明します。

Access Control に含まれるコンポーネントを次に示します。

• セキュリティ トークン サービス (STS)。認証要求を受け取って、セキュリティ トークンを発行します。
• Azure クラシック ポータル。このポータルでは、Access Control 名前空間を作成したり、削除したり、有効/無効を切り替えることができます。
• 個別の Access Control 管理ポータル。このポータルでは、Access Control 名前空間のカスタマイズや構成を行うことができます。
• 管理サービス。ポータルの機能を自動化するために使用できます。
• トークン変換ルール エンジン。Access Control が発行するトークンの出力形式を操作する、複雑なロジックを定義できます。

これらのコンポーネントを使用するには、1 つ以上の Access Control 名前空間を作成する必要があります。 名前空間とは、アプリケーションやサービスと通信するために使用される、Access Control 専用のインスタンスのことです。 名前空間は、Access Control を使用するその他のすべてのお客様から分離されます。 他のお客様は、それぞれ独自の名前空間を使用します。 Access Control 名前空間には、次のような専用の URL が使用されます。

https://<mynamespace>.accesscontrol.windows.net

STS および管理操作とのすべての通信は、この URL で行われます。 目的ごとに、異なるパスを使用します。 アプリケーションやサービスが Access Control を使用しているかどうかを確認するには、 https://<名前空間>.accesscontrol.windows.net へのトラフィックを監視します。 この URL へのトラフィックは Access Control によって処理されるため、停止する必要があります。

これに対する例外は、https://accounts.accesscontrol.windows.net へのすべてのトラフィックです。 この URL へのトラフィックは既に他のサービスによって対処されており、Access Control の廃止の影響を受けません。

Access Control の詳細については、「Access Control Service 2.0」(アーカイブ) を参照してください。

影響を受けるアプリケーションを確認する

このセクションの手順に従って、どのアプリケーションが ACS の提供終了によって影響を受けるかを確認します。

ACS PowerShell をダウンロードしてインストールする

1. PowerShell ギャラリーに移動し、Acs.Namespaces をダウンロードします。

2. 次を実行してモジュールをインストールします

   Install-Module -Name Acs.Namespaces
   

3. 次を実行して、使用できるすべてのコマンドの一覧を取得します

   Get-Command -Module Acs.Namespaces
   

   特定のコマンドのヘルプを表示するには、次を実行します。

    Get-Help [Command-Name] -Full
   

   [Command-Name] は、ACS コマンドの名前です。

ACS 名前空間を一覧表示する

1. Connect-AcsAccount コマンドレットを使用して ACS に接続します。

   コマンドを実行する前に Set-ExecutionPolicy -ExecutionPolicy Bypass を実行し、コマンドを実行するためにそれらのサブスクリプションの管理者になっておくことが必要な場合があります。

2. Get-AcsSubscription コマンドレットを使用して、使用可能な Azure サブスクリプションを一覧表示します。

3. Get-AcsNamespace コマンドレットを使用して、ACS 名前空間を一覧表示します。

どのアプリケーションが影響を受けるかを確認する

1. 前の手順で取得した名前空間を使用して、https://<namespace>.accesscontrol.windows.net に移動します

   たとえば、名前空間の 1 つが contoso-test である場合は、https://contoso-test.accesscontrol.windows.net に移動します

2. [信頼関係] で、 [証明書利用者アプリケーション] を選択し、ACS の提供終了の影響を受けるアプリケーションの一覧を表示します。

3. その他に ACS 名前空間があれば、それらについて手順 1 ～ 2 を繰り返します。

提供終了のスケジュール

2017 年 11 月の時点では、すべての Access Control コンポーネントは完全にサポートされており、使用可能です。 ただし、Azure クラシック ポータルを使用して新しい Access Control 名前空間を作成することはできません。

Access Control コンポーネントの廃止スケジュールを次に示します。

• 2017 年 11 月: Azure クラシック ポータルでの Azure AD 管理エクスペリエンスの提供は終了します。 この時点で、Access Control の名前空間の管理は、新しい専用の URL https://manage.windowsazure.com?restoreClassic=true で利用できるようになります。 この URl を使用すれば、既存の名前空間を表示したり、名前空間を有効または無効にしたり、名前空間を削除することができます。
• 2018 年 4 月 2 日: Azure クラシック ポータルは完全に廃止され、Access Control の名前空間管理はすべての URL で使用できなくなります。 これ以降、Access Control 名前空間を有効または無効にしたり、削除したり、列挙することはできなくなります。 ただし、Access Control 管理ポータルはその機能を完全に維持され、https://<namespace>.accesscontrol.windows.net に配置されます。 その他の Access Control コンポーネントもすべて、引き続き正常に動作します。
• 2018 年 11 月 7 日: すべての Access Control コンポーネントが完全にシャットダウンされます。 これには、Access Control 管理ポータル、管理サービス、STS、およびトークン変換ルール エンジンが含まれます。 この時点では、(<namespace>.accesscontrol.windows.net にある) ACS に送信されるすべての要求は失敗します。 この時点までに、すべての既存アプリケーションとサービスを他のテクノロジへと移行しておく必要があります。

移行方法

次のセクションでは、Access Control から他の Microsoft テクノロジに移行する際の推奨事項の概要を示します。

Microsoft クラウド サービスのクライアント

Access Control によって発行されたトークンを受け入れる各 Microsoft クラウド サービスでは、少なくとも 1 つの代替認証形式がサポートされています。 使用できる認証メカニズムは、サービスごとに異なります。 各サービスの固有のドキュメントで、公式のガイダンスを参照することをお勧めします。 ここでは簡単に、各ドキュメントのセットを示します。

SharePoint のユーザー

SharePoint 2013、2016、SharePoint Online のユーザーは、クラウド、オンプレミス、およびハイブリッドのシナリオでの認証のために長い間 ACS を使ってきました。 SharePoint の一部の機能とユース ケースは ACS 提供終了の影響を受けますが、それ以外には影響ありません。 次の表は、ACS を利用する最も一般的な SharePoint 機能の一部に対する移行のガイダンスをまとめたものです。

パッシブ認証を使用する Web アプリケーション

ユーザー認証に Access Control を使用してる Web アプリケーションを考慮し、Access Control では、Web アプリケーションの開発者や設計者向けに次の機能が提供されています。

• Windows Identity Foundation (WIF) との緊密な統合
• Google、Facebook、Yahoo、Azure Active Directory、AD FS アカウント、および Microsoft アカウント とのフェデレーション。
• 次の認証プロトコルのサポート: OAuth 2.0 Draft 13、WS-Trust、Web Services Federation (WS-Federation)。
• 次のトークン形式のサポート: JSON Web トークン (JWT)、SAML 1.1、SAML 2.0、Simple Web Token (SWT)。
• ホーム領域検出のエクスペリエンス (WIF に統合)。サインインに使用するアカウントの種類を選択できます。 このエクスペリエンスは Web アプリケーションによってホストされ、完全にカスタマイズ可能です。
• トークン変換。Web アプリケーションが Access Control から受け取った要求の豊富なカスタマイズが可能です。これには次のようなものがあります。
  • ID プロバイダーからの要求をパススルー。
  • その他のカスタム要求の追加。
  • 特定の条件下で要求を発行する単純な if-then ロジック。

残念ながら、これらに匹敵するすべての機能を提供する単一のサービスはありません。 必要な Access Control の機能を評価して、Microsoft Entra ID、Azure Active Directory B2C (Azure AD B2C)、または他のクラウド認証サービスのいずれを使用するかを検討する必要があります。

Microsoft Entra ID に移行する

候補となる経路として、アプリケーションとサービスの Microsoft Entra ID との直接統合があります。 Microsoft Entra ID は、Microsoft の職場または学校アカウントに対応した、クラウド ベースの ID プロバイダーです。 Microsoft Entra IDは、Microsoft 365、Azure などに対応した ID プロバイダーです。 これは、Access Control と同様のフェデレーション認証機能を提供しますが、一部の Access Control の機能をサポートしていません。

主な例は、Facebook、Google、Yahoo などのソーシャル ID プロバイダーとのフェデレーションです。 ユーザーがこの種類の資格情報でサインインする場合、Microsoft Entra ID はソリューションとして適しません。

また、Microsoft Entra ID では Access Control とまったく同じ認証プロトコルがサポートされるとは限りません。 たとえば、OAuth は Access Control と Microsoft Entra ID の両方でサポートされていますが、各実装間で微妙な違いがあります。 移行に際しては、実装ごとにコードを変更する必要があります。

ただし、Microsoft Entra ID には Access Control のお客様にとっての潜在的な利点がいくつかあります。 たとえば、クラウドでホストされる、Microsoft の職場または学校のアカウント (Access Control のお客様によって広く使用されているアカウント) がネイティブにサポートされます。

Microsoft Entra テナントは、AD FS を通じて、1 つ以上のオンプレミス Active Directory インスタンスにフェデレーションすることもできます。 そのため、クラウド ベースのユーザーだけでなく、オンプレミスでホストされているユーザーもアプリで認証することができます。 また、WS-Federation プロトコルにも対応しています。これにより、WIF を使用して、Web アプリケーションと比較的簡単に統合できます。

次の表は、Web アプリケーションに関連する Access Control の機能を、Microsoft Entra ID で利用できる機能と比較したものです。

大まかに言うと、ユーザーのサインインに Microsoft の職場または学校アカウントだけを使用するのであれば、おそらく Microsoft Entra ID が移行に最適な選択肢です。

Microsoft Entra ID がアプリケーションとサービスの最善の移行経路であると判断した場合は、アプリを Microsoft Entra ID と統合する 2 つの方法を認識する必要があります。

WS-Federation または WIF を使用して Microsoft Entra ID と統合する場合は、「ギャラリー以外のアプリケーションのフェデレーション シングル サインオンを構成する方法」で説明されているアプローチに従うことをお勧めします。 この記事は、Microsoft Entra ID を SAML ベースのシングル サインオン用に構成する方法を説明したものですが、WS-Federation の構成にも使用できます。 この方法に従うには、Microsoft Entra ID P1 または P2 ライセンスが必要です。 このアプローチには 2 つの利点があります。

• Microsoft Entra トークン カスタマイズの柔軟性をフルに活用できます。 Microsoft Entra ID によって発行された要求を、Access Control によって発行された要求と一致するようにカスタマイズすることができます。 これは、ユーザー ID や名前識別子要求に特に便利です。 テクノロジが変更された後もユーザー ID の一貫性が維持されるようにするには、Microsoft Entra ID によって発行されたユーザー ID を、Access Control によって発行されたユーザー ID と一致させる必要があります。
• アプリケーション固有のトークン署名証明書を構成し、その有効期間を制御できます。

もう 1 つのアプローチは、こちらのコード サンプルに従う方法です。この方法では、WS-Federation の設定方法の手順が若干異なります。 このコード サンプルでは、WIF を使用せず、代わりに ASP.NET 4.5 OWIN ミドルウェアを使用します。 ただし、アプリ登録の手順は、WIF を使用するアプリに対しても有効であり、 Microsoft Entra ID P1 または P2 ライセンスは必要ありません。

このアプローチを選ぶ場合は、Microsoft Entra ID での署名キー ロールオーバーについて理解する必要があります。 このアプローチでは、Microsoft Entra のグローバル署名キーを使用してトークンを発行します。 既定では、WIF は署名キーを自動的に更新しません。 Microsoft Entra ID がそのグローバル署名キーを回転する場合、変更を確定するために WIF 実装を準備する必要があります。 詳細については、「Microsoft Entra ID の署名キーのロールオーバーに関する重要な情報」を参照してください。

OpenID Connect または OAuth プロトコル経由で Microsoft Entra ID と統合できる場合は、その方法で統合することをお勧めします。 Microsoft Entra ID を Web アプリケーションに統合する方法については、Microsoft Entra ID 開発者ガイドにさまざまなドキュメントとガイダンスが記載されています。

Azure Active Directory B2C への移行

検討すべきその他の移行パスは、Azure AD B2C です。 Azure AD B2C はクラウド認証サービスです。Access Control と同様、開発者は認証と ID 管理のロジックをクラウド サービスに外部委託できます。 これは、最大数百万人ものアクティブ ユーザーを抱えることがあるコンシューマー向けアプリケーション用に設計された、有料サービスです (Free レベルと Premium レベルがあります)。

Azure AD B2C の最も魅力的な機能の 1 つは、Access Control と同様、さまざまな種類のアカウントをサポートできることです。 Azure AD B2C では、Microsoft アカウントや、Facebook、Google、LinkedIn、GitHub、Yahoo アカウントなどを使用して、ユーザーをサインインさせることができます。 さらに Azure AD B2C では、"ローカル アカウント"、つまりユーザーがアプリケーション専用に作成するユーザー名とパスワードもサポートされます。 Azure AD B2C には、サインイン フローのカスタマイズに使用できる豊富な機能拡張も用意されています。

ただし、Azure AD B2C では、Access Control のお客様が必要とする可能性がある、広範な認証プロトコルやトークン形式はサポートされません。 また、Azure AD B2C では、トークンを取得したり、ユーザーに関する追加情報を ID プロバイダーや Microsoft などにクエリしたりすることもできません。

次の表は、Web アプリケーションに関連する Access Control の機能を、Azure AD B2C で利用できる機能と比較したものです。 大まかに言えば、おそらく Azure AD B2C は、アプリケーションがコンシューマー向けの場合、またはさまざまな種類のアカウントをサポートする場合の移行に適した選択肢です。

Azure AD B2C がアプリケーションとサービスの最善の移行経路であると判断した場合は、次のリソースで開始してください。

• Azure AD B2C ドキュメント
• Azure AD B2C カスタム ポリシー
• Azure AD B2C の価格

Ping Identity または Auth0 への移行

場合によっては、Web アプリケーションの Access Control を Microsoft Entra ID や Azure AD B2C に置き換えるために、大量のコード変更が必要になることがあります。 たとえば、次のような場合です。

• Web アプリケーションで、Google や Facebook などのソーシャル ID プロバイダーにサインインするために、WIF または WS-Federation を使用してしている。
• Web アプリケーションで、WS-Federation プロトコルを使用して、エンタープライズ ID プロバイダーへの直接フェデレーションを実行している。
• Web アプリケーションで、Access Control によって発行されたトークン内の要求として、ソーシャル ID プロバイダー (Google や Facebook など) によって発行されたアクセス トークンが必要である。
• Web アプリケーションで、Microsoft Entra ID や Azure AD B2C では再現できない複雑なトークン変換を使用している。
• マルチテナントの Web アプリケーションで、多数の ID プロバイダーへのフェデレーションを一元管理するために、ACS を使用している

以上のような場合には、Web アプリケーションを別のクラウド認証サービスに移行することを検討してください。 次のオプションを検討することをお勧めします。 これらのオプションでは、Access Control と同様の機能が提供されます。

Auth0 は柔軟なクラウド ID サービスで、Access Control のお客様向けの高レベルな移行ガイダンスが作成されているほか、ACS で提供される機能がほぼすべてサポートされます。

Ping Identity では、ACS によく似た 2 つのソリューションが提供されます。 PingOne は、ACS と同じ機能を多数サポートしているクラウド ID サービスであり、PingFederate は、より高度な柔軟性を提供する、類似のオンプレミス ID 製品です。 これらの製品の使用の詳細については、ACS の提供終了に関する Ping のガイダンスを参照してください。

Microsoft では、Access Control を使用するすべてのお客様に、アプリやサービスの最適な移行経路を提供し、Access Control の移行に伴う作業を最小限に抑えていただく目的で、Ping Identity および Auth0 と連携しています。

アクティブな認証を使用する Web サービス

Access Control によって発行されたトークンでセキュリティ保護された Web サービスに対して、Access Control は次の機能を提供しています。

• 1 つ以上のサービス ID を Access Control 名前空間に登録する機能。 サービス ID は、トークンを要求するために使用できます。
• 次の種類の資格情報を使用してトークンを要求するための OAuth WRAP および OAuth 2.0 Draft 13 プロトコルのサポート。
  • サービス ID に対して作成されるシンプルなパスワード
  • 対称キーまたは X509 証明書を使用した署名付き SWT
  • 信頼できる ID プロバイダー (通常は AD FS インスタンス) によって発行された SAML トークン
• 次のトークン形式のサポート: JWT、SAML 1.1、SAML 2.0、SWT。
• シンプルなトークン変換ルール。

Access Control のサービス ID は、通常はサーバー対サーバー認証の実装に使用されます。

Microsoft Entra ID に移行する

この種類の認証フローに対する推奨事項は、Microsoft Entra ID に移行することです。 Microsoft Entra ID は、Microsoft の職場または学校アカウントに対応した、クラウド ベースの ID プロバイダーです。 Microsoft Entra IDは、Microsoft 365、Azure などに対応した ID プロバイダーです。

OAuth クライアント資格情報の付与の Microsoft Entra 実装を使用して、Microsoft Entra ID をサーバー対サーバー認証に使用することもできます。 次の表は、サーバー対サーバー認証での Access Control の機能を、Microsoft Entra ID で使用可能な機能と比較したものです。

サーバー対サーバーのシナリオの実装のガイダンスについては、次のリソースをご覧ください。

• Microsoft Entra 開発者ガイド の「サービス間」セクション
• シンプルなパスワード クライアント資格情報を使用したデーモン コード サンプル
• 証明書クライアント資格情報を使用したデーモン コード サンプル

Ping Identity または Auth0 への移行

場合によっては、Access Control を Microsoft Entra クライアント資格情報や OAuth の付与の実装へと移行するために、大量のコード変更が必要になることがあります。 たとえば、次のような場合です。

• サーバー対サーバー認証で、JWT 以外のトークン形式を使用している。
• サーバー対サーバー認証で、外部の ID プロバイダーから提供される入力トークンを使用している。
• サーバー対サーバー認証で、Microsoft Entra ID では再現できないトークン変換ルールを使用している。

以上のような場合には、Web アプリケーションを別のクラウド認証サービスに移行することを検討してください。 次のオプションを検討することをお勧めします。 これらのオプションでは、Access Control と同様の機能が提供されます。

Auth0 は柔軟なクラウド ID サービスで、Access Control のお客様向けの高レベルな移行ガイダンスが作成されているほか、ACS で提供される機能がほぼすべてサポートされます。

Ping Identity では ACS に似た 2 つのソリューションを提供しています。 PingOne は、ACS と同じ機能を多数サポートしているクラウド ID サービスであり、PingFederate は、より高度な柔軟性を提供する、類似のオンプレミス ID 製品です。 これらの製品の使用の詳細については、ACS の提供終了に関する Ping のガイダンスを参照してください。

Microsoft では、Access Control を使用するすべてのお客様に、アプリやサービスの最適な移行経路を提供し、Access Control の移行に伴う作業を最小限に抑えていただく目的で、Ping Identity および Auth0 と連携しています。

パススルー認証

任意のトークン変換によるパススルー認証の場合、ACS に相当する Microsoft のテクノロジはありません。 お客様がそれを必要としている場合は、Auth0 が最も近い類似のソリューションを提供しています。

質問、懸念事項、フィードバック

Microsoft では、Access Control のお客様の多くがこの記事を読んでも明確な移行パスを見つけられず、 適切なプランの決定において支援やガイダンスを必要とする可能性があることを認識しています。 移行シナリオと質問について話し合いをご希望の場合は、このページにコメントを残してください。