こんにちは、富士榮です。
プロビジョニングの標準仕様策定を目指して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製品やサービスも出てきているので、今後さらに普及していくと思われますので、要チェックですね。
2015年9月26日土曜日
[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を指定します。
結果、Redirect URIに指定したアドレスにクエリパラメータとして認可コードが返ってきます。
このcode=xxxの部分が認可コードです。
次に取得した認可コードをトークンエンドポイントにPOSTしてアクセストークンを取得します。
すると、アクセストークン、リフレッシュトークン、IDトークンが返ってきます。
ん？なぜかscopeがopenidのみになってしまっていますね。。。
いやな予感しかしません。
◆UserInfoエンドポイントへアクセスする
取得したアクセストークンをAuthorizationヘッダに入れてGETします。
やはりsubしか返ってきません。profileとかemailがscopeから消えてしまっているからですかね。。
AD FSの管理コンソールから定義されているscope一覧を見るとちゃんとprofileやemailもあるんですけどね。
まだTechnical Preview版なので、こんなものなのかも知れません。今後の進化に期待ですね。
先月のポストでは、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版なので、こんなものなのかも知れません。今後の進化に期待ですね。
2015年9月3日木曜日
[告知]ID連携入門セミナーが大阪で開催されます
こんにちは、富士榮です。
今年はID&IT Managementカンファレンスも東京だけ、となかなかホットにならない大阪のID市場ですが、何とか活気が出てくるとうれしいなぁ、と思う今日この頃です。
（実際、大阪でID専任で仕事をしてる身としてはそれなりに忙しいんですけど・・・）
そんな中、2270万人の近畿地方のID愛好家のみなさんに朗報です。
「ID連携入門セミナ in 大阪」の開催が決定しました。
内容的には8月末に東京で開催された「OpenID Technight vol.13」＋少しエンタープライズ要素を強めという感じです。
思い起こせば前回の大阪でのOpenID Technightから早4年。当時はフェデレーションって話をしても全然響かなかったのに、最近では普通に「フェデレーションを検討してます（ｷﾘｯ」という話も増えてきて、ようやく大阪でもブームが来たか、と感無量だったりします。
というわけで、概要です。
開催日：2015年10月9日（金）
受付開始：15:00
講演開始：15:30（18:00終了予定）
場所：伊藤忠テクノソリューションズ株式会社 大阪支店
申し込みURL：
http://www.openid.or.jp/news/2015/09/id109.html
今回、私は会社としての取り組みの話をする予定ですが、OpenID Foundation Japanのエバンジェリスト達やEnterprise Identity Working Groupの江川さんや八幡さんがID連携の基礎的な話やエンタープライズでの活用について話をしてくれますので、この機会に基本から勉強したい、という方はぜひご参加ください。
今年はID&IT Managementカンファレンスも東京だけ、となかなかホットにならない大阪のID市場ですが、何とか活気が出てくるとうれしいなぁ、と思う今日この頃です。
（実際、大阪でID専任で仕事をしてる身としてはそれなりに忙しいんですけど・・・）
そんな中、2270万人の近畿地方のID愛好家のみなさんに朗報です。
「ID連携入門セミナ in 大阪」の開催が決定しました。
内容的には8月末に東京で開催された「OpenID Technight vol.13」＋少しエンタープライズ要素を強めという感じです。
思い起こせば前回の大阪でのOpenID Technightから早4年。当時はフェデレーションって話をしても全然響かなかったのに、最近では普通に「フェデレーションを検討してます（ｷﾘｯ」という話も増えてきて、ようやく大阪でもブームが来たか、と感無量だったりします。
というわけで、概要です。
開催日：2015年10月9日（金）
受付開始：15:00
講演開始：15:30（18:00終了予定）
場所：伊藤忠テクノソリューションズ株式会社 大阪支店
申し込みURL：
http://www.openid.or.jp/news/2015/09/id109.html
今回、私は会社としての取り組みの話をする予定ですが、OpenID Foundation Japanのエバンジェリスト達やEnterprise Identity Working Groupの江川さんや八幡さんがID連携の基礎的な話やエンタープライズでの活用について話をしてくれますので、この機会に基本から勉強したい、という方はぜひご参加ください。
2015年8月31日月曜日
[顔認証]ChromebookでWindows Helloっぽくログインする
こんにちは、富士榮です。
Windows 10の新機能であるWindows Helloでは顔や指紋などの生体情報を使ってOSへログインすることが出来ます。
関連ポスト）
[Windows10]ついにWindows Helloで顔認証！
http://idmlab.eidentity.jp/2015/07/windows10windowshello.html
一方で他のOS/デバイスではどうなのかと言いますと、iOSにおけるTouchIDのあるAppleや、SAMSUNGやdocomoがFIDO Allianceに参加しているAndroidなどもメーカ実装として生体認証に対応してきています。
こうなってくると気になるのがGoolgeの出しているChromebookです。
（気になるのはごく一部の人だとは思いますが）
と、いうことで確認してみます。
◆準備
今回は以下の2つの機能を使ってChromebookへのログイン/ロック解除時の顔認証を目指します。
１．Smart Lock for Chromebook
２．Smart Lock for Androidの顔認識機能
１．Smart Lock for Chromebook
まずはChromebook側のSmart Lockです。
ChromebookにはSmart Lock for ChromebookというAndroidを使ったログイン/ロック解除機能が存在します。
Android スマートフォンで Chromebook のロックを解除する
https://support.google.com/chromebook/answer/6070209?hl=ja
簡単に言うとあらかじめBluetoothでペアリングされた、Smart Lockに対応した端末（Android 5.0以降）がChromebookの近く（Bluetoothの有効範囲）にあるとパスワード入力をスキップして端末へのログインやロック解除を行うことが出来る、という機能です。
この機能を使うには、BluetoothをONにした状態で、Chromebookの設定からSmart Lockの設定を行います。
設定時、同じくBluetoothをONにしたSmart Lock対応のAndroid端末が近くにあると、自動的にデバイスを検出します。
２．Smart Lock for Androidの顔認識機能
次にAndroid端末側です。
こちらも端末の設定のセキュリティ項目からSmart Lockの設定を行います。
今回は顔認証を行うので、「認識済みの顔」を選択し顔を登録します。
◆テストする
ここまでで、Chromebook⇒Android端末⇒顔という信頼関係が構築されました。
早速Chromebookを起動、もしくはロックします。
Android端末側のロックを解除していない状態だと、以下のようなメッセージが表示され、ロック解除を促されます。
Android端末側を起動すると、ロック画面の一番下に顔マークが表示され、信頼済みの顔を探します。
正常に顔を認識すると顔マークがロック解除マークに代わり、画面をスワイプするとパスワードを入れなくても端末ロックを解除できます。
Android端末のロックを解除すると連動してChromebookのロックも解除され、Chromebookのロック画面がロック解除状態になり、写真をクリックすれば同じくパスワードを入れなくても端末ロックを解除できます。
Windows 10のWindows Helloと異なり、PC（＋カメラ）単体での顔認証とは行きませんが、Android端末側のロック解除方法によって認証のバリエーションが変えられるので、利用者の状況に合わせた柔軟かつ安全な運用を行うことができると思います。
※そのような意味で、生体認証付きの多要素認証ログインという方が的確なのかもしれません。
Windows 10の新機能であるWindows Helloでは顔や指紋などの生体情報を使ってOSへログインすることが出来ます。
関連ポスト）
[Windows10]ついにWindows Helloで顔認証！
http://idmlab.eidentity.jp/2015/07/windows10windowshello.html
一方で他のOS/デバイスではどうなのかと言いますと、iOSにおけるTouchIDのあるAppleや、SAMSUNGやdocomoがFIDO Allianceに参加しているAndroidなどもメーカ実装として生体認証に対応してきています。
こうなってくると気になるのがGoolgeの出しているChromebookです。
（気になるのはごく一部の人だとは思いますが）
と、いうことで確認してみます。
◆準備
今回は以下の2つの機能を使ってChromebookへのログイン/ロック解除時の顔認証を目指します。
１．Smart Lock for Chromebook
２．Smart Lock for Androidの顔認識機能
１．Smart Lock for Chromebook
まずはChromebook側のSmart Lockです。
ChromebookにはSmart Lock for ChromebookというAndroidを使ったログイン/ロック解除機能が存在します。
Android スマートフォンで Chromebook のロックを解除する
https://support.google.com/chromebook/answer/6070209?hl=ja
簡単に言うとあらかじめBluetoothでペアリングされた、Smart Lockに対応した端末（Android 5.0以降）がChromebookの近く（Bluetoothの有効範囲）にあるとパスワード入力をスキップして端末へのログインやロック解除を行うことが出来る、という機能です。
この機能を使うには、BluetoothをONにした状態で、Chromebookの設定からSmart Lockの設定を行います。
設定時、同じくBluetoothをONにしたSmart Lock対応のAndroid端末が近くにあると、自動的にデバイスを検出します。
２．Smart Lock for Androidの顔認識機能
次にAndroid端末側です。
こちらも端末の設定のセキュリティ項目からSmart Lockの設定を行います。
今回は顔認証を行うので、「認識済みの顔」を選択し顔を登録します。
◆テストする
ここまでで、Chromebook⇒Android端末⇒顔という信頼関係が構築されました。
早速Chromebookを起動、もしくはロックします。
Android端末側のロックを解除していない状態だと、以下のようなメッセージが表示され、ロック解除を促されます。
Android端末側を起動すると、ロック画面の一番下に顔マークが表示され、信頼済みの顔を探します。
正常に顔を認識すると顔マークがロック解除マークに代わり、画面をスワイプするとパスワードを入れなくても端末ロックを解除できます。
Android端末のロックを解除すると連動してChromebookのロックも解除され、Chromebookのロック画面がロック解除状態になり、写真をクリックすれば同じくパスワードを入れなくても端末ロックを解除できます。
Windows 10のWindows Helloと異なり、PC（＋カメラ）単体での顔認証とは行きませんが、Android端末側のロック解除方法によって認証のバリエーションが変えられるので、利用者の状況に合わせた柔軟かつ安全な運用を行うことができると思います。
※そのような意味で、生体認証付きの多要素認証ログインという方が的確なのかもしれません。
2015年8月24日月曜日
[告知]9月はイベント三昧。ID&IT Management ConferenceとJapan SharePoint Group
こんにちは、富士榮です。
9月にある2つのイベントに登壇することになったので、告知です。
１．ID&IT Management Conference 2015
世界3大アイデンティティ・イベントの一つである「ID&IT Management Conference」が9月18日に開催されます。今年で5回目になるんですね。
私もなんだかんだでほぼ毎年関わらせていただいているんですが、今年もパネル・セッションにパネリストとして参加させていただきます。
私は「エンタープライズIDの正しい捉え方、活用方法」というセッションでNTTデータの山田さん、NIIの中村先生、エクスジェンの江川さんと一緒にパネルディスカッションをする予定です。社内管理部門、学認、パッケージ、SIerという複数の立場からエンタープライズにおけるアイデンティティのあり方みたいな話ができると思います。
以下、セッション概要（イベントページより引用）です。
http://nosurrender.jp/idit2015/index.html
２．Japan SharePoint Group
2つ目はこれまでもたまにお手伝いさせていただいておりますMVP山崎さんが主宰しているJapan SharePoint Groupで9月12日に開催されます。こちらも20回目の開催になるんですね。
同日にSystem Center User Group Japanが品川で開催され、そちらがActive Directory特集ということなので、スピーカー不足ということで招集がかかりましたｗ
SharePointグループということでどちらかというと情報系アプリケーションの開発者の方や社内管理者の方が多く参加されると思いますので、テクニカルというよりもハイブリッドな認証/ID管理基盤の基礎的な話、プロジェクトの進め方、Windows 10のAzure AD Joinなんかの話が出来ればいいかな、と考えています。
こちらも以下のURLから申し込みが可能です。
http://jpsps.com/event/20150912/
時間的に国井さんのセッションとダダ被りですね。。。。
9月にある2つのイベントに登壇することになったので、告知です。
１．ID&IT Management Conference 2015
世界3大アイデンティティ・イベントの一つである「ID&IT Management Conference」が9月18日に開催されます。今年で5回目になるんですね。
私もなんだかんだでほぼ毎年関わらせていただいているんですが、今年もパネル・セッションにパネリストとして参加させていただきます。
私は「エンタープライズIDの正しい捉え方、活用方法」というセッションでNTTデータの山田さん、NIIの中村先生、エクスジェンの江川さんと一緒にパネルディスカッションをする予定です。社内管理部門、学認、パッケージ、SIerという複数の立場からエンタープライズにおけるアイデンティティのあり方みたいな話ができると思います。
以下、セッション概要（イベントページより引用）です。
以下のURLから申し込みが可能なので、お早めに！エンタープライズIDの正しい捉え方、活用方法 (パネルセッション)認証基盤システム整備のための予算を確保するのに苦労する組織は、大変多いのではないでしょうか。これは認証基盤整備が、セキュリティ確保や内部統制を主目的とし、また既に稼働中の基盤システムに対する再構築である場合が多く、利益増を主目的とする企業にとっては優先課題にはなりづらいからではないでしょうか。IDを適切に運用、管理することで実現される理想像を描けているにも関わらず、我々には乗り越えないといけない様々な現実的な(技術論ではない）問題が多くあります。大規模認証基盤システム構築事例を元に、パネリストがそれぞれの立場から、様々な壁を乗り越える策を議論します。
http://nosurrender.jp/idit2015/index.html
２．Japan SharePoint Group
2つ目はこれまでもたまにお手伝いさせていただいておりますMVP山崎さんが主宰しているJapan SharePoint Groupで9月12日に開催されます。こちらも20回目の開催になるんですね。
同日にSystem Center User Group Japanが品川で開催され、そちらがActive Directory特集ということなので、スピーカー不足ということで招集がかかりましたｗ
SharePointグループということでどちらかというと情報系アプリケーションの開発者の方や社内管理者の方が多く参加されると思いますので、テクニカルというよりもハイブリッドな認証/ID管理基盤の基礎的な話、プロジェクトの進め方、Windows 10のAzure AD Joinなんかの話が出来ればいいかな、と考えています。
こちらも以下のURLから申し込みが可能です。
http://jpsps.com/event/20150912/
時間的に国井さんのセッションとダダ被りですね。。。。
2015年8月22日土曜日
[AD FS]OpenID Connectに対応した次期AD FSを試す
こんにちは、富士榮です。
先日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
これを見ると、
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としても使えるかも知れませんね。
先日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としても使えるかも知れませんね。
2015年8月15日土曜日
[AADSync/MIM]プロキシサーバ経由でID同期を行う
こんにちは、富士榮です。
企業内からOffice365などのSaaSアプリケーションをAzure Active Active Directory（Azure AD）経由で使う場合、オンプレミスのActive Directory上のアカウントをAzure AD Sync（AADSync）やMicrosoft Identity Manager 2016（MIM）のAzure AD Connectorを使って同期するのが一般的なシナリオです。
しかし、ほとんどの企業のネットワークには厄介なことにプロキシサーバが配置されており、AADSyncなどクラウド上のサービスに直接通信を行うサーバーを導入する際、どこに配置するのか非常に悩んだり、面倒な申請を上げてプロキシのバイパス設定や、場合によってはネットワーク機器のフィルタリングやルーティング設定を変更する必要性が出てきたりします。
本格導入をする場合は、その辺りの環境の洗い出しや構成変更についても覚悟をもって構築作業をするのでしょうが、開発環境やテスト環境として使う場合はそこまで大掛かりな準備をする手間がかけられず、困ることが多いと思います。
そのようなケースにおいてAADSyncやMIMがプロキシサーバを参照して動作するための設定を行う必要があります。
ケースとして以下の3つのパターンに対応することが可能です。
1. 認証なしのプロキシサーバを使っている
2. BASIC認証が必要なプロキシサーバを使っている
3. NTLM認証が必要なプロキシサーバを使っている
それぞれについてどのように対応するか解説していきます。
1. 認証なしのプロキシサーバを使っている
このケースは比較的簡単です。
マイクロソフトのサポートサイトにも情報が記載されており、具体的には「C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config」にプロキシサーバに関するエントリを追加して再起動するだけです。
サポートサイト
https://support.microsoft.com/en-us/kb/3013032
以下のエントリをConfigurationブロックの最後に追記します。
企業内からOffice365などのSaaSアプリケーションをAzure Active Active Directory（Azure AD）経由で使う場合、オンプレミスのActive Directory上のアカウントをAzure AD Sync（AADSync）やMicrosoft Identity Manager 2016（MIM）のAzure AD Connectorを使って同期するのが一般的なシナリオです。
しかし、ほとんどの企業のネットワークには厄介なことにプロキシサーバが配置されており、AADSyncなどクラウド上のサービスに直接通信を行うサーバーを導入する際、どこに配置するのか非常に悩んだり、面倒な申請を上げてプロキシのバイパス設定や、場合によってはネットワーク機器のフィルタリングやルーティング設定を変更する必要性が出てきたりします。
本格導入をする場合は、その辺りの環境の洗い出しや構成変更についても覚悟をもって構築作業をするのでしょうが、開発環境やテスト環境として使う場合はそこまで大掛かりな準備をする手間がかけられず、困ることが多いと思います。
そのようなケースにおいてAADSyncやMIMがプロキシサーバを参照して動作するための設定を行う必要があります。
ケースとして以下の3つのパターンに対応することが可能です。
1. 認証なしのプロキシサーバを使っている
2. BASIC認証が必要なプロキシサーバを使っている
3. NTLM認証が必要なプロキシサーバを使っている
それぞれについてどのように対応するか解説していきます。
1. 認証なしのプロキシサーバを使っている
このケースは比較的簡単です。
マイクロソフトのサポートサイトにも情報が記載されており、具体的には「C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config」にプロキシサーバに関するエントリを追加して再起動するだけです。
サポートサイト
https://support.microsoft.com/en-us/kb/3013032
以下のエントリをConfigurationブロックの最後に追記します。
<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://[Proxyサーバアドレス]:[ポート番号]"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
2. BASIC認証が必要なプロキシサーバを使っている
ここからが少しトリッキーになってきます。
先のmachine.configには認証に使うユーザIDやパスワードを記載することが出来ないので、認証プロキシとAADSync/MIMの中間に認証なしのプロキシサーバを挟み、上位プロキシへフォワードさせる際に中間のプロキシサーバから認証情報をつける、ということを行います。
上位のプロキシサーバがBASIC認証を使う場合は、squidを使うことで対応することが可能です。
※尚、中間プロキシサーバの要件としては①http/httpsを上位プロキシサーバへフォワード出来ること、②フォワード時にBASIC認証に対応できることの2点なので、squid以外でも対応できるものがあるかもしれません。
今回はAADSyncサーバにWindows版のsquidを同居させました。
Windows版squidのダウンロード
C:\squid以下にダウンロードしたモジュールを展開し、etcフォルダ以下のmime.conf.defaultをmime.confへリネームし、以下の内容のsquid.confを新規作成します。
（今回は限定的な用途なので、最低限のエントリだけしか記載していません。ログなど出したければsquid.conf.defaultを参考に追記してください）
acl all src all acl localhost src 127.0.0.1/32 acl SSL_ports port 443 acl Safe_ports port 80 acl Safe_ports port 443 acl CONNECT method CONNECT acl SSL method CONNECT never_direct allow SSL http_access deny !Safe_ports http_access allow localhost http_access deny all http_port 8080 cache_peer [上位プロキシサーバのアドレス] parent [ポート番号] 0 login=[ユーザID]:[パスワード]
これでsquidを起動し、先のmachine.configのプロキシサーバ設定にlocalhostを指定すればAADSync/MIMはsquidを、squidは本来のプロキシを参照する形でインターネットへ接続できるようになります。
3. NTLM認証が必要なプロキシサーバを使っている
最後が、Windows統合認証を使っている認証プロキシです。ISAとかですね。（古）
この場合も考え方は同じですが、squidがWindows統合認証に対応していないので、Cntlmというフリーウェアを使うことで対応している例があるようです。
Cntlmダウンロードページ
細かい方法は今回は省略しますが、Cntlmの設定ファイル（iniファイル）に認証に使うユーザ名、ドメイン名、パスワードを記載してサービスを起動、上位プロキシサーバを参照させる、という方法をとります。
旧Forefront Identity Manager（FIM）、現Directory ServicesのMVPも在籍しているオーストラリアのkloudという会社のblogで紹介されているので、詳しくはそちらを見てください。
kloudのblog
尚、上記で紹介したのはあくまで開発・テスト時の使用にとどめておいた方が良いと思います。障害ポイントを増やすだけですし、思わぬトラブルが発生した時に切り分けが難しくなる場合もあると思われますので。
登録:
投稿 (Atom)
投稿
