方法:Azure Access Control Service からの移行How to: Migrate from the Azure Access Control Service

Azure Active Directory (Azure AD) のサービスである Microsoft Azure Access Control (ACS) は、2018 年 11 月 7 日に終了する予定です。Microsoft Azure Access Control Service (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. 現在 Access Control を使用しているアプリケーションとサービスは、それまでに別の認証メカニズムへと完全移行する必要があります。Applications and services that currently use Access Control must be fully migrated to a different authentication mechanism by then. この記事では、現在のお客様を対象に、Access Control の使用の廃止を計画する際の推奨事項を紹介します。This article describes recommendations for current customers, as you plan to deprecate your use of Access Control. 現在 Access Control を使用していない場合は、何もする必要はありません。If you don't currently use Access Control, you don't need to take any action.

概要Overview

Access Control は、Web アプリケーションや Web サービスにアクセスするユーザーの認証と承認を容易にする、クラウド認証サービスです。Access Control is a cloud authentication service that offers an easy way to authenticate and authorize users for access to your web applications and services. これにより、認証や承認に関する多くの機能について、コーディングの必要がなくなります。It allows many features of authentication and authorization to be factored out of your code. Access Control は主に、Microsoft .NET クライアント、ASP.NET Web アプリケーション、および Windows Communication Foundation (WCF) Web サービスの開発者や設計者によって使用されます。Access Control is primarily used by developers and architects of Microsoft .NET clients, ASP.NET web applications, and Windows Communication Foundation (WCF) web services.

Access Control のユース ケースは、主に次の 3 つのカテゴリに分けることができます。Use cases for Access Control can be broken down into three main categories:

  • 特定の Microsoft クラウド サービス (Azure Service Bus、Dynamics CRM など) に対する認証。Authenticating to certain Microsoft cloud services, including Azure Service Bus and Dynamics CRM. クライアント アプリケーションは、Access Control から取得したトークンによってこれらのサービスに対する認証を受け、さまざまなアクションを実行します。Client applications obtain tokens from Access Control to authenticate to these services to perform various actions.
  • Web アプリケーション (カスタムとパッケージ (SharePoint など) の両方) に対する認証の追加。Adding authentication to web applications, both custom and prepackaged (like SharePoint). Web アプリケーションで Access Control の "パッシブ" 認証を使用すると、Microsoft アカウント (以前の Live ID) だけでなく、Google、Facebook、Yahoo、Azure AD、および Active Directory フェデレーション サービス (AD FS) のアカウントを使用してサインインできるようになります。By using Access Control "passive" authentication, web applications can support sign-in with a Microsoft account (formerly Live ID), and with accounts from Google, Facebook, Yahoo, Azure AD, and Active Directory Federation Services (AD FS).
  • Access Control によって発行されるトークンを使用したカスタム Web サービスのセキュリティ保護。Securing custom web services with tokens issued by Access Control. Web サービスで "アクティブ" 認証を使用すると、Access Control を使用して認証された既知のクライアントに対してのみ、アクセスを許可できるようになります。By using "active" authentication, web services can ensure that they allow access only to known clients that have authenticated with Access Control.

これらの各ユース ケースと推奨される移行方法については、以下のセクションで説明します。Each of these use cases and their recommended migration strategies are discussed in the following sections.

警告

ほとんどの場合、既存のアプリやサービスを新しいテクノロジに移行するには大幅なコード変更が必要になります。In most cases, significant code changes are required to migrate existing apps and services to newer technologies. 停止またはダウンタイムの可能性を防ぐために、移行の計画や実行を速やかに開始することをお勧めします。We recommend that you immediately begin planning and executing your migration to avoid any potential outages or downtime.

Access Control に含まれるコンポーネントを次に示します。Access Control has the following components:

  • セキュリティ トークン サービス (STS)。認証要求を受け取って、セキュリティ トークンを発行します。A secure token service (STS), which receives authentication requests and issues security tokens in return.
  • Azure クラシック ポータル。このポータルでは、Access Control 名前空間を作成したり、削除したり、有効/無効を切り替えることができます。The Azure classic portal, where you create, delete, and enable and disable Access Control namespaces.
  • 個別の Access Control 管理ポータル。このポータルでは、Access Control 名前空間のカスタマイズや構成を行うことができます。A separate Access Control management portal, where you customize and configure Access Control namespaces.
  • 管理サービス。ポータルの機能を自動化するために使用できます。A management service, which you can use to automate the functions of the portals.
  • トークン変換ルール エンジン。Access Control が発行するトークンの出力形式を操作する、複雑なロジックを定義できます。A token transformation rule engine, which you can use to define complex logic to manipulate the output format of tokens that Access Control issues.

これらのコンポーネントを使用するには、1 つ以上の Access Control 名前空間を作成する必要があります。To use these components, you must create one or more Access Control namespaces. 名前空間とは、アプリケーションやサービスと通信するために使用される、Access Control 専用のインスタンスのことです。A namespace is a dedicated instance of Access Control that your applications and services communicate with. 名前空間は、Access Control を使用するその他のすべてのお客様から分離されます。A namespace is isolated from all other Access Control customers. 他のお客様は、それぞれ独自の名前空間を使用します。Other Access Control customers use their own namespaces. Access Control 名前空間には、次のような専用の URL が使用されます。A namespace in Access Control has a dedicated URL that looks like this:

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

STS および管理操作とのすべての通信は、この URL で行われます。All communication with the STS and management operations are done at this URL. 目的ごとに、異なるパスを使用します。You use different paths for different purposes. アプリケーションやサービスが Access Control を使用しているかどうかを確認するには、 https://<名前空間>.accesscontrol.windows.net へのトラフィックを監視します。To determine whether your applications or services use Access Control, monitor for any traffic to https://<namespace>.accesscontrol.windows.net. この URL へのトラフィックは Access Control によって処理されるため、停止する必要があります。Any traffic to this URL is handled by Access Control, and needs to be discontinued.

これに対する例外は、https://accounts.accesscontrol.windows.net へのすべてのトラフィックです。The exception to this is any traffic to https://accounts.accesscontrol.windows.net. この URL へのトラフィックは既に他のサービスによって対処されており、Access Control の廃止の影響を受けませんTraffic to this URL is already handled by a different service and is not affected by the Access Control deprecation.

Access Control の詳細については、「Access Control Service 2.0」(アーカイブ) を参照してください。For more information about Access Control, see Access Control Service 2.0 (archived).

影響を受けるアプリケーションを確認するFind out which of your apps will be impacted

このセクションの手順に従って、どのアプリケーションが ACS の提供終了によって影響を受けるかを確認します。Follow the steps in this section to find out which of your apps will be impacted by ACS retirement.

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

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

  2. 次を実行してモジュールをインストールしますInstall the module by running

    Install-Module -Name Acs.Namespaces
    
  3. 次を実行して、使用できるすべてのコマンドの一覧を取得しますGet a list of all possible commands by running

    Get-Command -Module Acs.Namespaces
    

    特定のコマンドのヘルプを表示するには、次を実行します。To get help on a specific command, run:

     Get-Help [Command-Name] -Full
    

    [Command-Name] は、ACS コマンドの名前です。where [Command-Name] is the name of the ACS command.

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

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

    コマンドを実行する前に Set-ExecutionPolicy -ExecutionPolicy Bypass を実行し、コマンドを実行するためにそれらのサブスクリプションの管理者になっておくことが必要な場合があります。You may need to run Set-ExecutionPolicy -ExecutionPolicy Bypass before you can execute commands and be the admin of those subscriptions in order to execute the commands.

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

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

どのアプリケーションが影響を受けるかを確認するCheck which applications will be impacted

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

    たとえば、名前空間の 1 つが contoso-test である場合は、https://contoso-test.accesscontrol.windows.net に移動しますFor example, if one of the namespaces is contoso-test, go to https://contoso-test.accesscontrol.windows.net

  2. [信頼関係] で、 [証明書利用者アプリケーション] を選択し、ACS の提供終了の影響を受けるアプリケーションの一覧を表示します。Under Trust relationships, select Relying party applications to see the list of apps that will be impacted by ACS retirement.

  3. その他に ACS 名前空間があれば、それらについて手順 1 ~ 2 を繰り返します。Repeat steps 1-2 for any other ACS namespace(s) that you have.

提供終了のスケジュールRetirement schedule

2017 年 11 月の時点では、すべての Access Control コンポーネントは完全にサポートされており、使用可能です。As of November 2017, all Access Control components are fully supported and operational. ただし、Azure クラシック ポータルを使用して新しい Access Control 名前空間を作成することはできませんThe only restriction is that you can't create new Access Control namespaces via the Azure classic portal.

Access Control コンポーネントの廃止スケジュールを次に示します。Here's the schedule for deprecating Access Control components:

  • 2017 年 11 月: Azure クラシック ポータルでの Azure AD 管理エクスペリエンスの提供は終了しますNovember 2017: The Azure AD admin experience in the Azure classic portal is retired. この時点で、Access Control の名前空間の管理は、新しい専用の URL https://manage.windowsazure.com?restoreClassic=true で利用できるようになります。At this point, namespace management for Access Control is available at a new, dedicated URL: https://manage.windowsazure.com?restoreClassic=true. この URl を使用すれば、既存の名前空間を表示したり、名前空間を有効または無効にしたり、名前空間を削除することができます。Use this URl to view your existing namespaces, enable and disable namespaces, and to delete namespaces, if you choose to.
  • 2018 年 4 月 2 日: Azure クラシック ポータルは完全に廃止され、Access Control の名前空間管理はすべての URL で使用できなくなります。April 2, 2018: The Azure classic portal is completely retired, meaning Access Control namespace management is no longer available via any URL. これ以降、Access Control 名前空間を有効または無効にしたり、削除したり、列挙することはできなくなります。At this point, you can't disable or enable, delete, or enumerate your Access Control namespaces. ただし、Access Control 管理ポータルはその機能を完全に維持され、https://\<namespace\>.accesscontrol.windows.net に配置されます。However, the Access Control management portal will be fully functional and located at https://\<namespace\>.accesscontrol.windows.net. その他の Access Control コンポーネントもすべて、引き続き正常に動作します。All other components of Access Control continue to operate normally.
  • 2018 年 11 月 7 日: すべての Access Control コンポーネントが完全にシャットダウンされます。November 7, 2018: All Access Control components are permanently shut down. これには、Access Control 管理ポータル、管理サービス、STS、およびトークン変換ルール エンジンが含まれます。This includes the Access Control management portal, the management service, STS, and the token transformation rule engine. これ以降、(<名前空間>.accesscontrol.windows.net にある) Access Control へ送信されるすべての要求は失敗するようになります。At this point, any requests sent to Access Control (located at <namespace>.accesscontrol.windows.net) fail. この時点までに、すべての既存アプリケーションとサービスを他のテクノロジへと移行しておく必要があります。You should have migrated all existing apps and services to other technologies well before this time.

注意

ポリシーは、一定期間トークンを要求していない名前空間を無効にします。A policy disables namespaces that have not requested a token for a period of time. 2018 年初頭現在、この期間は 14 日間の非アクティブですが、今後数週間以内に 7 日間の非アクティブに短縮されます。As of early September 2018, this period of time is currently at 14 days of inactivity, but this will be shortened to 7 days of inactivity in the coming weeks. 現在無効になっている Access Control 名前空間がある場合、ACS PowerShell をダウンロードしてインストールし、名前空間を再度有効にすることができます。If you have Access Control namespaces that are currently disabled, you can download and install ACS PowerShell to re-enable the namespace(s).

移行方法Migration strategies

次のセクションでは、Access Control から他の Microsoft テクノロジに移行する際の推奨事項の概要を示します。The following sections describe high-level recommendations for migrating from Access Control to other Microsoft technologies.

Microsoft クラウド サービスのクライアントClients of Microsoft cloud services

Access Control によって発行されたトークンを受け入れる各 Microsoft クラウド サービスでは、少なくとも 1 つの代替認証形式がサポートされています。Each Microsoft cloud service that accepts tokens that are issued by Access Control now supports at least one alternate form of authentication. 使用できる認証メカニズムは、サービスごとに異なります。The correct authentication mechanism varies for each service. 各サービスの固有のドキュメントで、公式のガイダンスを参照することをお勧めします。We recommend that you refer to the specific documentation for each service for official guidance. ここでは簡単に、各ドキュメントのセットを示します。For convenience, each set of documentation is provided here:

ServiceService ガイダンスGuidance
Azure Service BusAzure Service Bus Shared Access Signatures への移行Migrate to shared access signatures
Azure Service Bus RelayAzure Service Bus Relay Shared Access Signatures への移行Migrate to shared access signatures
Azure Managed CacheAzure Managed Cache Azure Cache for Redis への移行Migrate to Azure Cache for Redis
Azure DataMarketAzure DataMarket Cognitive Services APIs への移行Migrate to the Cognitive Services APIs
BizTalk ServicesBizTalk Services Azure App Service の Logic Apps 機能への移行Migrate to the Logic Apps feature of Azure App Service
Azure Media ServicesAzure Media Services Azure AD 認証への移行Migrate to Azure AD authentication
Azure BackupAzure Backup Azure Backup エージェントのアップグレードUpgrade the Azure Backup agent

SharePoint のユーザーSharePoint customers

SharePoint 2013、2016、SharePoint Online のユーザーは、クラウド、オンプレミス、およびハイブリッドのシナリオでの認証のために長い間 ACS を使ってきました。SharePoint 2013, 2016, and SharePoint Online customers have long used ACS for authentication purposes in cloud, on premises, and hybrid scenarios. SharePoint の一部の機能とユース ケースは ACS 提供終了の影響を受けますが、それ以外には影響ありません。Some SharePoint features and use cases will be affected by ACS retirement, while others will not. 次の表は、ACS を利用する最も一般的な SharePoint 機能の一部に対する移行のガイダンスをまとめたものです。The below table summarizes migration guidance for some of the most popular SharePoint feature that leverage ACS:

機能Feature ガイダンスGuidance
Azure AD からのユーザーの認証Authenticating users from Azure AD これまで、Azure AD は SharePoint での認証に必要な SAML 1.1 トークンをサポートしておらず、SharePoint を Azure AD トークン形式と互換性があるようにする手段として ACS が使われていました。Previously, Azure AD did not support SAML 1.1 tokens required by SharePoint for authentication, and ACS was used as an intermediary that made SharePoint compatible with Azure AD token formats. 現在は、Azure AD アプリ ギャラリーの SharePoint オンプレミス アプリを使って SharePoint を Azure AD に直接接続することができます。Now, you can connect SharePoint directly to Azure AD using Azure AD App Gallery SharePoint on premises app.
オンプレミスの SharePoint でのアプリ認証とサーバー間認証App authentication & server-to-server authentication in SharePoint on premises ACS の提供終了の影響を受けません。変更は必要ありません。Not affected by ACS retirement; no changes necessary.
SharePoint アドインに対する低信頼度の承認 (プロバイダーおよび SharePoint によるホスト)Low trust authorization for SharePoint add-ins (provider hosted and SharePoint hosted) ACS の提供終了の影響を受けません。変更は必要ありません。Not affected by ACS retirement; no changes necessary.
SharePoint クラウド ハイブリッド検索SharePoint cloud hybrid search ACS の提供終了の影響を受けません。変更は必要ありません。Not affected by ACS retirement; no changes necessary.

パッシブ認証を使用する Web アプリケーションWeb applications that use passive authentication

ユーザー認証に Access Control を使用してる Web アプリケーションを考慮し、Access Control では、Web アプリケーションの開発者や設計者向けに次の機能が提供されています。For web applications that use Access Control for user authentication, Access Control provides the following features and capabilities to web application developers and architects:

  • Windows Identity Foundation (WIF) との緊密な統合Deep integration with Windows Identity Foundation (WIF).
  • Google、Facebook、Yahoo、Azure Active Directory、AD FS アカウント、および Microsoft アカウント とのフェデレーション。Federation with Google, Facebook, Yahoo, Azure Active Directory, and AD FS accounts, and Microsoft accounts.
  • 次の認証プロトコルのサポート: OAuth 2.0 Draft 13、WS-Trust、Web Services Federation (WS-Federation)。Support for the following authentication protocols: OAuth 2.0 Draft 13, WS-Trust, and Web Services Federation (WS-Federation).
  • 次のトークン形式のサポート: JSON Web トークン (JWT)、SAML 1.1、SAML 2.0、Simple Web Token (SWT)。Support for the following token formats: JSON Web Token (JWT), SAML 1.1, SAML 2.0, and Simple Web Token (SWT).
  • ホーム領域検出のエクスペリエンス (WIF に統合)。サインインに使用するアカウントの種類を選択できます。A home realm discovery experience, integrated into WIF, that allows users to pick the type of account they use to sign in. このエクスペリエンスは Web アプリケーションによってホストされ、完全にカスタマイズ可能です。This experience is hosted by the web application and is fully customizable.
  • トークン変換。Web アプリケーションが Access Control から受け取った要求の豊富なカスタマイズが可能です。これには次のようなものがあります。Token transformation that allows rich customization of the claims received by the web application from Access Control, including:
    • ID プロバイダーからの要求をパススルー。Pass through claims from identity providers.
    • その他のカスタム要求の追加。Adding additional custom claims.
    • 特定の条件下で要求を発行する単純な if-then ロジック。Simple if-then logic to issue claims under certain conditions.

残念ながら、これらに匹敵するすべての機能を提供する単一のサービスはありません。Unfortunately, there isn't one service that offers all of these equivalent capabilities. 必要な Access Control の機能を評価して、Azure Active Directory (Azure AD)、Azure Active Directory B2C (Azure AD B2C)、または他のクラウド認証サービスのいずれを使用するかを検討する必要があります。You should evaluate which capabilities of Access Control you need, and then choose between using Azure Active Directory, Azure Active Directory B2C (Azure AD B2C), or another cloud authentication service.

Azure Active Directory への移行Migrate to Azure Active Directory

候補となる経路として、アプリケーションとサービスの Azure AD との直接統合があります。A path to consider is integrating your apps and services directly with Azure AD. Azure AD は、Microsoft の職場または学校アカウントに対応した、クラウド ベースの ID プロバイダーです。Azure AD is the cloud-based identity provider for Microsoft work or school accounts. Azure AD は、Office 365、Azure などに対応した ID プロバイダーです。Azure AD is the identity provider for Office 365, Azure, and much more. これは、Access Control と同様のフェデレーション認証機能を提供しますが、一部の Access Control の機能をサポートしていません。It provides similar federated authentication capabilities to Access Control, but doesn't support all Access Control features.

主な例は、Facebook、Google、Yahoo などのソーシャル ID プロバイダーとのフェデレーションです。The primary example is federation with social identity providers, such as Facebook, Google, and Yahoo. ユーザーがこの種類の資格情報でサインインする場合、Azure AD はソリューションとして適しません。If your users sign in with these types of credentials, Azure AD is not the solution for you.

また、Azure AD では Access Control とまったく同じ認証プロトコルがサポートされるとは限りません。Azure AD also doesn't necessarily support the exact same authentication protocols as Access Control. たとえば、OAuth は Access Control と Azure AD の両方でサポートされていますが、各実装間で微妙な違いがあります。For example, although both Access Control and Azure AD support OAuth, there are subtle differences between each implementation. 移行に際しては、実装ごとにコードを変更する必要があります。Different implementations require you to modify code as part of a migration.

ただし、Azure AD には Access Control のお客様にとっての潜在的な利点がいくつかあります。However, Azure AD does provide several potential advantages to Access Control customers. たとえば、クラウドでホストされる、Microsoft の職場または学校のアカウント (Access Control のお客様によって広く使用されているアカウント) がネイティブにサポートされます。It natively supports Microsoft work or school accounts hosted in the cloud, which are commonly used by Access Control customers.

Azure AD テナントは、AD FS を通じて、1 つ以上のオンプレミス Active Directory インスタンスにフェデレーションすることもできます。An Azure AD tenant can also be federated to one or more instances of on-premises Active Directory via AD FS. そのため、クラウド ベースのユーザーだけでなく、オンプレミスでホストされているユーザーもアプリで認証することができます。This way, your app can authenticate cloud-based users and users that are hosted on-premises. また、WS-Federation プロトコルにも対応しています。これにより、WIF を使用して、Web アプリケーションと比較的簡単に統合できます。It also supports the WS-Federation protocol, which makes it relatively straightforward to integrate with a web application by using WIF.

次の表は、Web アプリケーションに関連する Access Control の機能を、Azure AD で利用できる機能と比較したものです。The following table compares the features of Access Control that are relevant to web applications with those features that are available in Azure AD.

大まかに言うと、ユーザーのサインインに Microsoft の職場または学校アカウントだけを使用するのであれば、おそらく Azure Active Directory が移行に最適な選択肢ですAt a high level, Azure Active Directory is probably the best choice for your migration if you let users sign in only with their Microsoft work or school accounts.

機能Capability Access Control でのサポートAccess Control support Azure AD でのサポートAzure AD support
アカウントの種類Types of accounts
Microsoft の職場または学校のアカウントMicrosoft work or school accounts サポートされていますSupported サポートされていますSupported
Windows Server Active Directory および AD FS のアカウントAccounts from Windows Server Active Directory and AD FS - サポート対象 (Azure AD テナントとのフェデレーションを使用)- Supported via federation with an Azure AD tenant
- サポート対象 (AD FS との直接フェデレーションを使用)- Supported via direct federation with AD FS
Azure AD テナントとのフェデレーションによってのみサポート対象Only supported via federation with an Azure AD tenant
その他のエンタープライズ ID 管理システムのアカウントAccounts from other enterprise identity management systems - Azure AD テナントとのフェデレーションにより可能- Possible via federation with an Azure AD tenant
- サポート対象 (直接フェデレーションを使用)- Supported via direct federation
Azure AD テナントとのフェデレーションにより可能Possible via federation with an Azure AD tenant
個人的な使用のための Microsoft アカウントMicrosoft accounts for personal use サポートされていますSupported サポート対象 (Azure AD v2.0 OAuth プロトコルを使用。その他のプロトコルは使用できません)Supported via the Azure AD v2.0 OAuth protocol, but not over any other protocols
Facebook、Google、Yahoo アカウントFacebook, Google, Yahoo accounts サポートされていますSupported 未サポートNot supported whatsoever
プロトコルと SDK の互換性Protocols and SDK compatibility
WIFWIF サポートされていますSupported サポート対象。ただし、使用できる手順に制限ありSupported, but limited instructions are available
WS-FederationWS-Federation サポートされていますSupported サポートされていますSupported
OAuth 2.0OAuth 2.0 Draft 13 をサポートSupport for Draft 13 RFC 6749 (ほとんどの最新の仕様) をサポートSupport for RFC 6749, the most modern specification
WS-TrustWS-Trust サポートされていますSupported サポートされていませんNot supported
トークン形式Token formats
JWTJWT Beta でサポートSupported In Beta サポートされていますSupported
SAML 1.1SAML 1.1 サポートされていますSupported プレビューPreview
SAML 2.0SAML 2.0 サポートされていますSupported サポートされていますSupported
SWTSWT サポートされていますSupported サポートされていませんNot supported
カスタマイズCustomizations
カスタマイズ可能なホーム領域検出/アカウント選択 UICustomizable home realm discovery/account-picking UI アプリに組み込めるダウンロード可能なコードDownloadable code that can be incorporated into apps サポートされていませんNot supported
カスタムのトークン署名証明書をアップロードUpload custom token-signing certificates サポートされていますSupported サポートされていますSupported
トークンの要求をカスタマイズCustomize claims in tokens - ID プロバイダーからの入力要求をパススルー- Pass through input claims from identity providers
- ID プロバイダーからアクセス トークンを要求として取得- Get access token from identity provider as a claim
- 入力要求の値に基づいて出力要求を発行- Issue output claims based on values of input claims
- 定数値を持つ出力要求を発行- Issue output claims with constant values
- フェデレーション ID プロバイダーからの要求をパススルーすることはできません- Cannot pass through claims from federated identity providers
- ID プロバイダーからアクセス トークンを要求として取得できません- Cannot get access token from identity provider as a claim
- 入力要求の値に基づいて出力要求を発行できません- Cannot issue output claims based on values of input claims
- 定数値を持つ出力要求を発行できます- Can issue output claims with constant values
- Azure AD に同期されたユーザーのプロパティに基づいて出力要求を発行できます- Can issue output claims based on properties of users synced to Azure AD
AutomationAutomation
構成および管理タスクを自動化Automate configuration and management tasks サポート対象 (Access Control 管理サービスを使用)Supported via Access Control Management Service サポート対象 (Microsoft Graph と Azure AD Graph API を使用)Supported via Microsoft Graph and Azure AD Graph API

Azure AD がアプリケーションとサービスの最善の移行経路であると判断した場合は、アプリを Azure AD と統合する 2 つの方法を認識する必要があります。If you decide that Azure AD is the best migration path for your applications and services, you should be aware of two ways to integrate your app with Azure AD.

WS-Federation または WIF を使用して Azure AD と統合する場合は、「ギャラリー以外のアプリケーションのフェデレーション シングル サインオンを構成する方法」で説明されているアプローチに従うことをお勧めします。To use WS-Federation or WIF to integrate with Azure AD, we recommend following the approach described in Configure federated single sign-on for a non-gallery application. この記事は、Azure AD を SAML ベースのシングル サインオン用に構成する方法を説明したものですが、WS-Federation の構成にも使用できます。The article refers to configuring Azure AD for SAML-based single sign-on, but also works for configuring WS-Federation. このアプローチを使用するには、Azure AD Premium ライセンスが必要です。Following this approach requires an Azure AD Premium license. このアプローチには 2 つの利点があります。This approach has two advantages:

  • Azure AD トークン カスタマイズの柔軟性をフルに活用できます。You get the full flexibility of Azure AD token customization. Azure AD によって発行された要求を、Access Control によって発行された要求と一致するようにカスタマイズすることができます。You can customize the claims that are issued by Azure AD to match the claims that are issued by Access Control. これは、ユーザー ID や名前識別子要求に特に便利です。This especially includes the user ID or Name Identifier claim. テクノロジが変更された後もユーザー ID の一貫性が維持されるようにするには、Azure AD によって発行されたユーザー ID を、Access Control によって発行されたユーザー ID と一致させる必要があります。To continue to receive consistent user IDentifiers for your users after you change technologies, ensure that the user IDs issued by Azure AD match those issued by Access Control.
  • アプリケーション固有のトークン署名証明書を構成し、その有効期間を制御できます。You can configure a token-signing certificate that is specific to your application, and with a lifetime that you control.

注意

このアプローチを使用するには、Azure AD Premium ライセンスが必要です。This approach requires an Azure AD Premium license. Access Control をご使用のお客様で、アプリケーションのシングル サインオンを設定するためのプレミアム ライセンスが必要なお客様は、Microsoft までご連絡ください。If you are an Access Control customer and you require a premium license for setting up single-sign on for an application, contact us. 必要な開発者ライセンスをご提供します。We'll be happy to provide developer licenses for you to use.

もう 1 つのアプローチは、こちらのコード サンプルに従う方法です。この方法では、WS-Federation の設定方法の手順が若干異なります。An alternative approach is to follow this code sample, which gives slightly different instructions for setting up WS-Federation. このコード サンプルでは、WIF を使用せず、代わりに ASP.NET 4.5 OWIN ミドルウェアを使用します。This code sample does not use WIF, but rather, the ASP.NET 4.5 OWIN middleware. ただし、アプリ登録の手順は、WIF を使用するアプリに対しても有効であり、Azure AD Premium ライセンスは必要ありません。However, the instructions for app registration are valid for apps using WIF, and don't require an Azure AD Premium license.

このアプローチを選ぶ場合は、Azure AD での署名キー ロールオーバーについて理解する必要があります。If you choose this approach, you need to understand signing key rollover in Azure AD. このアプローチでは、Azure AD のグローバル署名キーを使用してトークンを発行します。This approach uses the Azure AD global signing key to issue tokens. 既定では、WIF は署名キーを自動的に更新しません。By default, WIF does not automatically refresh signing keys. Azure AD がそのグローバル署名キーを回転する場合、変更を確定するために WIF 実装を準備する必要があります。When Azure AD rotates its global signing keys, your WIF implementation needs to be prepared to accept the changes. 詳細については、「Important information about signing key rollover in Azure AD」 (Azure AD の署名キーのロールオーバーに関する重要な情報) を参照してください。For more information, see Important information about signing key rollover in Azure AD.

OpenID Connect または OAuth プロトコル経由で Azure AD と統合できる場合は、その方法で統合することをお勧めします。If you can integrate with Azure AD via the OpenID Connect or OAuth protocols, we recommend doing so. Azure AD を Web アプリケーションに統合する方法については、Azure AD 開発者ガイドにさまざまなドキュメントとガイダンスが記載されています。We have extensive documentation and guidance about how to integrate Azure AD into your web application available in our Azure AD developer guide.

Azure Active Directory B2C への移行Migrate to Azure Active Directory B2C

検討すべきその他の移行パスは、Azure AD B2C です。The other migration path to consider is Azure AD B2C. Azure AD B2C はクラウド認証サービスです。Access Control と同様、開発者は認証と ID 管理のロジックをクラウド サービスに外部委託できます。Azure AD B2C is a cloud authentication service that, like Access Control, allows developers to outsource their authentication and identity management logic to a cloud service. これは、最大数百万人ものアクティブ ユーザーを抱えることがあるコンシューマー向けアプリケーション用に設計された、有料サービスです (Free レベルと Premium レベルがあります)。It's a paid service (with free and premium tiers) that is designed for consumer-facing applications that might have up to millions of active users.

Azure AD B2C の最も魅力的な機能の 1 つは、Access Control と同様、さまざまな種類のアカウントをサポートできることです。Like Access Control, one of the most attractive features of Azure AD B2C is that it supports many different types of accounts. Azure AD B2C では、Microsoft アカウントや、Facebook、Google、LinkedIn、GitHub、Yahoo アカウントなどを使用して、ユーザーをサインインさせることができます。With Azure AD B2C, you can sign in users by using their Microsoft account, or Facebook, Google, LinkedIn, GitHub, or Yahoo accounts, and more. さらに Azure AD B2C では、"ローカル アカウント"、つまりユーザーがアプリケーション専用に作成するユーザー名とパスワードもサポートされます。Azure AD B2C also supports "local accounts," or username and passwords that users create specifically for your application. Azure AD B2C には、サインイン フローのカスタマイズに使用できる豊富な機能拡張も用意されています。Azure AD B2C also provides rich extensibility that you can use to customize your sign-in flows.

ただし、Azure AD B2C では、Access Control のお客様が必要とする可能性がある、広範な認証プロトコルやトークン形式はサポートされません。However, Azure AD B2C doesn't support the breadth of authentication protocols and token formats that Access Control customers might require. また、Azure AD B2C では、トークンを取得したり、ユーザーに関する追加情報を ID プロバイダーや Microsoft などにクエリしたりすることもできません。You also can't use Azure AD B2C to get tokens and query for additional information about the user from the identity provider, Microsoft or otherwise.

次の表は、Web アプリケーションに関連する Access Control の機能を、Azure AD B2C で利用できる機能と比較したものです。The following table compares the features of Access Control that are relevant to web applications with those that are available in Azure AD B2C. 大まかに言えば、おそらく Azure AD B2C は、アプリケーションがコンシューマー向けの場合、またはさまざまな種類のアカウントをサポートする場合の移行に適した選択肢です。At a high level, Azure AD B2C is probably the right choice for your migration if your application is consumer facing, or if it supports many different types of accounts.

機能Capability Access Control でのサポートAccess Control support Azure AD B2C でのサポートAzure AD B2C support
アカウントの種類Types of accounts
Microsoft の職場または学校のアカウントMicrosoft work or school accounts サポートされていますSupported サポート対象 (カスタム ポリシーを使用)Supported via custom policies
Windows Server Active Directory および AD FS のアカウントAccounts from Windows Server Active Directory and AD FS サポート対象 (AD FS との直接フェデレーションを使用)Supported via direct federation with AD FS サポート対象 (カスタム ポリシーを使用した SAML フェデレーション経由)Supported via SAML federation by using custom policies
その他のエンタープライズ ID 管理システムのアカウントAccounts from other enterprise identity management systems サポート対象 (WS-Federation 上の直接フェデレーションを使用)Supported via direct federation through WS-Federation サポート対象 (カスタム ポリシーを使用した SAML フェデレーション経由)Supported via SAML federation by using custom policies
個人的な使用のための Microsoft アカウントMicrosoft accounts for personal use サポートされていますSupported サポートされていますSupported
Facebook、Google、Yahoo アカウントFacebook, Google, Yahoo accounts サポートされていますSupported Facebook と Google はネイティブにサポートされ、Yahoo はカスタム ポリシーを使用して OpenID Connect フェデレーションを介してサポートされますFacebook and Google supported natively, Yahoo supported via OpenID Connect federation by using custom policies
プロトコルと SDK の互換性Protocols and SDK compatibility
Windows Identity Foundation (WIF)Windows Identity Foundation (WIF) サポートされていますSupported サポートされていませんNot supported
WS-FederationWS-Federation サポートされていますSupported サポートされていませんNot supported
OAuth 2.0OAuth 2.0 Draft 13 をサポートSupport for Draft 13 RFC 6749 (ほとんどの最新の仕様) をサポートSupport for RFC 6749, the most modern specification
WS-TrustWS-Trust サポートされていますSupported サポートされていませんNot supported
トークン形式Token formats
JWTJWT Beta でサポートSupported In Beta サポートされていますSupported
SAML 1.1SAML 1.1 サポートされていますSupported サポートされていませんNot supported
SAML 2.0SAML 2.0 サポートされていますSupported サポートされていませんNot supported
SWTSWT サポートされていますSupported サポートされていませんNot supported
カスタマイズCustomizations
カスタマイズ可能なホーム領域検出/アカウント選択 UICustomizable home realm discovery/account-picking UI アプリに組み込めるダウンロード可能なコードDownloadable code that can be incorporated into apps カスタム CSS を使用して完全にカスタマイズできますFully customizable UI via custom CSS
カスタムのトークン署名証明書をアップロードUpload custom token-signing certificates サポートされていますSupported 証明書ではなくカスタム署名キーがサポート対象です (カスタム ポリシーを使用)Custom signing keys, not certificates, supported via custom policies
トークンの要求をカスタマイズCustomize claims in tokens - ID プロバイダーからの入力要求をパススルー- Pass through input claims from identity providers
- ID プロバイダーからアクセス トークンを要求として取得- Get access token from identity provider as a claim
- 入力要求の値に基づいて出力要求を発行- Issue output claims based on values of input claims
- 定数値を持つ出力要求を発行- Issue output claims with constant values
- ID プロバイダーからの要求をパススルーできます。 一部の要求にはカスタム ポリシーが必要です- Can pass through claims from identity providers; custom policies required for some claims
- ID プロバイダーからアクセス トークンを要求として取得できません- Cannot get access token from identity provider as a claim
- カスタム ポリシーを使用して入力要求の値に基づいて出力要求を発行できます- Can issue output claims based on values of input claims via custom policies
- カスタム ポリシーを使用して定数値を持つ出力要求を発行できます- Can issue output claims with constant values via custom policies
AutomationAutomation
構成および管理タスクを自動化Automate configuration and management tasks サポート対象 (Access Control 管理サービスを使用)Supported via Access Control Management Service - Azure AD Graph API を使用してユーザーを作成できます- Creation of users allowed via Azure AD Graph API
- B2C テナント、アプリケーション、またはポリシーをプログラムで作成することはできません- Cannot create B2C tenants, applications, or policies programmatically

Azure AD B2C がアプリケーションとサービスの最善の移行経路であると判断した場合は、次のリソースで開始してください。If you decide that Azure AD B2C is the best migration path for your applications and services, begin with the following resources:

Ping Identity または Auth0 への移行Migrate to Ping Identity or Auth0

場合によっては、Web アプリケーションの Access Control を Azure AD や Azure AD B2C に置き換えるために、大量のコード変更が必要になることがあります。In some cases, you might find that Azure AD and Azure AD B2C aren't sufficient to replace Access Control in your web applications without making major code changes. たとえば、次のような場合です。Some common examples might include:

  • Web アプリケーションで、Google や Facebook などのソーシャル ID プロバイダーにサインインするために、WIF または WS-Federation を使用してしている。Web applications that use WIF or WS-Federation for sign-in with social identity providers such as Google or Facebook.
  • Web アプリケーションで、WS-Federation プロトコルを使用して、エンタープライズ ID プロバイダーへの直接フェデレーションを実行している。Web applications that perform direct federation to an enterprise identity provider over the WS-Federation protocol.
  • Web アプリケーションで、Access Control によって発行されたトークン内の要求として、ソーシャル ID プロバイダー (Google や Facebook など) によって発行されたアクセス トークンが必要である。Web applications that require the access token issued by a social identity provider (such as Google or Facebook) as a claim in the tokens issued by Access Control.
  • Web アプリケーションで、Azure AD や Azure AD B2C では再現できない複雑なトークン変換を使用している。Web applications with complex token transformation rules that Azure AD or Azure AD B2C can't reproduce.
  • マルチテナントの Web アプリケーションで、多数の ID プロバイダーへのフェデレーションを一元管理するために、ACS を使用しているMulti-tenant web applications that use ACS to centrally manage federation to many different identity providers

以上のような場合には、Web アプリケーションを別のクラウド認証サービスに移行することを検討してください。In these cases, you might want to consider migrating your web application to another cloud authentication service. 次のオプションを検討することをお勧めします。We recommend exploring the following options. これらのオプションでは、Access Control と同様の機能が提供されます。Each of the following options offer capabilities similar to Access Control:

この図は Auth0 のロゴを示します Auth0 は柔軟なクラウド ID サービスで、Access Control のお客様向けの高レベルな移行ガイダンスが作成されているほか、ACS で提供される機能がほぼすべてサポートされます。Auth0 is a flexible cloud identity service that has created high-level migration guidance for customers of Access Control, and supports nearly every feature that ACS does.
この図は Ping Identity のロゴを示します Ping Identity では、ACS によく似た 2 つのソリューションが提供されます。Ping Identity offers two solutions similar to ACS. PingOne は、ACS と同じ機能を多数サポートしているクラウド ID サービスであり、PingFederate は、より高度な柔軟性を提供する、類似のオンプレミス ID 製品です。PingOne is a cloud identity service that supports many of the same features as ACS, and PingFederate is a similar on premises identity product that offers more flexibility. これらの製品の使用の詳細については、ACS の提供終了に関する Ping のガイダンスを参照してください。Refer to Ping's ACS retirement guidance for more details on using these products.

Microsoft では、Access Control を使用するすべてのお客様に、アプリやサービスの最適な移行経路を提供し、Access Control の移行に伴う作業を最小限に抑えていただく目的で、Ping Identity および Auth0 と連携しています。Our aim in working with Ping Identity and Auth0 is to ensure that all Access Control customers have a migration path for their apps and services that minimizes the amount of work required to move from Access Control.

アクティブな認証を使用する Web サービスWeb services that use active authentication

Access Control によって発行されたトークンでセキュリティ保護された Web サービスに対して、Access Control は次の機能を提供しています。For web services that are secured with tokens issued by Access Control, Access Control offers the following features and capabilities:

  • 1 つ以上のサービス ID を Access Control 名前空間に登録する機能。Ability to register one or more service identities in your Access Control namespace. サービス ID は、トークンを要求するために使用できます。Service identities can be used to request tokens.
  • 次の種類の資格情報を使用してトークンを要求するための OAuth WRAP および OAuth 2.0 Draft 13 プロトコルのサポート。Support for the OAuth WRAP and OAuth 2.0 Draft 13 protocols for requesting tokens, by using the following types of credentials:
    • サービス ID に対して作成されるシンプルなパスワードA simple password that's created for the service identity
    • 対称キーまたは X509 証明書を使用した署名付き SWTA signed SWT by using a symmetric key or X509 certificate
    • 信頼できる ID プロバイダー (通常は AD FS インスタンス) によって発行された SAML トークンA SAML token issued by a trusted identity provider (typically, an AD FS instance)
  • 次のトークン形式のサポート: JWT、SAML 1.1、SAML 2.0、SWT。Support for the following token formats: JWT, SAML 1.1, SAML 2.0, and SWT.
  • シンプルなトークン変換ルール。Simple token transformation rules.

Access Control のサービス ID は、通常はサーバー対サーバー認証の実装に使用されます。Service identities in Access Control are typically used to implement server-to-server authentication.

Azure Active Directory への移行Migrate to Azure Active Directory

この種類の認証フローに対する推奨事項は、Azure Active Directory に移行することです。Our recommendation for this type of authentication flow is to migrate to Azure Active Directory. Azure AD は、Microsoft の職場または学校アカウントに対応した、クラウド ベースの ID プロバイダーです。Azure AD is the cloud-based identity provider for Microsoft work or school accounts. Azure AD は、Office 365、Azure などに対応した ID プロバイダーです。Azure AD is the identity provider for Office 365, Azure, and much more.

OAuth クライアント資格情報の付与の Azure AD 実装を使用して、Azure AD をサーバー対サーバー認証に使用することもできます。You can also use Azure AD for server-to-server authentication by using the Azure AD implementation of the OAuth client credentials grant. 次の表は、サーバー対サーバー認証での Access Control の機能を、Azure AD で使用可能な機能と比較したものです。The following table compares the capabilities of Access Control in server-to-server authentication with those that are available in Azure AD.

機能Capability Access Control でのサポートAccess Control support Azure AD でのサポートAzure AD support
Web サービスを登録する方法How to register a web service Access Control 管理ポータルで証明書利用者を作成しますCreate a relying party in the Access Control management portal Azure Portal で Azure AD Web アプリケーションを作成しますCreate an Azure AD web application in the Azure portal
クライアントを登録する方法How to register a client Access Control 管理ポータルでサービス ID を作成しますCreate a service identity in Access Control management portal Azure Portal で別の Azure AD Web アプリケーションを作成しますCreate another Azure AD web application in the Azure portal
使用されるプロトコルProtocol used - OAuth WRAP プロトコル- OAuth WRAP protocol
- OAuth 2.0 Draft 13 クライアント資格情報の付与- OAuth 2.0 Draft 13 client credentials grant
OAuth 2.0 クライアント資格情報の付与OAuth 2.0 client credentials grant
クライアント認証方法Client authentication methods - シンプルなパスワード- Simple password
- 署名付き SWT- Signed SWT
- フェデレーション ID プロバイダーからの SAML トークン- SAML token from a federated identity provider
- シンプルなパスワード- Simple password
- 署名付き JWT- Signed JWT
トークン形式Token formats - JWT- JWT
- SAML 1.1- SAML 1.1
- SAML 2.0- SAML 2.0
- SWT- SWT
JWT のみJWT only
トークン変換Token transformation - カスタム要求の追加- Add custom claims
- シンプルな if-then 要求発行ロジック- Simple if-then claim issuance logic
カスタム要求の追加Add custom claims
構成および管理タスクを自動化Automate configuration and management tasks サポート対象 (Access Control 管理サービスを使用)Supported via Access Control Management Service サポート対象 (Microsoft Graph と Azure AD Graph API を使用)Supported via Microsoft Graph and Azure AD Graph API

サーバー対サーバーのシナリオの実装のガイダンスについては、次のリソースをご覧ください。For guidance about implementing server-to-server scenarios, see the following resources:

Ping Identity または Auth0 への移行Migrate to Ping Identity or Auth0

場合によっては、Access Control を Azure AD クライアント資格情報や OAuth の付与の実装へと移行するために、大量のコード変更が必要になることがあります。In some cases, you might find that the Azure AD client credentials and the OAuth grant implementation aren't sufficient to replace Access Control in your architecture without major code changes. たとえば、次のような場合です。Some common examples might include:

  • サーバー対サーバー認証で、JWT 以外のトークン形式を使用している。Server-to-server authentication using token formats other than JWTs.
  • サーバー対サーバー認証で、外部の ID プロバイダーから提供される入力トークンを使用している。Server-to-server authentication using an input token provided by an external identity provider.
  • サーバー対サーバー認証で、Azure AD では再現できないトークン変換ルールを使用している。Server-to-server authentication with token transformation rules that Azure AD cannot reproduce.

以上のような場合には、Web アプリケーションを別のクラウド認証サービスに移行することを検討してください。In these cases, you might consider migrating your web application to another cloud authentication service. 次のオプションを検討することをお勧めします。We recommend exploring the following options. これらのオプションでは、Access Control と同様の機能が提供されます。Each of the following options offer capabilities similar to Access Control:

この図は Auth0 のロゴを示します Auth0 は柔軟なクラウド ID サービスで、Access Control のお客様向けの高レベルな移行ガイダンスが作成されているほか、ACS で提供される機能がほぼすべてサポートされます。Auth0 is a flexible cloud identity service that has created high-level migration guidance for customers of Access Control, and supports nearly every feature that ACS does.
この図は Ping Identity のロゴを示します Ping Identity では、ACS によく似た 2 つのソリューションが提供されます。Ping Identity offers two solutions similar to ACS. PingOne は、ACS と同じ機能を多数サポートしているクラウド ID サービスであり、PingFederate は、より高度な柔軟性を提供する、類似のオンプレミス ID 製品です。PingOne is a cloud identity service that supports many of the same features as ACS, and PingFederate is a similar on premises identity product that offers more flexibility. これらの製品の使用の詳細については、ACS の提供終了に関する Ping のガイダンスを参照してください。Refer to Ping's ACS retirement guidance for more details on using these products.

Microsoft では、Access Control を使用するすべてのお客様に、アプリやサービスの最適な移行経路を提供し、Access Control の移行に伴う作業を最小限に抑えていただく目的で、Ping Identity および Auth0 と連携しています。Our aim in working with Ping Identity and Auth0 is to ensure that all Access Control customers have a migration path for their apps and services that minimizes the amount of work required to move from Access Control.

パススルー認証Passthrough authentication

任意のトークン変換によるパススルー認証の場合、ACS に相当する Microsoft のテクノロジはありません。For passthrough authentication with arbitrary token transformation, there is no equivalent Microsoft technology to ACS. お客様がそれを必要としている場合は、Auth0 が最も近い類似のソリューションを提供しています。If that is what your customers need, Auth0 might be the one who provides the closest approximation solution.

質問、懸念事項、フィードバックQuestions, concerns, and feedback

Microsoft では、Access Control のお客様の多くがこの記事を読んでも明確な移行パスを見つけられず、We understand that many Access Control customers won't find a clear migration path after reading this article. 適切なプランの決定において支援やガイダンスを必要とする可能性があることを認識しています。You might need some assistance or guidance in determining the right plan. 移行シナリオと質問について話し合いをご希望の場合は、このページにコメントを残してください。If you would like to discuss your migration scenarios and questions, please leave a comment on this page.