先日3回目のTechnical Previewが公開された次期Windows ServerであるWindows Server 2016のActive Directory Federation Services(AD FS)はOpenID Connectに対応しています。
実は前回のTechnical Preview 2からOpenID Connectには対応しており、すでに色々と試してあったのですが、情報をまとめる暇がなくblogに投稿していなかったのですが、とりあえず新しいPreviewも出たので、軽く動作確認をした結果を公開したいと思います。
参考)
[AD FS]Windows Server Technical Preview 2のAD FSファーストレビュー(管理GUI編)
http://idmlab.eidentity.jp/2015/05/ad-fswindows-server-technical-preview.html
尚、インストール方法やASP.NETアプリケーションでの動作についてはVittorioがまとめているのでそちらも参考にしてみてください。
OpenId Connect Web Sign On with ADFS in Windows Server 2016 TP3
http://www.cloudidentity.com/blog/2015/08/21/OPENID-CONNECT-WEB-SIGN-ON-WITH-ADFS-IN-WINDOWS-SERVER-2016-TP3/
今回はとりあえずの動作確認ということで先日Azure Active Directory(Azure AD)のApp Model v2.0の紹介をした際に使ったphpアプリケーションをそのまま使います。
[Azure AD]App Model v2.0を利用して組織内外共用のアプリケーションを開発する
http://idmlab.eidentity.jp/2015/08/azure-adapp-model-v20.html
では、早速試してみます。
◆AD FSへアプリケーションを登録する
新しいAD FSではアプリケーション登録をGUIからできるようになっています。(Windows Server 2012 R2ではOAuthクライアントはPowerShellのコマンドレットからしか登録できませんでしたので、とっても便利です)
新しいメニューとしてApplication Groupsという項目が出来ているので、ここにアプリケーションを登録します。
任意の名前を付けてアプリケーションの種類を選択します。
今回はWebアプリケーションなので、「Server application or Website」を選択します。
client_idが生成されるのでメモしておきます。
また、redirect_uriにこれから作成するアプリケーションのURLを登録しておきます。
次のページでGenerate a shared secretにチェックを入れるとclient_secretが生成されるので、こちらの値もメモしておきます。
後はウィザードを先に進めればアプリケーションの登録は完了です。
◆アプリケーションにAD FSの情報を登録する
次はアプリケーション側にAD FSのエンドポイントの情報や先ほどのclient_id/client_secretを登録していきます。
まず、authorizeおよびtokenエンドポイントを確認するために、.well-known/openid-configurationにアクセスしてみます。
rootにあるべき.well-knownが/adfs以下にあるのは微妙ですが、以下のようなURLになっています。(Technical Preview 2の時にフィードバックしたんですが結局治らないんでしょうねぇ)
https://adfs.example.com/adfs/.well-known/openid-configuration
{ "issuer":"https://adfs.example.com/adfs", "authorization_endpoint":"https://adfs.example.com/adfs/oauth2/authorize/", "token_endpoint":"https://adfs.example.com/adfs/oauth2/token/", "jwks_uri":"https://adfs.example.com/adfs/discovery/keys", "token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic", "private_key_jwt", "windows_client_authentication" ], "response_types_supported": [ "code", "id_token", "code id_token", "token id_token" ], "response_modes_supported": [ "query", "fragment", "form_post" ], "grant_types_supported": [ "authorization_code", "refresh_token", "client_credentials", "urn:ietf:params:oauth:grant-type:jwt-bearer", "implicit", "password", "srv_challenge" ], "subject_types_supported": [ "pairwise" ], "scopes_supported": [ "openid", "profile", "email", "logon_cert", "aza", "vpn_cert", "user_impersonation" ], "id_token_signing_alg_values_supported": [ "RS256" ], "token_endpoint_auth_signing_alg_values_supported": [ "RS256" ], "access_token_issuer":"http://adfs.example.com/adfs/services/trust", "claims_supported": [ "aud", "iss", "iat", "exp", "auth_time", "nonce", "at_hash", "c_hash", "sub", "upn", "unique_name", "pwd_url", "pwd_exp" ], "microsoft_multi_refresh_token":true, "userinfo_endpoint":"https://adfs.example.com/adfs/userinfo" }
これを見ると、
Authorizeエンドポイントは
https://adfs.example.com/adfs/oauth2/authorize/
Tokenエンドポイントは
https://adfs.example.com/adfs/oauth2/token/
であることがわかります。
この情報を前回作ったphpアプリケーションに設定します。
これで準備は完了です。
◆動作確認
早速、アプリケーションにアクセスしてみます。
すると、AD FSのログイン画面に飛ばされますので、ログインします。
ログインに成功するとid_tokenがアプリケーションにわたるので、前回と同じくClaimとValueが取得できます。
いかがでしょうか?
Discoveryの課題はあるものの、かなり手軽に自前のOpenID Provider(OP)を立てることが出来るようになったと思うので、今後はテスト用のOPとしても使えるかも知れませんね。
0 件のコメント:
コメントを投稿