[Google/ACS]6/1を迎えてAzureACSのGoogle IDプロバイダーはどうなった

2015/04/20をもってGoogleのOpenID 2.0のサポートが終了し、マイクロソフトもAzure ACS（アクセス制御サービス）のGoogle IDプロバイダー設定を6/1までに変更するようにアナウンスを出していました。

関連ポスト）
　GoogleのOpenID 2.0サポート終了による影響いろいろ（Azure ACS編）
　http://idmlab.eidentity.jp/2015/03/googleopenid-20azure-acs.html

　[Google]4/20を迎えてAPIはどうなった？
　http://idmlab.eidentity.jp/2015/04/google420api.html


と、いうことで6月を超えたのでACSがどうなったのかを確認してみました。
結果、まだOpenID 2.0が動いています。結構しぶといです。
（人によって動いていない、という話もあるようなので環境に依存するのかもしれません）

これまで通りの動きです。
１．アプリケーションの認証の設定を行います。

２．実行するとレルムディスカバリ画面がでます。

３．Googleアカウントでログインします。

４．認可をおこないます。

５．アプリケーションからGoogleの属性が取得できています。

このように中々しぶとい状況ですが、MSDNには以下のアナウンスが出ています。
https://msdn.microsoft.com/ja-jp/library/azure/dn927169.aspx

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

ACS側の移行が終わっても次は2017/01/01までに従来のOpenID 2.0で使っていた識別子（nameidentifier）ではなく、OpenID Connectの識別子（subject）を使うようにアプリケーションの改修を行う必要があるようです。
ACS側でのクレームのマッピングを修正する形にしたほうが柔軟な気もしますので、私ならACSのクレームマッピング（規則グループ）を変えますが。。
※この図のnameidentifierとsubjectのマッピングを合わせてあげる形にします。既存アプリケーションはnameidentifier属性を見ているはずなので、OpenID Connect対応した際にGoogleから取得できるようになるsubject属性を出力側のnameidentifier属性にマッピングしてあげればアプリケーションを改修する必要はありません。

まだまだ余裕はありますが、こちらの改修も早めに実施しておいたほうがよさそうですね。

※使えなくなる瞬間どうなるのかを確認したいので、あえてACSの設定を移行せずに残してあるのですが、中々使えなくならないので、今後も引き続きウォッチしていきたいと思います。