ACS 名前空間の Google OpenID Connect への移行

これは、現在、ID プロバイダーとして Google を使用するアクセス制御サービス (ACS) 2.0 名前空間の所有者向けのトピックです。 ACS は Google の OpenID 2.0 実装を使用してこの機能を提供します。 Google は 2015 年 4 月 20 日までに OpenID 2.0 のサポートを終了する予定です。 ACS 名前空間は、2015 年 6 月 1 日まで Google の OpenID 2.0 実装で引き続き動作します。この時点で、これらの名前空間の移行を完了して Google の OpenID Connect実装を使用する必要があります。または、ユーザーは Google アカウントでアプリケーションにサインインできなくなります。 ACS 名前空間を OpenID Connect に移行してもアプリケーションのダウンタイムは発生しません。 1 つの例外 (下記のメモを参照) を除き、この移行はアプリケーション コードを変更しなくても可能です。 ACS 名前空間を移行して OpenID Connect を使用するようにした後、バックエンドでユーザーの識別子を OpenID Connect 識別子に移行する必要があります。 この移行は、2017 年 1 月 1 日までに完了する必要があります。 バックエンドでコード変更が必要になります。 移行の両フェーズの詳細については、以下の重要なメモを参照してください。

重要

次の重要な日付に注意し、それぞれの日までに必要な操作を完了して、Google を ID プロバイダーとして使用する ACS 名前空間が引き続き確実に機能するようにしてください。

• 2015 年 6 月 1 日 - ACS 名前空間は Google の OpenID 2.0 実装の使用を停止します。 この日までに、ACS 名前空間の移行を完了して、Google OpenID Connect を使用する必要があります。 この日付より前に、移行中に問題が発生した場合は、OpenID 2.0 にロールバックできます。 この日付までに移行されていない名前空間の場合、ユーザーは Google アカウントでサインインできなくなり、Google アカウントの OpenID 2.0 が削除されたことを示すページが表示されます。 Google アカウントでサインイン機能を復元するには、名前空間を移行する必要があります。
  
  ほとんどの場合、アプリケーション コードの変更は必要ありません。 アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して "すべての要求をパススルーする" というルールが存在する場合は、コードの変更が必要になる場合があります。 これは、移行によって Google からの新しい要求の種類 (サブジェクト) が ACS で利用可能になることから、アプリケーションが新しい要求の種類の存在を適切に処理できるようにコードを変更する必要が生じる場合があるためです。 移行を正常に完了させるうえで、アプリケーションで新しい要求の種類を処理する必要はありません。
  
  
• 2017 年 1 月 1 日 – Google の OpenID 2.0 と OpenID Connect の実装では、Google ユーザーを一意に識別するのに、異なる識別子を使用します。 ACS 名前空間の移行後は、現在の OpenID 2.0 識別子と新しい OpenID Connect 識別子の両方をアプリケーションで使用できるようになります。 この日までにバックエンド システムでユーザーの識別子を OpenID Connect 識別子に切り替え、以降は OpenID Connect 識別子のみを使用する必要があります。 これには、アプリケーション コードの変更が必要です。
  
  

Stack Overflow での移行に関する質問を投稿し、"acs-google" でタグ付けすることができます。 できる限り迅速に回答します。

Google のプランの詳細については、 OpenID 2.0 移行ガイドを参照してください。

移行のチェック リスト

次の表は、ACS 名前空間を移行して、Google の OpenID Connect 実装を使用するための手順をまとめたチェック リストです。

手順	[説明]	完了期日
1	Google Developers Console で Google + アプリケーションを作成します。	2015 年 6 月 1 日
2	アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して "すべての要求をパススルーする" というルールが存在する場合は、アプリケーションをテストして、移行の準備が完了していることを確認します。存在しない場合、この手順は省略可能です。	2015 年 6 月 1 日
3	ACS 管理ポータルを使用して Google + アプリケーションのパラメーター (クライアント ID とクライアント シークレット) を指定することで、ACS 名前空間で Google の OpenID Connect 実装を使用するように切り替えます。 2015 年 6 月 1 日までは、移行時に問題が発生しても、OpenID 2.0 にロールバックできます。	2015 年 6 月 1 日
4	バックエンド システムでユーザーの識別子を現在の Google OpenID 2.0 識別子から新しい Google OpenID Connect 識別子に移行します。 これにはコードの変更が必要です。	2017 年 1 月 1 日

移行のチュートリアル

ACS 名前空間を移行して、Google の OpenID Connect 実装を使用するには、次の手順を実行します。

1. Google+ アプリケーションを作成する

   これを行う方法の詳細については、「方法: Google+ アプリケーションを作成する」セクションを参照してください。

2. アプリケーションの移行の準備が完了していることを確認する

   アプリケーションに関連付けられているルール グループの ID プロバイダーとして Google の "すべての要求をパススルーする" ルールがある場合は、「方法: ACS アプリケーションの移行準備状況を確認する」セクションの手順に従って、移行の準備のためにアプリケーションをテストします。 これは、移行すると、Google からの新しい要求の種類 (サブジェクト) が ACS で利用可能になるためです。

   注意

   "パススルーすべての要求" ルールは、 入力要求の種類 と 入力要求の値 が Any と Output 要求の種類 に設定され、 出力要求の値 がそれぞれ [最初の入力要求の種類をパススルー ] と [ パススルー入力要求の値 ] に設定されている規則です。 このルールは、ACS 管理ポータルには、次のように表示されます ([出力要求] 列が [パススルー] に設定されています)。

   

   アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して以前に生成したルールまたは手動で追加したルールが存在する場合は、この手順を省略できます。 このようなケースでは、移行後、新しい要求の種類であるサブジェクトがアプリケーションに送信されないためです。

   これらのオプションの詳細については、「 ルール グループとルール」を参照してください。

3. ACS 名前空間で Google の OpenID Connect 実装を使用するように切り替える

   1. Microsoft Azure の管理ポータルに移動してサインインし、[Active Directory] をクリックします。 移行する必要がある ACS 名前空間を選択してから [管理] をクリックして、ACS 管理ポータルを起動します。

   2. ACS 管理ポータルで、左側にあるツリーの [ID プロバイダー] をクリックするか、[はじめに] セクションの [ID プロバイダー] リンクをクリックします。 [Google] をクリックします。

      

   3. [Google ID プロバイダーの編集] ページで、[OpenID Connect を使用] チェック ボックスをオンにします。

      

   4. [クライアント ID] と [クライアント シークレット] (現在は有効) に、使用する Google+ アプリケーションの該当する値をコピーします。

      

      注意

      この時点で [保存] をクリックすると、ACS 名前空間から送信されたすべての Google ID プロバイダー要求で、Google の OpenID Connect 実装が自動的に使用されます。 ロールバックする必要がある場合は、[OpenID Connect を使用] チェック ボックスをオフにします。 クライアント ID とクライアント シークレットを保存しておくと、後で再利用できます。

   5. [保存] をクリックします。

   6. Google ID でサインインを試行して、OpenID Connect に正しく切り替わっていることを確認します。 サインイン時に問題が発生した場合は、[Google ID プロバイダーの編集] ページに戻り、[OpenID Connect を使用] チェック ボックスをオフにして OpenID 2.0 にロールバックしてください。 ロールバック終了後、Google Developer Console からコピーした名前空間用のクライアント ID とシークレットが正しく入力されていること (入力ミスなどがないかどうか) を確認してください。

4. バックエンド システムでユーザーの識別子を OpenID 2.0 から Open ID Connect に移行する

   2017 年 1 月 1 日までにバックエンド システムのユーザー ID を既存の Google Open ID 2.0 ID から新しい Google OpenID Connect ID に移行する必要があります。 この手順にはコードの変更が必要です。 詳細については、「方法: ユーザーの既存の Open ID 2.0 識別子を新しい OpenID Connect ユーザー識別子に移行する」を参照してください。

方法: Google+ アプリケーションを作成する

次の手順を実行するには、Google アカウントが必要です。あなたが持っていない場合は、1つ https://accounts.google.com/SignUpを取得することができます.

1. ブラウザー ウィンドウで、 Google デベロッパー コンソール に移動し、Google アカウントの資格情報でサインインします。

2. [プロジェクトを作成] をクリックし、[プロジェクト名] と [プロジェクト ID] を入力します。 サービス利用規約のチェック ボックスをオンにします。 [作成] をクリックします。 これでアプリケーションが Google に登録されます。

   

3. 左側のウィンドウで [API 認証&] をクリックします。 次に、[認証情報] をクリックします。 [OAuth] の下にある [新しいクライアント ID を作成] をクリックし、[ウェブ アプリケーション] を選択して、「同意画面を設定」をクリックします。 [製品名] を指定して [保存] をクリックします。

   

4. 左側のウィンドウで [API 認証&] をクリックします。 次に、[API] をクリックします。 [API を見る] の下で Google+ API を探します。 [ステータス] を [ON] に設定します。

   

5. [クライアント ID を作成] ダイアログ ボックスで、[アプリケーションの種類] として [ウェブ アプリケーション] を選択します。

   [ Authorized Javascript Origins ] フィールドで、名前空間の完全修飾ドメイン名 (FQDN) URL (先頭の "HTTPS://" と末尾のポート番号を含む) を指定します。たとえば、 https://contoso.accesscontrol.windows.net:443.

   [ 承認されたリダイレクト URI ] フィールドで、名前空間の完全修飾ドメイン名 (FQDN) URL を含む URI (先頭の "HTTPS://" と末尾のポート番号、続けて "/v2/openid" を指定します。たとえば、 https://contoso.accesscontrol.windows.net:443/v2/openid.

   [クライアント ID を作成] をクリックします。

   

6. [ウェブ アプリケーションのクライアント ID] ページの [クライアント ID] と [クライアント シークレット] の値を書き留めておきます。 ACS 管理ポータルで Google の OpenID Connect 実装を構成するときにこれらの情報が必要になります。

   

   重要

   [Client Secret] は、重要なセキュリティ資格情報です。 安全に保管してください。

方法: ユーザーの既存の Open ID 2.0 識別子を新しい OpenID Connect ユーザー識別子に移行する

Google の OpenID Connect 実装を使用するように ACS 名前空間を正常に移行した後、バックエンド システムのユーザー識別子を現在の OpenID 2.0 識別子から新しい OpenID Connect識別子に移行するには、2017 年 1 月 1 日まで (Google の OpenID 2.0 移行ガイドに従って) 必要があります。

次の表に、ACS 名前空間を移行して Google の OpenID Connect 実装を使用するようにした後、ACS で利用できるようになる Google からの要求の種類を示します。

要求の種類	URI	説明	利用可能なプロトコル
名前識別子	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier	Google から提供される、ユーザー アカウントの一意の識別子。 これは (既存の) OpenID 2.0 識別子です。	OpenID 2.0、OpenID Connect
サブジェクト	https://schemas.microsoft.com/identity/claims/subject	Google から提供される、ユーザー アカウントの一意の識別子。 これは (新しい) OpenID Connect 識別子です。	OpenID Connect
名前	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	Google から提供される、ユーザー アカウントの表示名。	OpenID 2.0、OpenID Connect (下記の注を参照してください)
電子メール アドレス	https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	Google から提供される、ユーザー アカウントの電子メール アドレス	OpenID 2.0、OpenID Connect
ID プロバイダー	https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/IdentityProvider	既定の Google ID プロバイダーを使用してユーザーが認証されたことを証明書利用者アプリケーションに通知する、ACS によって提供される要求。 この要求の値は、ACS 管理ポータルの [ID プロバイダーの編集] ページにある [領域] に表示されます。	OpenID 2.0、OpenID Connect

注意

(登録されている) Google + プロフィールがない Google ユーザーの場合、Name 要求の種類の値は OpenID Connect の Email address 要求の値と同じです。

(以前の) OpenID 2.0 識別子を (新しい) OpenID Connect 識別子にマップすることにより、要求の種類の名前識別子とサブジェクトを使用して、既存のユーザーの一意の識別子をバックエンドで追跡および切り替えることができます。

アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して "すべての要求をパススルーする" というルールが存在する場合、アプリケーションはサブジェクトという要求の種類を自動的に受信し始めます。

アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して以前に生成したルールまたは手動で追加したルールが存在する場合は、サブジェクトという要求の種類を手動で追加する必要があります。 これを行う方法の詳細については、「 ルール グループとルール」を参照してください。

たとえば、上記のように、ルール グループに ID プロバイダーとしての Google に対して以前に生成したルールが存在する場合に、サブジェクトという新しい要求の種類を追加すると、次のように表示されます。

このルール グループを使用するアプリケーションでは、他の要求の種類に加えて、サブジェクトという要求の種類も受信するようになります。

注意

2017 年 1 月 1 日を過ぎると Google は識別子のマッピングのサポートを停止します。ACS は、同じ OpenID Connect ユーザー識別子を使用して、NameIdentifier と Subject の両方の要求の種類を設定します。

方法: ACS アプリケーションの移行準備を確認する

1 つの例外を除き、アプリケーション コードを変更しなくても、ACS 名前空間を移行して Google の OpenID Connect 実装を使用できます。 例外は、アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して "すべての要求をパススルーする" というルールが存在する場合です。 このようなケースでは、移行後、新しい要求の種類 (サブジェクト) が、アプリケーションに自動的に送信されるためです。

このセクションでは、移行で影響を受けるすべてのアプリケーションが、新しい要求の種類を処理する準備ができていることを確認するための、推奨される変更とテストの手順について大まかに説明します。

ここでは、ユーザーが ns-contoso という名前の ACS 名前空間の所有者で、運用環境のアプリケーションが ProdContosoApp という名前であると仮定します。 また、このアプリケーションでは ID プロバイダーとして Google を使用し、"すべての要求をパススルーする" ルールが Google に対して有効になっているとします。

セットアップ

1. 最初に、Microsoft Azure の管理ポータルに移動してサインインし、[Active Directory] をクリックします。 ACS 名前空間 (ns-contoso) を選択してから [管理] をクリックして ACS 管理ポータルを起動します。

2. ACS 管理ポータルで、左側にあるツリーの [証明書利用者アプリケーション] をクリックするか、[はじめに] セクションの下の [証明書利用者アプリケーション] リンクをクリックします。 運用環境のアプリケーション (ProdContosoApp) をクリックします。

3. ProdContosoApp のプロパティを書き留めます。この情報は後で必要になります。

   

4. [ルール グループ] の下の [ProdContosoApp の既定のルール グループ] をクリックして、"すべての要求をパススルーする" ルールが Google に対して有効になっていることを確認します。

   

手順 1: 運用 ACS 名前空間にアプリケーションのテスト インスタンスをセットアップする

アプリケーションのテスト インスタンス TestContosoApp を別のルート URI に設定します。たとえば、 https://contoso-test.com:7777/. ns-contoso 名前空間に証明書利用者アプリケーション (証明書利用者アプリケーション) として登録する必要があります。

1. ACS 管理ポータルで、左側にあるツリーの [証明書利用者アプリケーション] をクリックするか、[はじめに] セクションの下の [証明書利用者アプリケーション] リンクをクリックします。 次に、[証明書利用者アプリケーション] ページの [追加] をクリックします。

2. [証明書利用者アプリケーションの追加] ページで、次の手順を実行します。

   • [名前] に、テスト アプリケーションの名前を入力します。 ここでは TestContosoApp です。

   • [モード] で、[手動で設定を入力する] を選択します。

   • [領域] にテスト アプリケーションの URI を入力します。 ここにある https://contoso-test.com:7777/.

   • ここでは、[エラー URL (省略可能)] は空白のままにできます。

   • [トークン形式]、[トークンの暗号化ポリシー]、[トークン有効期間 (秒)] の各プロパティ、および [トークン署名の設定] セクションには、ProdContosoApp に使用したのと同じ値を使用します。

   • [ID プロバイダー] として [Google] を選択していることを確認します。

   • [ルール グループ] の下で [新しいルール グループの作成] を選択します。

   

3. ページの下部にある [保存] をクリックします。

手順 2: Google の OpenID Connect実装を使用するように名前空間が移行された後にアプリケーションが受け取る ACS トークンの形式をシミュレートするルール グループを作成する

1. ACS 管理ポータルで、左側にあるツリーの [ルール グループ] をクリックするか、[はじめに] セクションの [ルール グループ] リンクをクリックします。 [ルール グループ] ページで [追加] をクリックします。

2. [ルール グループの追加] ページで、新しいルール グループの名前 (ManualGoogleRuleGroup など) を指定します。 [保存] をクリックします。

   

3. [ルール グループの編集] ページで、[追加] リンクをクリックします。

   

4. [要求ルールの追加] ページで、以下の各値を指定していることを確認してから [保存] をクリックします。 この操作で Google に対する "すべての要求をパススルーする" ルールが生成されます。

   • [If] セクション:

     • [ID プロバイダー] は [Google] です。

     • [入力要求の種類] の選択は、[任意] です。

     • [入力要求の値] は [任意] です。

   • [Then] セクション:

     • [出力要求の種類] は [最初の要求の種類をパススルー] です。

     • [出力要求の値] は [最初の入力要求の値をパススルー] です。

   • [ルールについて] セクション:

     • [説明 (省略可能)] は空白のままにします。

   

5. [ルール グループの編集] ページで、[追加] リンクをもう一度クリックします。

6. [要求ルールの追加] ページで、以下の各値を指定していることを確認してから [保存] をクリックします。 これにより、新しい要求の種類であるサブジェクトの追加をシミュレートする、Google に対する "静的な" 要求ルールが生成されます。サブジェクトは、移行後に Google がアプリケーションに送信する新しい OpenID Connect ユーザー識別子です。

   • [If] セクション:

     • [ID プロバイダー] は [Google] です。

     • [入力要求の種類] の選択は、[任意] です。

     • [入力要求の値] は [任意] です。

   • [Then] セクション:

     • [出力要求の種類] は [種類の入力] です。 フィールドに「.」と入力します https://schemas.microsoft.com/identity/claims/subject。

     • [出力要求の値] は [値の入力] です。 フィールドに、「123456」と入力します。

   • [ルールについて] セクション:

     • [説明 (省略可能)] は空白のままにします。

   

7. [ルール グループの編集] ページで [保存] をクリックします。

手順 3: 新しいルール グループをアプリケーションのテスト インスタンスに関連付ける

1. ACS 管理ポータルで、左側にあるツリーの [証明書利用者アプリケーション] をクリックするか、[はじめに] セクションの下の [証明書利用者アプリケーション] リンクをクリックします。 次に、[証明書利用者アプリケーション] ページの [TestContosoApp] をクリックします。

2. [証明書利用者アプリケーションの編集] ページの [認証の設定] セクションで [ManualGoogleRuleGroup] を選択して [保存] をクリックします。

   

これで、テスト アプリケーションに対する Google のすべてのサインイン要求に、新しい要求の種類が含まれるようになります。

手順 4: アプリケーションがサブジェクト要求の種類の追加を処理できることを確認するテスト

アプリケーションをテストして、アプリケーションが新しい要求の種類 (Subject) の存在を適切に処理できることを確認します。 通常、適切に記述されたアプリケーションは、トークンに追加された新しい要求の種類に対して堅牢である必要があります。 問題を特定して解決します。 必要に応じて、「方法: ユーザーの既存の Open ID 2.0 識別子を新しい OpenID Connectユーザー識別子に移行する」セクションに従って、ユーザー識別子マッピングを実行することもできます。

手順 5: 運用環境を移行する

運用環境のアプリケーション (ProdContosoApp) を再ビルドしてデプロイします。 移行のチュートリアルの手順に従って、名前空間 (ns-contoso) を移行して、Google の OpenID Connect実装を使用します。 ProdContosoApp が想定どおりに動作していることを確認します。