Quantcast
Viewing all 771 articles
Browse latest View live

[AD FS]OpenID Connectに対応した次期AD FSを試す(UserInfo編)

こんにちは、富士榮です。

先月のポストでは、Windows Server 2016のTechnical Preview 3に搭載される新AD FSのOpenID Connectへの対応の概要を紹介しました。

 [AD FS]OpenID Connectに対応した次期AD FSを試す
 http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html


また、同じく既にOpenID Connectに対応しているAzure Active Directory(Azure AD)について、userinfoエンドポイントを使ってユーザ情報を取得する方法についても紹介しました。

 [Azure AD]OpenID ConnectのUserInfoエンドポイントを使ってユーザ情報を取得する
 http://idmlab.eidentity.jp/2015/08/azure-adopenid-connectuserinfo.html



と、いうことで今回は新AD FSのUserInfoエンドポイントよりユーザ情報を取得できるかどうか確認して見たいと思います。

◆エンドポイントを確認する

前回同様、/adfs/.well-known/openid-configurationをGETして各種エンドポイントの情報を確認すると、UserInfoエンドポイントは
 "userinfo_endpoint":"https://adfs.example.com/adfs/userinfo"
であることがわかります。

別の方法としては、AD FSの管理コンソールから登録されているエンドポイント一覧を確認することもできるので、コンソールアクセスできる場合はそちらから確認しても大丈夫です。



◆クライアント登録する

次に、UserInfoを取得するクライアントを登録します。
新しいAD FSでは、「Application Groups」メニューよりアプリケーション・グループを作成し、その中にアプリケーション(クライアント)を登録します。

今回はダミークライアントでOKなので、以下のパラメータで登録しました。
・Template:Standalone applications - Server application or Website
・Redirect URI:http://localhost
・Application Credentials:Generate a shared secret

以下、登録ウィザードの画面です。




◆UserInfoへアクセスするためのアクセストークンを取得する

code flowでアクセストークンを取得していきますので、まずは認可エンドポイントへアクセスし、認可コードを取得します。
UserInfoエンドポイントからプロファイル情報やメールアドレスなどの情報も取得したいので、scopeにはopenid profile emailを指定します。

https://adfs.example.com/adfs/oauth2/authorize/
client_id=2155e727-7560-4e2f-985d-274a91691af9&
response_type=code&
redirect_uri=http%3A%2F%2Flocalhost&
scope=openid%20profile%20email&
state=12345


結果、Redirect URIに指定したアドレスにクエリパラメータとして認可コードが返ってきます。

http://localhost/?
code=fcCKuMdQjUmSBo8l1mZWFA.XE6TFE7G0ggOAPXOTd4Eag7n30A.ENQ1pomEwEqzzWB_-q3HhwKX0pYq0mAuN-o_6qa4JAiMD8lWIbvaxThqlbkE8SAkZ4Ik0RfbuzdqHfzEjXSj_U513DgjLyq5VmPt34nLmcs9BhpoBjZJY84b-0rmiWmCe8lbHZHb1ENQy7KbytmDwC7j_fRjzXDkAcr9ReeFkQPl6PCe7mSOTvGOEpi04YrzDeY6tk_YKMPpRv8d2YnKd4R3qMAUKCfeNfhgOdua8xTcVDj0d-9bDVIW5GKD6Agydu1xsnTv3Mzm_UirAWMTpRQtpbtRJZUt3fdNSQAxpgst3H7qbG3Iy7bmfYb2FpxmP02BMHikr36vS09tTk6KnA&
state=12345


このcode=xxxの部分が認可コードです。


次に取得した認可コードをトークンエンドポイントにPOSTしてアクセストークンを取得します。
https://adfs.example.com/adfs/oauth2/token
grant_type: authorization_code
client_id: 2155e727-7560-4e2f-985d-274a91691af9
code: fcCKuMdQjUmSBo8l1mZWFA.XE6TFE7G0ggOAPXOTd4Eag7n30A.ENQ1pomEwEqzzWB_-q3HhwKX0pYq0mAuN-o_6qa4JAiMD8lWIbvaxThqlbkE8SAkZ4Ik0RfbuzdqHfzEjXSj_U513DgjLyq5VmPt34nLmcs9BhpoBjZJY84b-0rmiWmCe8lbHZHb1ENQy7KbytmDwC7j_fRjzXDkAcr9ReeFkQPl6PCe7mSOTvGOEpi04YrzDeY6tk_YKMPpRv8d2YnKd4R3qMAUKCfeNfhgOdua8xTcVDj0d-9bDVIW5GKD6Agydu1xsnTv3Mzm_UirAWMTpRQtpbtRJZUt3fdNSQAxpgst3H7qbG3Iy7bmfYb2FpxmP02BMHikr36vS09tTk6KnA
redirect_uri: http://localhost
client_secret: 6MsbJZTFr2ZEC-BNb8c6rRdIolxCm_c1HgA5hHFQ


すると、アクセストークン、リフレッシュトークン、IDトークンが返ってきます。
{
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0OnVzZXJpbmZvIiwiaXNzIjoiaHR0cDovL3RwMy5hZGZzMjAubmV0L2FkZnMvc2VydmljZXMvdHJ1c3QiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXBwdHlwZSI6IkNvbmZpZGVudGlhbCIsImFwcGlkIjoiYTgyNDg4NWItYzVkOS00ZDNhLWI2OWEtN2M4OTZiODBhZjhkIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXV0aF90aW1lIjoiMjAxNS0wOS0yNlQwODo0MDowNi41NjRaIiwidmVyIjoiMS4wIiwic2NwIjoib3BlbmlkIiwic3ViIjoiajhtMUZBT3hVWE5ZeFpxZHMwYkVNZG9MM1gybTZLcFA2Wkt4elZQYW42TT0ifQ.fNmEOEARGbWURRoRazcW36jgtw0a3h4i7Z5--UC9nLB0mFFjZVxcJe4-1hhaCQExn04oUD9-HXXI4BFKkbctWNJJKUo8kT4kAn_Uj8J10INYUAJA5veKis1MdUIZ7glpEfMzEvzjrTGnMhN4v4y_CEzziU0LB1nGogozOkDOD3Y6gfaUJbrOv4V8lbmjm9cuMNDRs6ZEwGf5aqc2ChAbWw2icqW3XBwTnUR_X0je2LKmwjcljY145-fybEgUbFANbAnSSC8WOcS-KGOKzlqIbf3AxQ1PaetMGAb02N25KM36b24I9yzDPDs8EmKgL4mSfjTPHxnUWCu7UB4wMcfvIw",
"token_type":"bearer",
"expires_in":3600,
"resource":"urn:microsoft:userinfo",
"refresh_token":"5dC-njXY426ezdn5gD3F0I303XUf7otp3hxwUTfPuXgAAQAAknmNeJNokXbBjoJ8_0szNQ6IyCQ0jM7VerjRPZl-fnpGzMz7eT6p6CZ2IUh2o_uv09DZZkLCKemeEdZakCQ84goI6drbRYXuCGCgjeZ4OXXJWshjLrO94qWD7hLeVxScBna7ZKDik2zU5ep4yQxljkIGcHzH4csh9cumG_Yr_SntMDdvXYGkVhT3DDf68hKn_fqWTCYygN5cRol3OjlX5ipVL-8x73ndaaqdrYfNVtacjIJmdgqm4qmfOi89kjajlt3VLXAqWfkdwRupLbmvQ4uXunriR9tYq-67zJcok2SD1m4Us9qeS9PEKLdjIeKzQusUKaO8rH0yYp4D3sZamHAFAABfIdD674BFeJV6xPKn3Rk7NmrZeSPKi5GY70mzUy0qjIwx93kKGV83INvNgkB608h5ZR4m-VrNMjxUZjIF6cCtxcrz85cjcCqj99W0pxXm_5-GzfBN1lUxhejAuWZxX-3LK05yTiWoSvSoqJUYDE2tyHQ4kX42dWqWv1QerfOo54QZQ72H8DWNNvxhAslDFrnQlJr9Y-h5ppaPpU2F9ViBKlJx6d0R8gIZs6ZJfgkgMG4X8Lw0K3OuM4vHBfVmBSSEAqCNMm8SLwI4i0Y6hb9G-WXGjd2c0SvgsOBWNvptWEdD571ggr2RUgyYqPHP5Aj3368mwKoHiWfdDR07YCIlk889lLhnA3kD2LItaYGgTuJ65N2kpiPoyc6EaTo-Nr961ERjxz9ajZijD69Ck6z6VRkqbphfhNXEVMop2ZJLW5dkXDiFoBMuM0oV95hjuwgBOHwUfTfM0RkjjEauARSN4DjV3enuWfIUKTCGFo-meI_Jt2c5mQ80U-7Fxfy2RxhbuJgXRa37I4YEtbeMBptu_o_vSvSqF__Z9fgpuWXYLJfpTfi0VI5k9GfJvmZm7zisyyRsEh1mWlDJdgE9hwl6GCIaoAd2kjrJmPnnNJrguOvwAXLCZVsY6IQxk8OsUjnZQ9a1OgdrAgHE3W0LRMPi6qEvNkKKlQxIoV4K0gyXrWnx752_7LCHfpGmKBG6Ot0FhVrw5z1JcAClBSv_4gWuKpkvXu6x8Ne4Km6dzmsVWsN7GyX3M9GUsW05CDASJ9KAbGbKNPeQpp8FBFdnooULAcb0KqGtPBDIu4dazZtpFMK2l9le2kfvaJOB87S1wod5CsR2ms5A6EDKcMOaXVmMl1H5MR_Mdae1057KulOze0HtQoebKRZHJHZL5DWE0r7qKUtINxz1LQ2eMAitcslcJCpD_j09YtOpkZIIhJzjx7kyisgv5yEoIh_qOTvMAr97wnewU63ZgYAHUdGPVBgOFKKuew_I0bIOIj4ZKk3qpXFdzdpYVXewy9VIffOkISlszUyjhL6xnU_W26M0YfWu4KDOpysTSF_rvPJXfix4eRc0CdeARCiYx4SJHzz8IzDEkCZwdy9zcpfufGphEfM3Pixey00xT5v0pACNMhvfBFD4-jY26iZbjMdiXr9hLlH1-GkOzkuNartjNiCN-vms3ris4Ywau3POuSoKCfmxLCzGORCw5t2K7AhQ85dVb6b8dqqcXD4-LsNOxgYWfGD4r064X1ZEOzhVZBBmttp0dipuV84ZQnc6gkc7AugipBYGv_T-UMsU8jyw99Y-hPCx0ZpQRB97T_LZz9yVqDqPGFFM1-72RMhJK6yK_smFXvd8rTXuKFewRhaRNa0I5ezBTcxm--DoHjBmyOycrd9O_3NddIMoVAXGQt9IS6QmoHyJGxF2rMFXlAidew2Ws_BojU6XSRBbRh91o-y5oZ94PvviDqxI6DtJFZpKNrNKBwlbUregs8cmHsZiTj3MgplzDJOf02aygRJ8is-XvQB--UWS4lMLrUIV7c40BlpsTuC2KDQUPx-LKcoUG0TqGcqG4bj2T4uzxr9oY5ZH5n8YSW2ZVnVXhvh-CyP-uVdfRULx9ZCBDGT4QD4h_r5dw1rSU72_XBCDzVGcWOEGx1Rfnm3v4uyjHCr0NZQtznOWf1-gBdQ_4GhUsiJsU8Wdev6J7Ul3733hm8o78I7GSbfr1rRtT9_UjX7cmrViHMPZr5uzGge7y4EAMf-bV6gse91mx_0z-sCriEjr8Ull7rsQedN5hlTbuDOHkc_jVp0jvcK7vlGVtJmSfsUZeMrGKxqGKkEYzb3Xn4OweYiCwGhx1ATCV-xAPTBHAGtyMX4e47Q.YEBU6-rJ4Ah-VZXWpoXirCIynU_JT2Ox5UMvD1CZnV1y7MuCib2uKFmwymSnk2iJe5FY4CfG-4AIK9Di4l9n82viNxRvcXh5mKD6wOd4xvh92N3_odYry72HXe6PtJa42gp5zdTDgoLkyXmJkyO04oguyuUhvbDK7VDoJQmAolCOG4IOM7LqvrvKRPs34uzFUrMlko0dLOCgECTT1XvzIigEb23HNQpOBJybwHw6zcpfkvNH-Lqa-70qbo9Rkjb3G9A9hb1G_IojZie3vaYGmwVKNwXKg9Y7p7wzgrnwWEyDKt1JdoMcVCXho7bvx-SpAGgdqWWMR11zDtR5OR4e8g",
"refresh_token_expires_in":28799,
"scope":"openid",
"id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCIsImtpZCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJhODI0ODg1Yi1jNWQ5LTRkM2EtYjY5YS03Yzg5NmI4MGFmOGQiLCJpc3MiOiJodHRwczovL3RwMy5hZGZzMjAubmV0L2FkZnMiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXV0aF90aW1lIjoxNDQzMjU2ODA2LCJzdWIiOiJqOG0xRkFPeFVYTll4WnFkczBiRU1kb0wzWDJtNktwUDZaS3h6VlBhbjZNPSIsInVwbiI6Im5mdWppZUB0cDMuYWRmczIwLm5ldCIsInVuaXF1ZV9uYW1lIjoiVFAzXFxuZnVqaWUiLCJwd2RfZXhwIjoiNTE5ODk5In0.iCRZlDKci_QxsCEY-m_AwKeZCO1wj95SRSZNyxslaQheMt2oOG9gh8cueFBowOeGRxg76vUbjqt8qIpH5JkV1iFBevTLmD8m_JggTdkL_n2WO-zGzVLKV48li6zL2y2VnakNwgERKaH9ccv_A3p81oPZf9coPJtphA0Z8CjM5xMTOJNpK3Oi_E7PtSw0ft8s1WBPKvA-TEvDqRVbiBwTuucazjF4rDdoIvAAMvr2PZfP3Rz-DzdEfprN7DLrKGtawQIzr3G2vhYIKaCZjC4kX4ys-MBK7dVJKZ4w2fT86iYVrOrkem6e4OCCiZFhgbDKLoo9y5VZAYt5eYoVDzNDvQ"
}



ん?なぜかscopeがopenidのみになってしまっていますね。。。
いやな予感しかしません。


◆UserInfoエンドポイントへアクセスする

取得したアクセストークンをAuthorizationヘッダに入れてGETします。
https://adfs.example.com/adfs/userinfo
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0OnVzZXJpbmZvIiwiaXNzIjoiaHR0cDovL3RwMy5hZGZzMjAubmV0L2FkZnMvc2VydmljZXMvdHJ1c3QiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXBwdHlwZSI6IkNvbmZpZGVudGlhbCIsImFwcGlkIjoiYTgyNDg4NWItYzVkOS00ZDNhLWI2OWEtN2M4OTZiODBhZjhkIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXV0aF90aW1lIjoiMjAxNS0wOS0yNlQwODo0MDowNi41NjRaIiwidmVyIjoiMS4wIiwic2NwIjoib3BlbmlkIiwic3ViIjoiajhtMUZBT3hVWE5ZeFpxZHMwYkVNZG9MM1gybTZLcFA2Wkt4elZQYW42TT0ifQ.fNmEOEARGbWURRoRazcW36jgtw0a3h4i7Z5--UC9nLB0mFFjZVxcJe4-1hhaCQExn04oUD9-HXXI4BFKkbctWNJJKUo8kT4kAn_Uj8J10INYUAJA5veKis1MdUIZ7glpEfMzEvzjrTGnMhN4v4y_CEzziU0LB1nGogozOkDOD3Y6gfaUJbrOv4V8lbmjm9cuMNDRs6ZEwGf5aqc2ChAbWw2icqW3XBwTnUR_X0je2LKmwjcljY145-fybEgUbFANbAnSSC8WOcS-KGOKzlqIbf3AxQ1PaetMGAb02N25KM36b24I9yzDPDs8EmKgL4mSfjTPHxnUWCu7UB4wMcfvIw


やはりsubしか返ってきません。profileとかemailがscopeから消えてしまっているからですかね。。
{"sub":"j8m1FAOxUXNYxZqds0bEMdoL3X2m6KpP6ZKxzVPan6M="}



AD FSの管理コンソールから定義されているscope一覧を見るとちゃんとprofileやemailもあるんですけどね。


まだTechnical Preview版なので、こんなものなのかも知れません。今後の進化に期待ですね。


[SCIM] SCIM2.0がRFCに!

こんにちは、富士榮です。

プロビジョニングの標準仕様策定を目指して2011年にver1.0、2012年にver1.1がリリースされたSCIM(System for Cross-domain Identity Management)ですが、ついにver2.0がRFC化されました。

対象となったのは、以下の3つです。

RFC7642(http://www.rfc-editor.org/rfc/rfc7642.txt)
  System for Cross-domain Identity Management:
  Definitions, Overview, Concepts, and Requirements

RFC7643(http://www.rfc-editor.org/rfc/rfc7643.txt)
  System for Cross-domain Identity Management:
  Core Schema

RFC7644(http://www.rfc-editor.org/rfc/rfc7644.txt)
  System for Cross-domain Identity Management:
  Protocol

ちなみに、OpenIDファウンデーション・ジャパンのEnterprise Identity Working Group(EIWG)ではエンタープライズにおけるOpenID ConnectやSCIMの利用促進を目指し、「OpenID ConnectとSCIMのエンタープライズ利用ガイドライン」を2013年に公開しており、新版を10月にも公開する予定となっていますので、こちらも期待しておきましょう。

 OpenIDファウンデーション・ジャパン エンタープライズ・アイデンティティ・ワーキンググループ『OpenID ConnectとSCIMのエンタープライズ利用ガイドライン』を公開
 https://www.openid.or.jp/working-group/2013/12/openid-openid-connectscim.html


最近では、Oracle Identity ManagementやExgenのLDAP ManagerなどSCIMに対応したプロビジョニング製品も出てきていますし、Ping ONE / Ping FederateなどSCIMを使ってID管理を行うIdP製品やサービスも出てきているので、今後さらに普及していくと思われますので、要チェックですね。

[お知らせ]IdM実験室別館をオープンしました

こんにちは、富士榮です。

既に一部ソーシャルメディアではお知らせしていたり、現在@ITで連載しているIDaaSに関する記事からもリンクを張っていますが、MSDNの動画投稿サイトであるChannel9に「IdM実験室別館」をオープンしました。


https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie


とりあえずは@ITの記事に連動する形でAzure Active Diretory(Azure AD)に関する以下のプレゼンテーションと実際の動作のデモンストレーションを動画で公開しています。


  • Azure AD アプリケーション連携(1) ~ アプリ連携の概要
  • Azure AD アプリケーション連携(2) ~ Google Apps との連携
  • Azure AD アプリケーション連携(3) ~ Google への ID配信
  • Azure AD アプリケーション連携(4) ~ ASP.NET アプリとの ID 連携
  • Azure AD アプリケーション連携(5) ~ グループベースのユーザー割り当て
  • Azure AD アプリケーション連携(6) ~ ユーザーの動的な割り当て
  • Azure AD アプリケーション連携(7) ~ ルールベースのアクセス制御



今後は、記事連動以外のトピックスについても取り上げていきたいので、文字ばっかりじゃ良くわからない、とか自分でやるのは面倒だから動いているところがみたい!!というリクエストなどあれば、コメントを頂ければコンテンツ化をしていければと思います。


参考)現在連載中の@ITの記事

企業のID管理/シングルサインオンの新しい選択肢「IDaaS」の活用:
 第1回 もはや企業のID管理で避けては通れない「IDaaS」とは?
 http://www.atmarkit.co.jp/ait/articles/1508/07/news034.html

 第2回 IDaaSの実装をAzure ADで理解する(前編)
 http://www.atmarkit.co.jp/ait/articles/1509/30/news051.html

 第3回 IDaaSの実装をAzure ADで理解する(後編)
 http://www.atmarkit.co.jp/ait/articles/1510/05/news013.html

[AD FS]Azure ADに引き続きAD FSもOpenID Connect適合性認定

こんにちは、富士榮です。

本blogでも紹介してきたとおり、Azure Active Directory(Azure AD)に引き続き、次期Active Directory Federation Services(AD FS)もOpenID Connectに対応していますが、OpenID Foundationによる適合性を認定されたとの発表がありました。



 Active Directory Federation Server gains OpenID Certifications!
 http://blogs.technet.com/b/ad/archive/2015/10/08/active-directory-federation-server-gains-openid-certifications.aspx

 OpenID Foundationの認定ページ
 http://openid.net/certification/

 ここを見るとAzure Active DirectoryおよびAD FS for Windows10(Windows Server 2016のことだと思うので表現はどうかと思いますが)が認定されていることがわかります。


参考)本blogでの検証結果
 [AD FS]OpenID Connectに対応した次期AD FSを試す
 http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html

 [AD FS]OpenID Connectに対応した次期AD FSを試す(UserInfo編)
 http://idmlab.eidentity.jp/2015/09/ad-fsopenid-connectad-fsuserinfo.html


検証結果を見るとまだまだな点もありますが、このようなオープンな仕様に準拠していることがわかる形で公表されると安心できますね。

ちなみに、AD FSがLibertyのSAML2.0の相互運用性テストに合格したのは2009年でした。

 クラウド時代のID管理へ? ~ADFS2.0がSAML2.0相互運用性テストにパス~
 http://idmlab.eidentity.jp/2009/10/idadfs20saml20.html

もう6年も前なんですね。
(6年前からやってることが変わらないこのblogもアレですが)

[Azure AD]Azure AD B2Cを利用してソーシャル認証するアプリケーションを開発する

こんにちは、富士榮です。

先日Public Previewが公開されたAzure Active Directory B2C(Azure AD B2C)を使うと、これまでAccess Control Service(ACS)が担ってきたコンシューマ・アイデンティティ・プロバイダを使った認証をサポートするアプリケーションを開発することができます。

参考)
・公式Blogでの発表
 Azure AD B2C and B2B are now in Public Preview!
 http://blogs.technet.com/b/ad/archive/2015/09/16/azure-ad-b2c-and-b2b-are-now-in-public-preview.aspx

・安納さんによる世界一はやいまとめ資料
 https://docs.com/junichia/8538/azure-ad-b2c-preview-v0-6


ASP.NET IdentityやACSでも同じようなことが出来るので、今後どのようにすみ分けていくのかは要注目ですが、まずは手始めにOpenID Connectに対応しているものも、そうでないものも含め各種IdPをAzure AD B2Cを経由することによりOpenID Connect対応のIdPにすることができる、という点でアプリケーション開発者から見ると利点があると思われます。

早速、これまでAzure ADやAD FSのOpenID Connect対応を検証するために書いたコードをどこまで再利用できるのか?を確認してみたいと思います。

参考)過去のポスト
 [Azure AD]App Model v2.0を利用して組織内外共用のアプリケーションを開発する
 http://idmlab.eidentity.jp/2015/08/azure-adapp-model-v20.html

 [AD FS]OpenID Connectに対応した次期AD FSを試す
 http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html


◆OpenID Connect関連のパラメータを確認する
まずは、Azure AD B2CのOpenID Connect関連パラメータをwell-known/openid-configurationエンドポイントから覗いてみます。
エンドポイントアドレスは、
https://login.microsoftonline.com/{tenant}.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_signin
です。


{
"issuer": "https://login.microsoftonline.com/xxxxxx/v2.0/",
"authorization_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_signin",
"token_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_signin",
"end_session_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/logout?p=b2c_1_signin",
"jwks_uri": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/discovery/v2.0/keys?p=b2c_1_signin",
"response_modes_supported": [
"query",
"fragment",
"form_post"
],
"response_types_supported": [
"code",
"id_token",
"code id_token"
],
"scopes_supported": [
"openid"
],
"subject_types_supported": [
"pairwise"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post"
],
"claims_supported": [
"emails",
"sub",
"idp"
]
}



これはマイクロソフトの悪い癖だと思うんですが、エンドポイントのアドレスにクエリパラメータをつけるのはちょっと頂けない感じですね。。。
実際にアプリケーションを開発する時にはConfiguration情報から取得したエンドポイントアドレスに他のパラメータをつけて処理を行うわけなので、クエリパラメータが2重についてエラーが起きてしまいます。。。
ここはAzure AD B2Cを使ったアプリケーション開発をする際の注意点ですね。


◆クライアント登録を行う
Azure AD B2Cの管理は新しいAzureポータルから行います。
このあたりの細かい設定方法は別の機会に紹介したいと思いますが、といあえずクライアント(アプリケーション)を登録してclient_idとclient_secretを取得しないと始まりませんので、まずは登録します。



◆アプリケーションを開発する
既存のOpenID Connect/RP(アプリケーション)のコードの再利用性を確認するのが目的なので、以前のポストで使ったPHPアプリケーションを再利用します。

完全互換であれば、
・authorization_endpoint
・token_endpoint
・client_id
・client_secret
・redirect_uri
を今回の環境に合わせて修正すればそのまま動くはずです。

早速修正してみました。


これで実行すると、、、404エラー来ました・・・。
先ほどのエンドポイントアドレスにクエリパラメータが入っているので変なエンドポイントへアクセスしてしまっています。
仕方がないので、認可エンドポイントへのGETリクエストのパラメータを'?'ではなく、'&'で連結します。



基本はこれで動くようになりましたが、id_tokenのフォーマットが微妙に違うようです。
具体的にはemailsクレームがマルチバリューで返ってくるので、jsonのパースをちゃんとしてあげないといけません。
例えばGoogle+だと以下のようなid_tokenがかえってきます。

{
"exp": 1444322056,
"nbf": 1444318456,
"ver": "1.0",
"iss": "https://login.microsoftonline.com/xxxx/v2.0/",
"acr": "b2c_1_signin",
"sub": "Not supported currently. Use oid claim.",
"aud": "60a26a60-1c47-497c-b4c3-5cea0f1bc293",
"iat": 1444318456,
"auth_time": 1444318456,
"idp": "google.com",
"emails": [
"xxx@gmail.com"
]
}



◆実行してみる
今回はGoogle+およびFacebookを使ってサインインする様にAzure AD B2Cを構成してみました。
それぞれの実行結果を確認してみます。

まずはアプリケーションへアクセスするとAzure AD B2Cのログイン画面へ遷移します。
デフォルト画面なので恐ろしくシンプルな画面です。
ここにあらかじめ設定しておいたアイデンティティ・プロバイダが出てきます。



初回アクセス時は認可の確認が求められますので許可すると、クレームが取得できます。
(ちなみに本当の初回はソーシャルIDでサインアップする必要があります。こちらの手順は別途紹介します)

Google+でサインインした場合



Facebookでサインインした場合




どちらの場合もsubが取得できないんですね。。。
今後にいろいろと期待です。


参考:今回利用したコード)

<?php

// パラメータ類
$authorization_endpoint = 'https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_signin';
$token_endpoint = 'https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_signin';
$client_id = '60a26a60-1c47-497c-b4c3-5cea0f1bc293';
$client_secret = 'xxxx';
$redirect_uri = 'https://xxxx.azurewebsites.net/index.php';
$response_type = 'code';
$state = 'hogehoge'; // 手抜き
$nonce = 'fogafoga'; // 手抜き

// codeの取得(codeがパラメータについてなければ初回アクセスとしてみなしています。手抜きです)
$req_code = $_GET['code'];
if(!$req_code){
// 初回アクセスなのでログインプロセス開始
// GETパラメータ関係
$query = http_build_query(array(
'client_id'=>$client_id,
'response_type'=>$response_type,
'redirect_uri'=> $redirect_uri,
'scope'=>'openid',
'state'=>$state,
'nonce'=>$nonce
));
// リクエスト
header('Location: ' . $authorization_endpoint . '&' . $query );
exit();
}

// POSTデータの作成
$postdata = array(
'grant_type'=>'authorization_code',
'client_id'=>$client_id,
'code'=>$req_code,
'client_secret'=>$client_secret,
'redirect_uri'=>$redirect_uri
);

// TokenエンドポイントへPOST
$ch = curl_init($token_endpoint);
curl_setopt( $ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt( $ch, CURLOPT_POSTFIELDS, http_build_query($postdata));
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
$response = json_decode(curl_exec($ch));
curl_close($ch);

// id_tokenの取り出しとdecode
$id_token = explode('.', $response->id_token);
$payload = base64_decode(str_pad(strtr($id_token[1], '-_', '+/'), strlen($id_token[1]) % 4, '=', STR_PAD_RIGHT));
$payload_json = json_decode($payload, true);

// 整形と表示
print<<<EOF
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
<title>Obtained claims</title>
</head>
<body>
<table border=1>
<tr><th>Claim</th><th>Value</th></tr>
EOF;
foreach($payload_json as $key => $value){
if($key == "emails"){
foreach($value as $mail_key => $mail_value){
print('<tr><td>'.$key.'</td><td>'.$mail_value.'</td></tr>');
}
}else{
print('<tr><td>'.$key.'</td><td>'.$value.'</td></tr>');
}
}
print<<<EOF
</table>
</body>
</html>
EOF;

?>

[MIM]同一サーバにMIM Service/PortalとSynchronization Serviceを同居する際の注意点

こんにちは、富士榮です。

本番環境ではMicrosoft Identity Manager(MIM)Synchronization ServiceとMIM Service/Portalは分離すると思うので、あまり問題になることはありませんが、開発や検証環境では一台のサーバ上に環境を作ることも多いと思います。

しかし、本番環境になるべく近い構成にするためにMIM Service/PortalのベースとしてStandard/Enterprise EditionのSharePointをインストールすると、同梱されているUser Profile Service(実体はFIM Synchronization Service)がインストールされてしまいます。

このことにより、MIM Synchronization Serviceの構成が壊れてしまうので、検証環境等でMIM Synchronization ServiceとMIM Service/Portal(およびベースとなるSharePoint)を同一のサーバにインストールする場合は注意が必要です。
(SharePoint FoundationにはUser Profile Serviceが入っていないので問題は起きません)


Microsoft Identity Manager 2016 のポータル


早速見ていきましょう。

◆発生条件
・MIM Synchronization ServiceとMIM Service/Portalを一台のサーバに同居する
・Standard/EnterpriseエディションのSharePointを利用する

◆発生する不具合
・MIM Synchronization Serviceをインストールした後でSharePointをインストールするとSynchronization Service Managerが起動しなくなる。
 ・サービス実行ファイルのパスがSharePoint側のFIM Synchronization Serviceになってしまう


 ・サービス実行アカウントが「\」となってしまう


 ・サービス起動設定が無効化となってしまう
 ・アカウントをSynchronization Service用に設定しなおしてもAccess Deniedエラーが出てサービスが起動しない


◆対策
結局のところ、サービスの設定のパス関係がすべて置き換わってしまっているので修正をする必要があります。
レジストリをガンガン触りますので、基本自己責任です。

①レジストリのサービス関連ファイルのパス修正

対象キー①
HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationServive\ImagePath

修正前)
"C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\Bin\miiserver.exe"
修正後)
"C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe"



対象キー②
HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationServive\Parameters\Path

修正前)
C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\
修正後)
C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\

※その他、Management Agent関連のパスも修正が必要になる場合もあります。


②サービス実行ユーザの修正
「\」となっているのでSynchronization Service実行ユーザに変更する



③パーミッションの変更
上記①、②でサービス自体の修正は終わりなのですが、どうやらPeopleILMなどSharePoint側の設定で消えないものがあるらしく、Synchronization Service起動ユーザにSharePoint側のSynchronization Serviceのパスへの読み取り・実行権限を与える必要があります。

C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\



一応ここまでで使えるようになります。


◆他の解決方法
インストールする順番をSharePoint⇒MIM Synchronization Serviceの順にすることでSharePoint側の設定を逆にMIMが上書きするのでレジストリの修正は不要になります。
が、やはりPeopleILM関係の問題は出るので、上記③の権限付与は必要です。


◆根本的な解決方法
「SharePoint Foundationを使う」。これに限ります。
基本は同居構成の場合はSharePoint Foundationを使いましょう。

[MIM]同期方法(ポリシーベース、Scope Filterベース)を比較する

こんにちは、富士榮です。

Microsoft Identity Manager 2016(MIM)を使って外部システムへIDをプロビジョニングするためには2つの方法があります。(コードベースを合わせると正確には3つですが、ここでは開発を伴う方法は除外して考えます)


◆2つの同期方式
①ポリシーベースのプロビジョニング
一つ目は、Forefront Identity Manager 2010から実装された管理ポリシールール(Management Policy Rule / MPR)、セット(SET)、アクションワークフロー(Action Workflow / WF)、送信同期規則(Outbound Synchronization Rule / OSR)を組み合わせて行う方法です。

ざっくり説明すると、
・一定の条件に当てはまるリソース(ユーザなど)を
・同期規則に割り当てる
ことによって外部システムへプロビジョニングを行います。

この条件をSET、外部システムとの同期するためのルール(属性マッピングなど)をOSR、同期規則へ割り当てるアクションの定義をWF、全体をまとめてMPR、と呼びます。

内部的には、以下の処理が行われます。

  1. 人事などからリソースがFIM(CS)へインポートされる
  2. Metaverseへ同期されるタイミングでISRによりFIM ServiceのCSへ同期される
  3. FIM ServiceへExportされる
  4. リソースがSETの条件に当てはまるかどうか評価される
  5. FIM Service上でリソース毎にExpected Rules Entry(ERE)が生成され、リソースに参照型の属性としてEREが割り当てられる
  6. FIM Service上のリソースとEREがImportされ、Metaverseに同期される
  7. EREによりMetaverse上のリソースとOSRが紐づけられて外部システム用のConnector Spaceへ同期される
  8. 外部システム用のMAでExportを行うことで外部システム上にプロビジョニングされる




キモはリソースがMetaverseに同期されたタイミングでリソースのERE属性が参照しているEREを見て適用するOSRを設定する、という部分です。(処理7の部分)


②Scope Filterベース
こちらはForefront Identity Manager 2010 R2から実装された少しシンプルな同期方法です。

OSRを適用するための条件(Scope Filter)を定義しておくことにより、Metaverseにリソースが同期された段階で条件にマッチすると即OSRが適用され、対象の外部システム向けのCSへリソースが同期されます。
ポリシーベースの同期ではEREオブジェクトがリソースとOSRの間を取り持っていたのに対して、とりあえずMetaverse上のすべてのリソースに対してScope Filterへの適合を確認する、という点で非常にシンプルです。





◆同期方式の機能面での比較
最大の違いは、デプロビジョニング(外部システムからリソースを削除する)ができるか、できないか、です。
ポリシーベースではSET条件に当てはまらなくなった場合に何を行うか?についても定義ができるので、デプロビジョニングするためのWFを作成し、MPRを定義しておけば外部システムからリソースを削除する、などの細かい制御を行うことが可能です。

ざっくりまとめると以下のような比較になります。

比較項目ポリシーベースScope Filterベース
プロビジョニング条件判断MPR、SET、WFの組み合わせにより適用するOSRを決定するOSR自体に設定された条件(Scope Filter)に合致するすべてのMetaverse上のリソースにOSRを適用する
複雑な条件の設定可能
(SETの条件はかなり柔軟、かつ手動でメンバ追加を行うことも可能)
不可能
(基本はリソースの属性の値による判断で、複数の条件を設定する場合はすべてAND条件となる)
FIM Service上へのリソースの同期の要否必要不要
生成されるオブジェクトの数多い(EREオブジェクトが必要)少ない
デプロビジョニング可能
(デプロビジョニング用のMPRとWFを定義することで外部システムからリソースを削除できる)
不可能
(Scope Filterに合致しなくなったリソースに関しては同期されなくなるだけで外部システムからリソースは消えない)
管理面FIM Portal上のユーザに対して適用する予定のルール(ERE)と実際に適用されたルール(DRE)が割り当てられるので、トラブルシュートが楽FIM Portal上で対象ユーザにどの同期規則が適用されているのかの判断がしづらい(FIM Serviceへユーザを同期しないことも可能になってしまうため。FIM Serviceへ同期されたユーザについてはDREを設定することで状態確認は可能)



◆同期方式を性能面で比較
これは圧倒的に差があります。
ポリシーベースだと一旦FIM Serviceにリソースが入ってからでないとリソース割り当ての判断ができないため、処理的にはかなりのオーバーヘッドとなります。また、リソースとは別にERE自体がオブジェクトとして生成され、Metaverse上へ同期されるため、オブジェクト数が外部システムの数分増えていくため、データベースの性能を圧迫します。

一方でScope FilterベースだとリソースがMetaverse上に同期された段階でScope Filterが評価され、適用されるOSRの判断が行われるので無駄がありません。

実際の性能測定をすると以下のような結果となります。
ADにユーザがプロビジョニングされて使えるようになるまで、という条件ですが10,000ユーザで1時間以上の差がついています。


属性条件
・Macbook Air上のVMware Workstationで計測
・ホストスペック
 OS : Windows 10 Pro x64
 CPU : Core i7-4650U 2.3GHz
 メモリ : 8GB
 ディスク : SSD
 VM : VMware Workstation 10
・ゲストスペック
 OS : Windows Server 2012 R2
 CPU : 1vCPU(2core)
 メモリ : 4GB
・ミドルウェア(すべて1台に同居)
 SQL Server 2014 Standard SP1
 SharePoint Foundation 2013 SP1
 Active Directory Domain Service
 Microsoft Identity Manager 2016
 - Synchronization Service
 - MIM Service
 - MIM Portal
・同期条件
 入力(HR相当):CSVファイル
 出力:ADDS
 ユーザ件数:10,000
 同期属性:
 - Account Name
 - Display Name
 - First Name
 - Last Name
 - Department
 同期条件:Department属性値がEIDENTITYとなっていること


◆どちらの方式を使うべきなのか
ケースバイケースなので、なんとも言えませんが例えばActive Directoryなど、ほぼ全員がプロビジョニングされてデプロビジョニングすることがない(無効化はするが実削除はしない)ようなケースであればScope Filterベースがあっていると思います。
今回のテスト環境は非常にプアな環境だったこともあり、データベースでロックが発生してしまい10,000ユーザをポリシーベースで同期しようとしただけでエラーが発生してしまったりしていることもあり、まずはScope Filterベースで設計できないかどうかを検討した上で、どうしても問題がある場合に限ってポリシーベースを使うというのが良いのかもしれません。

[AzureAD]Azure AD Domain Servicesを使って既存サービスをクラウド上へ移行する際の注意事項

こんにちは、富士榮です。

先日パブリック・プレビューが公開されたAzure Active Directory Domain Services(Azure AD DS/AADDS)を使うことでオンプレミスのActive Directoryが提供してきたドメイン・サービス(ドメイン参加やグループポリシーなど)を、同一Azure VNET上のマシンに対して提供することが可能になりました。

公式blogでのアナウンス
 Azure AD Domain Services is now in Public Preview ? Use Azure AD as a cloud domain controller!
 http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx

尚、基本的なセットアップ方法や簡単な注意点についてはMicrosoft Regional Directorの亀渕さんが紹介しているので、そちらを参考にしてください。

ブチザッキ
 Azure Active Directory Domain Services (Public Preview)
 https://buchizo.wordpress.com/2015/10/15/azure-active-directory-domain-services-public-preview/



公式ドキュメントや亀渕さんのblogにも書かれているとおり、AADDSで提供されているドメインサービスには一部制限があります。
・サイトの構成やマルチフォレスト・マルチドメインなどのドメイン構成自体のカスタマイズはできない
・グループポリシーはビルトインのもののみで、カスタマイズができない
・直接ユーザやグループをMMCで管理できない
・管理者(ドメイン参加権限くらいしかない)はAAD DS Administratorsグループに入る
などなどです。


オンプレミスの既存サービスをクラウドへ持って行こうとすると、これらの制限によって少々困ることが出てくるので移行計画を立てる際は注意が必要です。

私が試していて特に困った点は「Domain Admins」権限をユーザに付与できない、という点です。
既存アプリケーションの中にはActive Directory上のオブジェクトを参照・更新するものもあり、それらのアプリケーションは多くの場合Domain Admins権限を要求します。
(アプリケーションの作りの問題ではありますが・・・)

ちなみにAzure AD DSのDomain Adminsにはdcaasadminというユーザが固定でメンバ登録されていますが、このユーザのパスワードがわからないので、なんともなりません。
もちろんこのユーザのパスワードを更新することはできないようになっていますし、Azure AD側への同期もされていません。



以下、Domain Admins権限を求める例です。

1.メンバサーバへのリモート・デスクトップ・ログイン
 これは回避策がありますが、サーバをAzure仮想マシンで構築し、Azure AD DSへ参加させた後、サーバへリモート・デスクトップでAzure AD DS上のユーザでログインしようとしても拒否されてしまいます。


 これはメンバサーバへのリモート・デスクトップ接続が初期状態でビルトインのAdministratorsのみに許可されているためです。Domain Adminsはドメインに参加した時点でビルトインAdministratorsグループに登録されるため、オンプレミス環境ではDomain Adminsのメンバでサーバを管理すれば特に困ることはありませんでした。

 ところが、Azure AD DSでは先述の通り、Domain Adminsは使えないので、まずはローカル・アカウントでログインし、コンピュータの管理からローカルのAdministratorsにリモート・デスクトップ接続したいユーザもしくはグループを追加する必要があります。



2.Domain Admins権限を要求するアプリケーションを導入する
 これは現状どうしようもありません。アプリケーションが固定でDomain Admins権限を要求してくるので、なんともなりません。

 例えば、Active Directory Federation Services(AD FS)などマイクロソフトのサービスはこの時点でほぼ全滅です。(この辺りはAzure ADを使えってことなんでしょうけど)




今後正式版がリリースされるまでにうまく回避策が出てくるといいですねぇ。。

[告知]Azure AD Join / Microsoft Passportの中身を知りたい人は11/10 OpenID Summitへ

こんにちは、富士榮です。

4年ぶりの開催となる、OpenID Summitが来月開催されます。

海外勢は米国OpenID FoundationやPing Identity、Microsoftから大御所が、もちろん日本国内からも総務省、経済産業省といったGovernment系をはじめ、アイデンティティ関係やPKI関係の各種重鎮が終結する超豪華イベントです。


公式サイト:参加登録はこちらから。
 https://openid.or.jp/summit/2015/index.html


私も末席ながらエンタープライズ領域でのフェデレーション活用やIDaaSの可能性についてAzure Active Directory(Azure AD)を例にお話しさせていただきますが、個人的に注目しているセッションは、Microsoft CorporationのAnthony NadalinによるFIDO 2.0のセッションです。

FIDO 2.0といえばWindows 10のAzure AD Joinで使われているMicrosoft Passportの核となるテクノロジです。

私も過去に何度かこのブログでポストしたり、idconなどでお話しさせていただいたことがあるテーマですが、実際にMicrosoftで技術の標準化を進めているAnthony NadalinからFIDO 2.0の話が聞けるのは非常に貴重な機会になると思います。

参考)
 [FIDO/Windows10]idcon vol.20(別名fidcon)が開催されました
 http://idmlab.eidentity.jp/2015/05/fidowindows10idcon-vol20fidcon.html

 [Windows10]デバイス&サービス間のシングルサインオンの仕組み
 http://idmlab.eidentity.jp/2015/05/windows10.html

 [Windows10/AAD]クラウド・ドメイン参加を試す
 http://idmlab.eidentity.jp/2015/02/windows10aad.html


参加費用も無料ですし、ぜひご参加ください。


[Windows10]Surface Pro4でWindows Hello

※修正:11/08)Type Cover with Fingerprintが使えるのはSurface 3ではなく、「Surface Pro 3」でしたので修正しました。
こんにちは、富士榮です。

ついに日本でも来週(11/12)Surface Pro 4が発売されますが、先だって米国マイクロソフト本社のお膝元、ベルビューのマイクロソフト・ストアで購入してきましたので、Windows 10の新機能であるWindows Hello関係をレビューしたいと思います。


大きくポイントは2点です。
1.本体が顔認証に対応した
2.Type Cover with Fingerprint Readerをつけると指紋認証に対応する

特に2の指紋リーダー付きのType Coverは日本を含むUS以外の国では現状発売されないということなので、USで購入するしかありません。


レビューといっても文章で書くよりも動きを見た方が早いと思うので、Channel 9の別館側に動画をアップロードしましたので、そちらを参照してください。

IdM実験室別館
 Surface Pro 4 で Windows Hello
 https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie/Surface-Pro-4--Windows-Hello


尚、動画の中でも話していますが、本体で顔認証が使える以上、あえて指紋認証をする必要もないと思いますので、指紋リーダー付きのType CoverはSurface Pro 3ユーザ向きといえるかもしれません。(もちろんSurface Pro 3のOSをWindows 10にする必要はありますが)


[Windows 10]TH2新機能 - BYOD(WorkPlace Join)でMicrosoft Passportを使う

こんにちは、富士榮です。

Windows 10初の大型アップデートである「Threshold 2」が公開されましたので、早速新機能を順番に見ていきたいと思います。

なんといってもアイデンティティ屋さんにとっての一番大きなアップデートはBYODシナリオにおけるMicrosoft Passportのサポートです。

これまではAzure AD JoinのシナリオでしかMicrosoft Passportが使えず、職場のアカウントを追加(WorkPlace Join)してもOffice 365などへのシングルサインオンはできませんでしたが、今回のビルドからはMicrosoft Passportが使えるようになったので、BYODシナリオでもしっかりシングルサインオンしてくれます。

では、早速設定してみます。

今回は、ローカルアカウントを使ってPCにログインしていますが、その状態でアカウントの設定を開き、職場のアクセスメニューを開くと、これまでのビルドとは大きく異なるメニュー構成となっていますので、Azure ADにサインインをしてみます。

すると、なぜかメールとアカウントの画面に飛ばされるので、「他のアプリで使われるアカウント」から「職場または学校アカウントを追加」をクリックします。

お決まりのAzure ADへのログイン画面が出てくるのでサインインしていきます。

多要素認証が必要なので、通知が飛ばされます。

ポリシーが適用されていきます。
このあたりのポリシーの中身はIntuneなんかで設定します。

作業PINの作成が要求されます。

作業PINなのか職場用PINなのかいまいちわかりませんが、気にせずPINを登録します。

作成が終わると準備完了!と言われます。

アカウントが追加されていることが確認できます。



さて、ここまでで準備は完了ですので、早速ログインしてみます。
そのままブラウザを起動し、アクセスパネルなどAzure ADと連携しているアプリケーションを立ち上げると、Microsoft Passportが有効になり、シングルサインオンされます。



なお、Azure AD上に登録されたデバイスを確認してみると、WorkPlace Join端末であることがわかります。


今後、Windows Server 2016も出てきますので、Microsoft Passportの適用範囲もさらに広がってくると思いますので、非常に楽しみな分野です!





[Azure AD]カスタム・アプリケーション向けプロビジョニングにSCIM2.0のサポート

こんにちは、富士榮です。

IDaaSの主要機能の一つに連携しているアプリケーション向けのプロビジョニング機能がありますが、Azure Active Directory(Azure AD)もGoogle Appsやsalesforce.com、BoxなどメジャーなSaaSアプリケーション向けのプロビジョニングをサポートしてきました。

今回、アプリケーション向けのプロビジョニング機能の強化の一環としてSCIM 2.0(System for Cross-domain Identity Management)のサポートが発表されました。

 Active Directory Teamのblog
  Azure AD Premium now supports SCIM 2.0!
  http://blogs.technet.com/b/ad/archive/2015/11/17/azure-ad-premium-now-supports-scim-2-0.aspx


このニュースを見て、標準ではプロビジョニングできないSaaSアプリケーションでもSCIMをサポートしていればID管理できる!!と思ったのですが、現状はいろいろと制限があります。。。。
(PingOneとかSCIMをサポートしている別のIDaaSへのID同期に使えるかと思ったのですが・・・)

以下が現状の制限事項として大きい点です。
1.SCIMのエンドポイントの保護をAzure ADが行っているサービスのみに対応
  ※Azure ADが発行したOAuth2.0 Bearerトークンを使ってアクセスできるSCIMサーバのみなので、実質自分で開発したアプリケーションしか対象はありません。

2.Azure AD自体がSCIMサーバになった訳ではないので、Azure ADのID管理にSCIMは使えない
  ※これまで通り、Graph APIを使ってID管理をしましょう。

  参考)[Office 365 & WAAD] Graph API を利用したアイデンティティ管理
      http://idmlab.eidentity.jp/2012/12/office-365-waad-graph-api.html


使い方としては、Azure AD Premiumライセンスが割り当たっているユーザでギャラリーからカスタムアプリケーションを追加すると、「アカウント プロビジョニングの構成」メニューが出てくるので、SCIMエンドポイントの設定を行います。


先にも書いたようにSCIMサーバのエンドポイントはAzure ADによって保護されている必要があるため、client idやsecretなどOAuth関連のパラメータを入れる余地はありません。

SCIMサーバの作り方はこのあたりに書いてあります。
 https://azure.microsoft.com/en-us/documentation/articles/active-directory-scim-provisioning/

SCIM用のライブラリも用意されていて、nugetでダウンロードできます。
 https://www.nuget.org/packages/Microsoft.SystemForCrossDomainIdentityManagement/


本当はサードパーティアプリケーションやAzure AD自体へSCIMを使ってプロビジョニングができるようになると良いなぁ、と思いますので今後に期待です。

[Windows 10]Azure ADに参加したPCへリモートデスクトップ接続する

こんにちは、富士榮です。

Windows 10がリリースされてから、Azure ADへの参加やHybrid構成など検証したいことはたくさんあるのですが、いかんせんクライアントOSなので都度手元の端末をセットアップしなおして、、というのが非常に煩雑です。

そんな時のAzure VMなのですが、Windows 10のイメージをVMで作っても接続がリモートデスクトップになるので、Azure ADへの参加するところまでは行けてもAzure AD上のユーザでどうやってログインしたら???という疑問がわいてきます。


単純にAzure AD上のユーザを入力してもログインできません。


と、いうことで、今回はちょっとした工夫をしてみます。
(Morgan Simonsen氏が検証していましたのでその方法の紹介です)

◆接続先コンピュータでの作業
流れとしては、リモート接続設定の構成変更およびAzure ADユーザで接続できるように権限設定を行っておきます。



リモートデスクトップの接続許可の「Allow connections only from computers running Remote Desktop with Network Level Authentication」のチェックを外します。

次に、「Select Users」を開いて「Authenticated Users」を追加します。


これで接続先コンピュータでの作業は終わりです。
(もちろん事前にAzure ADへの参加はしておいてください)

◆接続元コンピュータでの作業(RDPファイルの編集)
今度は接続元での作業です。

Azure VMを作成し接続するとRDPファイルがダウンロードされますので、こちらを直接編集していきます。
具体的にはメモ帳などでRDPファイルを開いて、以下の2行を追記します。
enablecredsspsupport:i:0
authentication level:i:2

編集後、保存します。


これで準備は整いました。

◆接続する
では接続するので、RDPファイルをダブルクリックで開いてみます。
すると、通常はRDPを開いた段階で認証が走るのですが、接続先コンピュータのログイン画面が表示されます。
ここまで行けば、通常のローカルコンピュータと同じでAzure ADのユーザをログインを行います。

尚、ユーザ名には「Azure AD\hogehoge@xxxx.onmicrosoft.com」という形で入力します。
※接続先コンピュータがTH2であれば、UPN(hogehoge@xxxx.onmicrosoft.com)だけでもログインできます。


無事にリモートログインできました。
ブラウザを起動してAzure AD連携しているアプリケーションにアクセスすると無事にMicrosoft Passportも動作しており、シングルサインオンできます。


ネタ元)
http://morgansimonsenblog.azurewebsites.net/2015/11/06/connecting-to-an-azure-ad-joined-machine-with-remote-desktop/

[Windows 10]MobileでもMicrosoft Passport~個人デバイス編(WorkPlace Join)

こんにちは、富士榮です。

そう言えばWindows 10 Mobileにもバージョン1511/ビルド10586が落ちてきていたので、Microsoft Passportが使えるようになっているはず、ということで試してみます。
(久しぶりに通電~充電したLumia 430のめったに無い出番です)

##今回はBYODシナリオです。最初から組織アカウントでデバイスを設定する方法は次回解説します##

とりあえず充電しつつソフトウェア更新をかけて、バージョンが1511になりました。


ということで、Azure AD(Azure Active Directorry)へ参加させてみます。
オペレーションとしてはデスクトップOSと同じく、設定~アカウント~職場のアクセスを開きます。


先日紹介したBYOD端末でのAzure AD参加と同じようなオペレーションですね。
参考)[Windows 10]TH2新機能 - BYOD(WorkPlace Join)でMicrosoft Passportを使う
  http://idmlab.eidentity.jp/2015/11/windows-10th2-byodworkplace.html


この画面で「職場用または学校用のアカウントの追加と削除」をタップするとアカウント設定の画面へ遷移するため、アカウントを追加していきます。

「職場または学校アカウントを追加」をタップすると、Azure ADのログイン画面へ遷移するのでAzure ADのアカウントでログインします。


通常のログインと同様にサインインを行います。今回は多要素認証が有効なアカウントだったので、モバイルへの通知がされました。


これで設定は完了です。


早速、Edgeを立ち上げてアクセスパネル(https://myapps.microsoft.com)へアクセスしてみます。
すると、ログイン画面が一瞬みえますが、そのままアクセスパネルが表示されます。


もちろんアプリケーションへのログオンもそのままシングルサインオンされます。



うまくMicrosoft Passportが動いてくれています。
もちろんAzure ADの管理画面を見るとデバイスが登録されていることがわかります。

このようにWindows 10においてはデスクトップ用OSでもモバイル用OSでもアカウント管理の面においてはほぼ共通の実装になっていることがよくわかります。

Lumia 950も米国ではリリースされたようですし、あとはモバイルデバイスでWindows Helloを早く試してみたいところです。

[Windows 10]MobileでもMicrosoft Passport~企業デバイス編(Azure AD参加)

こんにちは、富士榮です。

前回は個人所有のWindows 10 Mobileの端末に対して職場または学校のアカウント(Azure ADアカウント)を追加してMicrosoft Passportが動作するイメージを紹介しました。

今回はそもそも企業が用意したデバイスをAzure ADに直接参加させて利用・管理するシナリオです。デスクトップOSでいうところのAzure ADへの参加するシナリオに当たります。

まず、デバイスを初期化するところから始めますので、試す方はそれなりの準備をしてから試してください。

初期化をして最初のセットアップ時のアカウント設定を行います。
ここで職場のアカウントでサインインを選択します。

いろいろ説明が出てきますが、次へ進みます。


サインイン画面が出てくるので、Azure ADアカウントでログインします。

何やら設定をしているようです。

ここでPINの設定を求められます。

なぜかこのタイミングで多要素認証が求められました。

多要素認証が完了するとPINの登録です。

一応これでアカウント設定は完了です。
引き続きアプリケーションの設定が行われます。

完了をしばし待ちます。

終わった、と思ったらもう少しありました。

ようやく終わりみたいです。

ええ、Lumiaを選びましたとも、、、安かったので。
ようやくデスクトップ画面にたどり着きます。

綺麗ですね。
とりあえずEdgeを起動してアクセス・パネル(https://myapps.microsoft.com)を起動します。

当然ですが、シングルサインオンされます。


Azure ADの管理画面で見ると「AAD参加済み」デバイスとして認識されています。


もちろんIntuneでもデバイスは見えます。
種別は「企業」になっていますね。ビルドは10.0.13058なんですね。


前回も書きましたが、Windows 10ではデスクトップでもモバイルでもかなりシームレスに管理ができる様になってきています。デバイスさえそろって来れば、企業で使うには一番管理しやすいデバイスになってくるかもしれませんね。


[Windows 10]Intuneを使ったMobileデバイスの消去

こんにちは、富士榮です。

前回、前々回とWindows 10 MobileデバイスをAzure Active Directory(Azure AD)へ参加させる方法について解説をしてきました。
この際、Azure ADとMicrosoft Intuneを連携させておくと、Azure ADに登録されたデバイス情報が自動的にIntuneに同期され、ポリシーの適用やリモート・ロック、ワイプなどの管理を行うことができるようになります。

しかし実際にワイプされるところを見ることも少ないだろうなぁ、ということでChannel 9に動画をアップしておきました。
実際は結構時間がかかるんですが、勝手にデバイスがシャットダウンされ、初期化されていく姿をご覧いただけると思いますので、ぜひご覧ください。

Azure ADへのWindows 10 Mobile参加とIntuneによるリモートワイプ
https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie/Azure-ADWindows-10-MobileIntune



[AD FS]Windows Server 2016 Technical Preview 4/TokenエンドポイントのBASIC認証

こんにちは、富士榮です。

先日Windows Server 2016のTechnical Preview 4が出たので、AD FSがどうなったのかを見ていきたいと思います。

まずOpenID ConnectのRP(Relying Party)を作る上で個人的に一番気になっていたTokenエンドポイントのクライアント認証を見てみました。

一般的なRPの開発ドキュメントを見ているとOAuth2.0のCode Flowを使う際、code取得後にTokenエンドポイントへのPOST時のクライアント認証はBASIC認証で実装されていることが多いですし、RFCのサンプルもそうなっているのですが、Azure Active DirectoryやAD FSのTokenエンドポイントはBASIC認証をサポートしていませんでした。

Windows Server 2016ではこのあたりが改修されることになっており、前回のTechnical Preview 3の.well-known/openid-configurationを見ると以下のようにclient_secret_basicもサポートされていることがわかります。

"token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic","private_key_jwt","windows_client_authentication"],

しかし、Technical Preview 3で実際にTokenエンドポイントでBASIC認証を使おうとすると、invalid_clientと言われてHTTP 400が返ってきてしまいました。



ということで、今回出たTechnical Preview 4ではどこまで治ったのかを見てみます。
codeを取得した後、TokenエンドポイントへのPOST時のAuthorizationヘッダにclient_idとclient_secretを":"で接続してbase64エンコードした文字列をBasicに続けて設定します。

結果、いけました!



これでこれまで他のOpenID Provider向けに作ったクライアントをAD FS用に変更する必要がなくなりましたね。
ただ、現状までAzure ADはまだclient_secret_postとprivate_key_jwtしかサポートしていないみたいです。今後に期待ですね。。





[Azure AD]PowerShellを使ってユーザの多要素認証設定を変更する

こんにちは、富士榮です。

Azure ADで多要素認証を使う場合、ユーザ毎に有効/無効/強制の設定を行う必要があるため非常に面倒です。(CSVで一括設定することも可能ですが、リストファイルを作成して管理コンソールからアップロードする必要があるので、ユーザが増えてくると結果確認などを考えると結構面倒です)

そういう場合のPowerShellです。

早速方法を紹介します。

手順は割愛しますが、まずはConnect-MSolServiceで全体管理者の権限を持つユーザでAzureへ接続します。
※Azure PIM(特権ID管理)をうまく使ってヘルプデスクユーザへ一時的に権限を与えてスクリプトを実行させるとセキュアで便利です。この辺りはそのうち細かく紹介したいと思います。

うまく接続できたら、早速設定をしてみます。

◆有効
以下を実行します。
PS C:\> $auth = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
PS C:\> $auth.RelyingParty = "*"
PS C:\> Set-MsolUser -UserPrincipalName mfa@xxxx.onmicrosoft.com -StrongAuthenticationRequirements @($auth)


Image may be NSFW.
Clik here to view.


管理コンソールで確認すると有効化されていることがわかります。
Image may be NSFW.
Clik here to view.



◆無効
同様に無効化です。
PS C:\> Set-MsolUser -UserPrincipalName mfa@xxxx.onmicrosoft.com -StrongAuthenticationRequirements @()


Image may be NSFW.
Clik here to view.


@()で空の配列をStrongAuthenticationRequirementsに渡してあげます。
管理コンソールを見ると無効化されていることがわかります。
Image may be NSFW.
Clik here to view.



◆強制
最後に強制です。
PS C:\> $auth = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
PS C:\> $auth.RelyingParty = "*"
PS C:\> $auth.State = "Enforced"
PS C:\> Set-MsolUser -UserPrincipalName mfa@xxxx.onmicrosoft.com -StrongAuthenticationRequirements @($auth)


Image may be NSFW.
Clik here to view.


少しトリッキーです。$auth.StateにEnforcedをセットします。

管理コンソールで確認します。
Image may be NSFW.
Clik here to view.




尚、設定結果の取得ですが、上記では管理コンソールでの目視をしましたが、もちろん以下のようにGet-MsolUserを使って確認することも可能です。
PS C:\> $user = Get-MsolUser -UserPrincipalName mfa@xxxx.onmicrosoft.com
PS C:\> $auth = $user.StrongAuthenticationRequirements
PS C:\> $auth | fl


Image may be NSFW.
Clik here to view.



この辺りをうまく使ってAzure ADの管理体制を上手に運用していけるといいですね。
※本当は全体管理者権限ではなく、もう少し細かい権限がほしいところです・・・



[Azure AD/IDaaS]Web記事連載が一息つきました

こんにちは、富士榮です。

夏から続けていた@ITへのIDaaS(Identity as a Service)関連の連載が先日終了したので、ラップアップをしてみます。



連載は以下でご覧いただけます。



全体をとおしてのテーマは「IDaaS」です。最近Azure ADはもちろん、OneLoginやPingOneなど各社のIDaaSが国内でも採用されてきているので、何故ここにきて「IDaaS」が注目されているのか?を「クラウド」、「モバイル」、「グループ&グローバル」の3つのキーワードで解説をしています。

また、第2回~第3回ではIDaaSの実装例としてAzure ADを例に何ができるのか?を「認証」、「ID管理」、「監査」の3つの側面から紹介しています。この中でAzure ADのアプリケーション連携のSSOやプロビジョニング機能、レポート機能の概要を解説しています。

最後は少し毛色を変えてWindows 10とAzure ADを組み合わせた場合を例に、IDaaSの別の一面であるデバイス管理について紹介しています。この中で、Microsoft Passportの仕組みをオンプレミスADでの統合Windows認証と対比しながら解説しています。



全体を通して、なるべく入門レベルを目指して書いているので、まず全体像を把握するための活用して頂けると幸いです。

尚、別の媒体(紙)でもAzure ADについて解説記事が近々公開される予定なので、また紹介したいと思います。


[告知]1月は「企業及びクラウドにおけるアイデンティティ管理セミナー」

こんにちは、富士榮です。

最近なんだかんだで毎月イベントに呼んで頂いていますね。
(カレンダーを見たら9月から毎月登壇してました・・・)

1月は以前からお世話になっている日本ネットワークセキュリティ協会(JNSA)のID管理ワーキンググループの創立10周年記念イベント「企業及びクラウドにおけるアイデンティティ管理セミナー」が開催されます。
(今週頭の段階ですでに定員の半分以上の申込があるので、興味のある方はお早めに!!)

申込サイト
 http://www.jnsa.org/seminar/2016/0121/



以前も紹介しましたが、本ワーキンググループは2005年から活動をしており、主要な成果物として「クラウド環境におけるアイデンティティ管理ガイドライン」や「ロール管理ガイドライン」などを出版しています。

今回のセミナーでは10年の歩みを振り返りつつ、これまで作成してきた各種成果物の概要を解説しますので、かなり凝縮された濃い内容になると思います。

ちなみに私は上記アイデンティティ管理ガイドラインの中で紹介している「ID管理プロジェクトの進め方」について解説するセッションを担当しますが、他にも特権ID管理やロール管理に関するセッション、クラウドやID管理に取り組む上で避けて通れないEUデータ保護指令とどのように付き合うべきか、改正個人情報保護法とID管理に関連したセッション、本ワーキンググループが様々なベンダやコンサル、SIから構成されている特色が良く出るであろうパネルディスカッションも予定されています。

また、セミナー自体は2016年に食い込んでしまっていますが、今年2015年はActive Directoryの15周年にあたる年でもありますので、日本マイクロソフトの安納さんによるActive Directoryを振り返るセッションも予定されています。


いずれもかなり濃い内容になると思いますので、早めにお申し込みください!
Viewing all 771 articles
Browse latest View live