警告
このコンテンツは、以前の Azure AD v1.0 エンドポイント用です。 新しいプロジェクトには Microsoft ID プラットフォームを使用します。
Azure Active Directory (Azure AD) のサービスである Microsoft Azure Access Control Service (ACS) は、2018 年 11 月 7 日に廃止されます。 アクセス制御を現在使用しているアプリケーションとサービスは、それまでに別の認証メカニズムに完全に移行する必要があります。 この記事では、Access Control の使用を廃止する予定の現在の顧客に対する推奨事項について説明します。 現在アクセス制御を使用していない場合は、何も行う必要はありません。
概要
Access Control は、Web アプリケーションとサービスにアクセスするためにユーザーを認証および承認する簡単な方法を提供するクラウド認証サービスです。 これにより、認証と承認の多くの機能をコードから除外できます。 Access Control は主に、Microsoft .NET クライアント、ASP.NET Web アプリケーション、および Windows Communication Foundation (WCF) Web サービスの開発者やアーキテクトによって使用されます。
アクセス制御のユース ケースは、次の 3 つの主要なカテゴリに分類できます。
- Azure Service Bus や Dynamics CRM など、特定の Microsoft クラウド サービスに対する認証。 クライアント アプリケーションは、Access Control からトークンを取得して、これらのサービスに対して認証を行い、さまざまなアクションを実行します。
- カスタムと事前パッケージの両方 (SharePoint など) の Web アプリケーションに認証を追加する。 Access Control の "パッシブ" 認証を使用すると、Web アプリケーションは Microsoft アカウント (以前の Live ID) と、Google、Facebook、Yahoo、Azure AD、Active Directory フェデレーション サービス (AD FS) のアカウントを使用したサインインをサポートできます。
- Access Control によって発行されたトークンを使用したカスタム Web サービスのセキュリティ保護。 "アクティブ" 認証を使用することで、Web サービスは、アクセス制御で認証された既知のクライアントへのアクセスのみを許可できます。
これらの各ユース ケースと推奨される移行戦略については、次のセクションで説明します。
警告
ほとんどの場合、既存のアプリとサービスを新しいテクノロジに移行するには、大幅なコード変更が必要です。 潜在的な停止やダウンタイムを回避するために、移行の計画と実行を直ちに開始することをお勧めします。
Access Control には、次のコンポーネントがあります。
- 認証要求を受け取り、その代わりにセキュリティ トークンを発行するセキュリティ トークン サービス (STS)。
- Azure クラシック ポータル。Access Control 名前空間を作成、削除、および有効化および無効化します。
- Access Control 名前空間をカスタマイズして構成する、別の Access Control 管理ポータル。
- 管理サービス。ポータルの機能を自動化するために使用できます。
- トークン変換ルール エンジン。Access Control が発行するトークンの出力形式を操作するための複雑なロジックを定義するために使用できます。
これらのコンポーネントを使用するには、1 つ以上の Access Control 名前空間を作成する必要があります。 名前空間は、アプリケーションとサービスが通信する Access Control の専用インスタンスです。 名前空間は、他のすべての Access Control のお客様から分離されています。 他の Access Control のお客様は、独自の名前空間を使用します。 Access Control の名前空間には、次のような専用 URL があります。
https://<mynamespace>.accesscontrol.windows.net
STS と管理操作との通信はすべて、この URL で行われます。 目的ごとに異なるパスを使用します。 アプリケーションまたはサービスがアクセス制御を使用しているかどうかを判断するには、https://<namespace>.accesscontrol.windows.net へのトラフィックを監視します。 この URL へのトラフィックは Access Control によって処理されるため、中止する必要があります。
例外は、 https://accounts.accesscontrol.windows.netへのトラフィックです。 この URL へのトラフィックは別のサービスによって既に処理されており、Access Control の非推奨の影響を受 けません 。
アクセス制御の詳細については、「 Access Control Service 2.0 (アーカイブ済み)」を参照してください。
影響を受けるアプリを確認する
このセクションの手順に従って、ACS の提供終了の影響を受けるアプリを確認します。
ACS PowerShell をダウンロードしてインストールする
PowerShell ギャラリーに移動し、 Acs.Namespaces をダウンロードします。
を実行してモジュールをインストールする
Install-Module -Name Acs.Namespacesを実行して、使用可能なすべてのコマンドの一覧を取得します。
Get-Command -Module Acs.Namespaces特定のコマンドに関するヘルプを表示するには、次のコマンドを実行します。
Get-Help [Command-Name] -Fullここで、
[Command-Name]は ACS コマンドの名前です。
ACS 名前空間を一覧表示する
Connect-AcsAccount コマンドレットを使用して ACS に接続します。
コマンドを実行する前に、
Set-ExecutionPolicy -ExecutionPolicy Bypassを実行し、それらのサブスクリプションの管理者としてコマンドを実行することが必要になる場合があります。Get-AcsSubscription コマンドレットを使用して、使用可能な Azure サブスクリプションを一覧表示します。
Get-AcsNamespace コマンドレットを使用して ACS 名前空間を一覧表示します。
影響を受けるアプリケーションを確認する
前の手順の名前空間を使用して、
https://<namespace>.accesscontrol.windows.netに移動してください。たとえば、名前空間の 1 つが contoso-test の場合は、
https://contoso-test.accesscontrol.windows.net[ 信頼関係] で、[ 証明書利用者アプリケーション ] を選択して、ACS の提供終了の影響を受けるアプリの一覧を表示します。
その他の ACS 名前空間に対して手順 1 から 2 を繰り返します。
引退スケジュール
2017 年 11 月の時点で、すべての Access Control コンポーネントが完全にサポートされ、動作しています。 唯一の制限は、 Azure クラシック ポータルを使用して新しい Access Control 名前空間を作成できないことです。
Access Control コンポーネントを非推奨にするためのスケジュールを次に示します。
-
2017 年 11 月: Azure クラシック ポータルでの Azure AD 管理者エクスペリエンス は廃止されました。 この時点で、アクセス制御の名前空間管理は、新しい専用 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 管理ポータル、管理サービス、STS、トークン変換規則エンジンが含まれます。 この時点で、(
<namespace>.accesscontrol.windows.netにある) アクセス制御に送信された要求はすべて失敗します。 この時点より前に、既存のすべてのアプリとサービスを他のテクノロジに移行しておく必要があります。
注
ポリシーは、一定期間トークンを要求していない名前空間を無効にします。 2018 年 9 月上旬の時点では、この期間は現在 14 日間非アクティブですが、今後数週間で非アクティブ状態の 7 日間に短縮されます。 現在無効になっている Access Control 名前空間がある場合は、 ACS PowerShell をダウンロードしてインストール し、名前空間を再度有効にすることができます。
移行戦略
以降のセクションでは、Access Control から他の Microsoft テクノロジに移行するための大まかな推奨事項について説明します。
Microsoft クラウド サービスのクライアント
Access Control によって発行されたトークンを受け入れる各 Microsoft クラウド サービスで、少なくとも 1 つの代替形式の認証がサポートされるようになりました。 正しい認証メカニズムは、サービスごとに異なります。 公式のガイダンスについては、各サービスの特定のドキュメントを参照することをお勧めします。 便宜上、ドキュメントの各セットを次に示します。
| サービス | 指導 |
|---|---|
| Azure Service Bus（アジュール サービス バス） | Shared Access Signature に移行する |
| Azure Service Bus Relay | Shared Access Signature に移行する |
| Azure マネージド キャッシュ | Azure Cache for Redis への移行 |
| Azure DataMarket | Azure AI サービス API に移行する |
| BizTalk Services | Azure App Service の Logic Apps 機能に移行する |
| Azure Media Services | Azure AD 認証に移行する |
| Azure Backup | Azure Backup エージェントをアップグレードする |
SharePoint のお客様
SharePoint 2013、2016、および SharePoint Online のお客様は、クラウド、オンプレミス、ハイブリッドのシナリオで認証目的で ACS を長い間使用してきました。 一部の SharePoint 機能とユース ケースは ACS の提供終了の影響を受けますが、それ以外の機能は影響を受けなくなります。 次の表は、ACS を利用する最も一般的な SharePoint 機能の移行ガイダンスをまとめたものです。
| 特徴 | 指導 |
|---|---|
| Azure AD からのユーザーの認証 | 以前は、Azure AD では認証に SharePoint に必要な SAML 1.1 トークンがサポートされておらず、ACS は SharePoint と Azure AD トークン形式の互換性を持つ中継局として使用されていました。 これで、 Azure AD アプリ ギャラリーの SharePoint オンプレミス アプリを使用して、SharePoint を Azure AD に直接接続できるようになりました。 |
| オンプレミスの SharePoint でのアプリ認証とサーバー間認証 | ACS の提供終了の影響を受けません。変更は必要ありません。 |
| SharePoint アドインの低信頼承認 (プロバイダーホスト型および SharePoint ホスト型) | ACS の提供終了の影響を受けません。変更は必要ありません。 |
| SharePoint クラウド ハイブリッド検索 | ACS の提供終了の影響を受けません。変更は必要ありません。 |
パッシブ認証を使用する 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 サービス フェデレーション (WS-Federation)。
- 次のトークン形式のサポート: JSON Web トークン (JWT)、SAML 1.1、SAML 2.0、Simple Web Token (SWT)。
- WIF に統合されたホーム領域検出エクスペリエンス。これにより、ユーザーはサインインに使用するアカウントの種類を選択できます。 このエクスペリエンスは Web アプリケーションによってホストされ、完全にカスタマイズ可能です。
- Access Control から Web アプリケーションが受け取る要求の高度なカスタマイズを可能にするトークン変換。
- ID プロバイダーからのクレームを通過させます。
- 追加のカスタム要求を追加する。
- 特定の条件下で要求を発行する単純な if-then ロジック。
残念ながら、これらすべての同等の機能を提供するサービスは 1 つではありません。 必要なアクセス制御の機能を評価し、 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 とまったく同じ認証プロトコルが必ずしもサポートされるとは限りません。 たとえば、Access Control と Microsoft Entra ID の両方で OAuth がサポートされていますが、各実装には微妙な違いがあります。 実装が異なると、移行の一環としてコードを変更する必要があります。
ただし、Microsoft Entra ID は、Access Control のお客様にいくつかの潜在的な利点を提供します。 クラウドでホストされている Microsoft の職場または学校アカウントがネイティブでサポートされています。これは、Access Control のお客様が一般的に使用します。
Microsoft Entra テナントは、AD FS 経由でオンプレミス Active Directory の 1 つ以上のインスタンスにフェデレーションすることもできます。 これにより、アプリは、オンプレミスでホストされているクラウドベースのユーザーとユーザーを認証できます。 また、WS-Federation プロトコルもサポートされているため、WIF を使用して Web アプリケーションと比較的簡単に統合できます。
次の表は、Web アプリケーションに関連する Access Control の機能と、Microsoft Entra ID で使用できる機能を比較しています。
ユーザー が Microsoft の職場または学校アカウントでのみサインインできるようにする場合は、大まかに言えば、Microsoft Entra ID が移行に最適な選択肢です。
| 能力 | アクセス制御のサポート | Microsoft Entra ID のサポート |
|---|---|---|
| アカウントの種類 | ||
| Microsoft の職場または学校アカウント | サポートされています | サポートされています |
| Windows Server Active Directory と AD FS のアカウント | - Microsoft Entra テナントとのフェデレーションを介してサポートされます - AD FS との直接フェデレーションを介してサポートされます |
Microsoft Entra テナントとのフェデレーションによってのみサポートされます |
| 他のエンタープライズ ID 管理システムのアカウント | - Microsoft Entra テナントとのフェデレーションを介して可能 - 直接フェデレーションを介してサポートされます |
Microsoft Entra テナントとのフェデレーションを介して可能 |
| 個人用の Microsoft アカウント | サポートされています | Microsoft Entra v2.0 OAuth プロトコルを介してサポートされますが、他のプロトコルではサポートされません |
| Facebook、Google、Yahoo アカウント | サポートされています | 一切サポートされていません |
| プロトコルと SDK の互換性 | ||
| WIF | サポートされています | サポートされていますが、使用できる手順は限られています |
| WS-Federation | サポートされています | サポートされています |
| OAuth 2.0 | ドラフト 13 のサポート | 最新の仕様である RFC 6749 のサポート |
| WS-Trust | サポートされています | サポートされていません |
| トークンの形式 | ||
| JWT | ベータ版でサポート | サポートされています |
| SAML 1.1 | サポートされています | プレビュー |
| SAML 2.0 | サポートされています | サポートされています |
| SWT | サポートされています | サポートされていません |
| カスタマイズ | ||
| カスタマイズ可能なホーム領域検出/アカウント選択 UI | アプリに組み込むことができるダウンロード可能なコード | サポートされていません |
| カスタム トークン署名証明書をアップロードする | サポートされています | サポートされています |
| トークン内の要求をカスタマイズする | - ID プロバイダーからの入力要求をパススルーする - ID プロバイダーから要求としてアクセス トークンを取得する - 入力要求の値に基づいて出力要求を発行する - 定数値を使用して出力要求を発行する |
- フェデレーション ID プロバイダーからの要求をパススルーできない - ID プロバイダーから要求としてアクセス トークンを取得できない - 入力要求の値に基づいて出力要求を発行できない - 定数値を使用して出力要求を発行できます - Microsoft Entra ID に同期されたユーザーのプロパティに基づいて出力要求を発行できます |
| 自動化 | ||
| 構成と管理のタスクを自動化する | Access Control Management サービス経由でサポートされます | Microsoft Graph API の使用がサポートされています |
Microsoft Entra ID がアプリケーションとサービスに最適な移行パスであると判断した場合は、アプリを Microsoft Entra ID と統合する 2 つの方法に注意する必要があります。
WS-Federation または WIF を使用して Microsoft Entra ID と統合するには、「 ギャラリー以外のアプリケーションのフェデレーション シングル サインオンを構成する」で説明されている方法に従うことをお勧めします。 この記事では、SAML ベースのシングル サインオン用に Microsoft Entra ID を構成する方法について説明しますが、WS-Federation の構成にも使用できます。 この方法に従うには、Microsoft Entra ID P1 または P2 ライセンスが必要です。 この方法には、次の 2 つの利点があります。
- Microsoft Entra トークンのカスタマイズの完全な柔軟性が得られます。 Microsoft Entra ID によって発行される要求は、Access Control によって発行された要求と一致するようにカスタマイズできます。 これには特に、ユーザー ID または名前識別子要求が含まれます。 テクノロジを変更した後も、ユーザーの一貫性のあるユーザー ID を引き続き受け取るために、Microsoft Entra ID によって発行されたユーザー ID が Access Control によって発行されたものと一致することを確認します。
- アプリケーションに固有のトークン署名証明書と、制御する有効期間を構成できます。
注
この方法には、Microsoft Entra ID P1 または P2 ライセンスが必要です。 Access Control のお客様で、アプリケーションのシングル サインオンを設定するために Premium ライセンスが必要な場合は、お問い合わせください。 Microsoft では、お客様が使用できる開発者ライセンスを提供します。
別の方法として、 このコード サンプルに従って、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 開発者ガイドで入手できる Web アプリケーションに Microsoft Entra ID を統合する方法に関する広範なドキュメントとガイダンスがあります。
Azure Active Directory B2C への移行
考慮すべきもう 1 つの移行パスは、Azure AD B2C です。 Azure AD B2C は、Access Control と同様に、開発者が認証と ID 管理ロジックをクラウド サービスにアウトソーシングできるクラウド認証サービスです。 これは、(Free レベルと Premium レベルの) 有料サービスであり、最大で何百万人ものアクティブ ユーザーが存在する可能性があるコンシューマー向けアプリケーション向けに設計されています。
アクセス制御と同様に、Azure AD B2C の最も魅力的な機能の 1 つは、さまざまな種類のアカウントをサポートしていることです。 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 のサポート |
|---|---|---|
| アカウントの種類 | ||
| Microsoft の職場または学校アカウント | サポートされています | カスタム ポリシーを使用してサポートされます |
| Windows Server Active Directory と AD FS のアカウント | AD FS との直接フェデレーションを介してサポートされます | カスタム ポリシーを使用した SAML フェデレーションによるサポート |
| 他のエンタープライズ ID 管理システムのアカウント | WS-Federation を介した直接フェデレーションによってサポートされます | カスタム ポリシーを使用した SAML フェデレーションによるサポート |
| 個人用の Microsoft アカウント | サポートされています | サポートされています |
| Facebook、Google、Yahoo アカウント | サポートされています | Facebook と Google はネイティブにサポートされ、Yahoo はカスタム ポリシーを使用して OpenID Connect フェデレーションを介してサポートされています |
| プロトコルと SDK の互換性 | ||
| Windows Identity Foundation (WIF) | サポートされています | サポートされていません |
| WS-Federation | サポートされています | サポートされていません |
| OAuth 2.0 | ドラフト 13 のサポート | 最新の仕様である RFC 6749 のサポート |
| WS-Trust | サポートされています | サポートされていません |
| トークンの形式 | ||
| JWT | ベータ版でサポート | サポートされています |
| SAML 1.1 | サポートされています | サポートされていません |
| SAML 2.0 | サポートされています | サポートされていません |
| SWT | サポートされています | サポートされていません |
| カスタマイズ | ||
| カスタマイズ可能なホーム領域検出/アカウント選択 UI | アプリに組み込むことができるダウンロード可能なコード | カスタム CSS を使用して完全にカスタマイズ可能な UI |
| カスタム トークン署名証明書をアップロードする | サポートされています | カスタム ポリシーを使用してサポートされる、証明書ではなくカスタム署名キー |
| トークン内の要求をカスタマイズする | - ID プロバイダーからの入力要求をパススルーする - ID プロバイダーから要求としてアクセス トークンを取得する - 入力要求の値に基づいて出力要求を発行する - 定数値を使用して出力要求を発行する |
- ID プロバイダーからのクレームをそのまま通過させることができます。一部のクレームにはカスタムポリシーが必要です。 - ID プロバイダーから要求としてアクセス トークンを取得できない - カスタム ポリシーを使用して、入力要求の値に基づいて出力要求を発行できます - カスタム ポリシーを使用して、定数値で出力要求を発行できます |
| 自動化 | ||
| 構成と管理のタスクを自動化する | Access Control Management サービス経由でサポートされます | - Microsoft Graph API を使用して許可されるユーザーの作成 - B2C テナント、アプリケーション、またはポリシーをプログラムで作成できない |
Azure AD B2C がアプリケーションとサービスに最適な移行パスであると判断した場合は、次のリソースから始めます。
Ping ID または Auth0 への移行
場合によっては、Microsoft Entra ID と Azure AD B2C では、主要なコードを変更せずに Web アプリケーションの Access Control を置き換えるには十分ではない場合があります。 一般的な例としては、次のようなものがあります。
- GOOGLE や Facebook などのソーシャル ID プロバイダーとのサインインに WIF または WS-Federation を使用する Web アプリケーション。
- WS-Federation プロトコル経由でエンタープライズ ID プロバイダーへの直接フェデレーションを実行する Web アプリケーション。
- ソーシャル ID プロバイダー (Google や Facebook など) によって発行されたアクセス トークンを Access Control によって発行されたトークンの要求として必要とする Web アプリケーション。
- Microsoft Entra ID または Azure AD B2C で再現できない複雑なトークン変換規則を持つ Web アプリケーション。
- ACS を使用してさまざまな ID プロバイダーへのフェデレーションを一元的に管理するマルチテナント Web アプリケーション
このような場合は、Web アプリケーションを別のクラウド認証サービスに移行することを検討することをお勧めします。 次のオプションを確認することをお勧めします。 次の各オプションは、Access Control と同様の機能を提供します。
Auth0 は、 アクセス制御のお客様向けの高度な移行ガイダンスを作成し、ACS が行うほぼすべての機能をサポートする柔軟なクラウド ID サービスです。
Ping ID には、 ACS に似た 2 つのソリューションが用意されています。 PingOne は、ACS と同じ機能の多くをサポートするクラウド ID サービスであり、PingFederate は、より柔軟性を提供する同様のオンプレミス ID 製品です。 これらの製品の使用の詳細については、Ping の ACS 提供終了ガイダンスを参照してください。
Ping ID と Auth0 を使用する目的は、すべての Access Control のお客様が、アクセス制御からの移行に必要な作業量を最小限に抑えるアプリとサービスの移行パスを確保することです。
アクティブな認証を使用する Web サービス
Access Control によって発行されたトークンでセキュリティ保護された Web サービスの場合、Access Control には次の機能が用意されています。
- Access Control 名前空間に 1 つ以上 のサービス ID を 登録する機能。 サービス 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 ID のサポート |
|---|---|---|
| Web サービスを登録する方法 | Access Control 管理ポータルで信頼関係者を作成する | Azure portal で Microsoft Entra Web アプリケーションを作成する |
| クライアントを登録する方法 | Access Control 管理ポータルでサービス ID を作成する | Azure portal で別の Microsoft Entra Web アプリケーションを作成する |
| 使用されるプロトコル | - OAuth WRAP プロトコル - OAuth 2.0 Draft 13 クライアント資格情報の付与 |
OAuth 2.0 クライアント資格情報の付与 |
| クライアント認証方法 | - 単純なパスワード - 署名された SWT - フェデレーション ID プロバイダーからの SAML トークン |
- 単純なパスワード - 署名された JWT |
| トークンの形式 | - JWT - SAML 1.1 - SAML 2.0 - SWT |
JWT のみ |
| トークン変換 | - カスタム要求を追加する - 単純な if-then クレーム発行ロジック |
カスタム要求を追加する |
| 構成と管理のタスクを自動化する | Access Control Management サービス経由でサポートされます | Microsoft Graph API の使用がサポートされています |
サーバー間シナリオの実装に関するガイダンスについては、次のリソースを参照してください。
- Microsoft Entra 開発者ガイドのサービス間セクション
- 単純なパスワード クライアント資格情報を使用したデーモン コード サンプル
- 証明書クライアント資格情報を使用したデーモン コード サンプル
Ping ID または Auth0 への移行
場合によっては、Microsoft Entra クライアントの資格情報と OAuth 許可の実装では、アーキテクチャ内の Access Control を大きなコードを変更せずに置き換えるには十分ではない場合があります。 一般的な例としては、次のようなものがあります。
- JWT 以外のトークン形式を使用したサーバー間認証。
- 外部 ID プロバイダーによって提供される入力トークンを使用したサーバー間認証。
- Microsoft Entra ID で再現できないトークン変換規則を使用したサーバー間認証。
このような場合は、Web アプリケーションを別のクラウド認証サービスに移行することを検討してください。 次のオプションを確認することをお勧めします。 次の各オプションは、Access Control と同様の機能を提供します。
Auth0 は、 アクセス制御のお客様向けの高度な移行ガイダンスを作成し、ACS が行うほぼすべての機能をサポートする柔軟なクラウド ID サービスです。
が ACS に似た 2 つのソリューションを提供することを示しています。 PingOne は、ACS と同じ機能の多くをサポートするクラウド ID サービスであり、PingFederate は、より柔軟性を提供する同様のオンプレミス ID 製品です。 これらの製品の使用の詳細については、Ping の ACS 提供終了ガイダンスを参照してください。
Ping ID と Auth0 を使用する目的は、すべての Access Control のお客様が、アクセス制御からの移行に必要な作業量を最小限に抑えるアプリとサービスの移行パスを確保することです。
パススルー認証
任意のトークン変換を使用したパススルー認証の場合、ACS と同等の Microsoft テクノロジはありません。 それが顧客に必要な場合は、最も近い近似ソリューションを提供する Auth0 である可能性があります。
質問、懸念事項、フィードバック
この記事を読んだ後、多くの Access Control のお客様が明確な移行パスを見つけられないことを理解しています。 適切な計画を決定する際に、何らかの支援やガイダンスが必要になる場合があります。 移行シナリオと質問について話し合いたい場合は、このページにコメントを残してください。