Recommended
More Related Content
What's hot
What's hot (20)
Similar to Azure AD B2CにIdPを色々と繋いでみる
Similar to Azure AD B2CにIdPを色々と繋いでみる (20)
More from Naohiro Fujie
More from Naohiro Fujie (19)
Recently uploaded
Recently uploaded (11)
Azure AD B2CにIdPを色々と繋いでみる
- 1. Azure AD B2CにIdPを 色々と繋いでみる Microsoft MVP for Enterprise Mobility 富士榮 尚寛（ふじえ なおひろ） @phr_eidentity 第35回 Tokyo Jazug Night
- 2. 自己紹介 • プロフィール • デジタル・アイデンティティ歴、約18年 • OpenIDファウンデーション・ジャパン/代表理事、KYC WGリーダ • 米国OpenID Foundation/eKYC and Identity Assurance WG共同議長 • 日本ネットワークセキュリティ協会デジタル・アイデンティティWG • Blog : IdM実験室（https://idmlab.eidentity.jp） • MS MVP for Enterprise Mobility, Auth0 Ambassador, LINE API Expert • 最近の興味領域 • 分散型ID（DID）、検証可能なクレデンシャル（VC） • 法人KYCとトラストフレームワーク
- 3. Azure Active Directory B2C • その名の通り、Business to Consumerシナリオで使うAzure Active Directory • TwitterやFacebookなどのSNSのアカウントを使ってECサイトへのID登録やログインを行う • いわば、IDのハブ 出典） https://docs.microsoft.com/ja- jp/azure/active-directory- b2c/overview
- 5. 顧客サイド IDプロバイダー • Amazon（米国） • Apple • Facebook • Github（Preview） • Google • LinkedInローカルアカウント • Microsoft Account • QQ（Preview） • Twitter • WeChat（Preview） • Weibo（Preview） • OpenID Connect
- 6. ロジック ユーザーフロー • サインアップとサインイン • プロファイル編集 • パスワードリセット • サインアップ • サインイン • リソース所有者のパスワード資格 情報（ROPC）を使用してサインイン する
- 7. ビジネスサイド アプリケーション • OAuth • OpenID Connect ここにはないがSAMLとかws-fedも （今日は触れませんが）
- 9. デモ① • とりあえずID登録〜アプリ連携を試す • IDプロバイダ：ローカル • ユーザーフロー：サインアップ＆サインイン • アプリ：https://jwt.ms
- 10. 顧客サイド IDプロバイダー • Amazon（米国） • Apple • Facebook • Github（Preview） • Google • LinkedInローカルアカウント • Microsoft Account • QQ（Preview） • Twitter • WeChat（Preview） • Weibo（Preview） • OpenID Connect
- 11. カスタムIdPの構成 （OpenID Connect） • 名前 • メタデータURL • クライアントID • クライアントシークレット • スコープ • 応答の種類 • 応答モード • ドメインのヒント • IDプロバイダの要求のマッピング • ユーザID • 表示名 • 名 • 姓 • 電子メール
- 12. パラメータ（接続パラメータ） 項目 説明 例（LINEの場合） 名前 IDプロバイダの名称（Azure AD B2Cのログイン画面に表示 されるボタンのラベル） LINE メタデータURL IDプロバイダの構成情報が公開されているURL（OpenID Connect Discoveryのwell-knownエンドポイント） https://access.line.me/.wel l-known/openid- configuration クライアントID IDプロバイダがクライアント（今回のケースではAzure AD B2Cを識別するためのID） xxxxxxxx（LINEのチャネル ID） クライアントシークレット クライアントIDと併せてクライアントを認証するためのシー クレット xxxxxxxx（LINEのチャネル シークレット） スコープ IDプロバイダへの認証要求に使うスコープ openid email profile 応答の種類 IDプロバイダ連携時のフローの種類（response_type） code 応答モード IDプロバイダからの応答方式の種類（response_mode） query ドメインのヒント IDプロバイダの自動選択をする際のヒント（domain_hint） line.me
- 13. パラメータ（IDプロバイダの要求のマッピング） 項目 説明 例（LINEの場合） ユーザーID IDプロバイダ上でユーザを一意に識別するための属性名 sub 表示名 Azure AD B2Cのname属性とマッピングされる属性名 name 名 Azure AD B2Cのgiven_name属性とマッピングされる属性 名 -（該当属性なし） 姓 Azure AD B2Cのfamily_name属性とマッピングされる属性 名 -（該当属性なし） 電子メール Azure AD B2CのotherMails属性とマッピングされる属性名 email ちなみに、外部IDプロバイダ側に登録するAzure AD B2Cのredirect_uriはこんな感じ。 https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/authresp
- 14. 接続パラメータ解説 • メタデータURL • OpenID Connect Discoveryの仕様に則り公開される各種エンドポイント等の情報が記載されたエンドポイント • https://ドメイン名/.well-known/openid-configurationという形式のURL • IDプロバイダによっては公開されていないものもあり • ドメイン名＋パスが含まれるIDプロバイダもあり（本来は違反） • 基本は各IDプロバイダのサイトに記載されていることが多い（こっそり公開されているケースもある） • 基本はここにある情報をもとに設定をしていく
- 15. LINEの場合 https://access.line.me/.well-known/openid-configuration { "issuer": "https://access.line.me", "authorization_endpoint": "https://access.line.me/oauth2/v2.1/authorize", "token_endpoint": "https://api.line.me/oauth2/v2.1/token", "jwks_uri": "https://api.line.me/oauth2/v2.1/certs", "response_types_supported": ["code"], "subject_types_supported": ["pairwise"], "id_token_signing_alg_values_supported": ["ES256"] }
- 16. LINEの場合 https://access.line.me/.well-known/openid-configuration { "issuer": "https://access.line.me", "authorization_endpoint": "https://access.line.me/oauth2/v2.1/authorize", "token_endpoint": "https://api.line.me/oauth2/v2.1/token", "jwks_uri": "https://api.line.me/oauth2/v2.1/certs", "response_types_supported": ["code"], "subject_types_supported": ["pairwise"], "id_token_signing_alg_values_supported": ["ES256"] } IDトークン発行者の識別子 認可エンドポイントのアドレス トークンエンドポイントのアドレス JWKSエンドポイントのアドレス サポートされているresponse_type IDトークンへの署名アルゴリズム サポートされる識別子のタイプ
- 17. クライアントID、クライアントシークレット クライアントID、クライアントシークレット • IDプロバイダにとってのクライアント（今回のケースではAzure AD B2C）を識別・認証するために利用す るIDとシークレット • 不正なクライアントからのリクエストにIDトークン（認証や属性情報の提供に利用）を渡さないことが目 的 スコープ • 認可範囲（トークンの利用範囲）を示す • OpenID: OpenID Connectプロトコルの利用であることを示す＝id_tokenを発行するスコープ • profile、email等（認可サーバ側が指定する）: 認可サーバが提供する属性の範囲を示す
- 18. 応答の種類、応答モード 応答の種類（response_type） • プロトコルフローの指定 • code: 認可コードフロー（認可コードを介してid_tokenを取得する） • Id_token: インプリシットフロー（認可エンドポイントから直接id_tokenを発行する） 応答モード（response_mode） • 認可エンドポイント等からの応答方式の指定（どうやってUAを経由してクライアントへ応答を渡すか？） • form_post: HTMLフォームのhiddenフィールドに設定された値を自動的にPOSTするJavaScriptを含むHTMLを応答する • query: クエリパラメータに値をセットし、HTTP 302によるリダイレクトで値を渡す • fragment: fragment部に値をセットし、HTTP 302によるリダイレクトで値を渡す（ユーザーフローでは未サポート）
- 20. おさらい）処理の流れとパラメータ Azure AD B2C LINE ① client_id, redirect_uri, response_type等の情報をつ けてAuthZ（認可エンドポイント）へアクセス（認可 サーバはあらかじめ発行したclient_idと登録されて いるredirect_uriを確認） ② 認可サーバ側で未認証ならユーザ認証を行う ③ 認可コードを発行しクライアントのredirect_uriへ redirectする • 認可コードの発行を行う：response_type=code • 認可コードをqueryで渡す: reponse_mode=query ④ 認可コードをTokenエンドポイントへPOSTし、IDトーク ンを取得する。その際、client_id, client_secretでクラ イアントを認証する。 ① ② ③ ④ 日本語訳もあるので仕様確認はこちらから https://openid-foundation-japan.github.io/openid- connect-core-1_0.ja.html
- 21. デモ② • LINEをIDプロバイダとして設定する • IDプロバイダ：LINE • ユーザーフロー：サインアップ＆サインイン • アプリ：https://jwt.ms • ちなみにprompt=loginが付いているとLINE Loginがコケることがあるのでテスト時は注意
- 23. デモ③ • Yahoo! JAPANをIDプロバイダとして設定する • IDプロバイダ：Yahoo Japan • ユーザーフロー：サインアップ＆サインイン • アプリ：https://jwt.ms
- 26. エラー箇所を特定する • ツールはなんでもいいが、HTTPのシーケンスを確認できるものが良い • 私はSAMLのトレースをすることが多いので、SAML Tracer（ブラウザプラグイン）を使用 • FiddlerなどでもいいがHTTPS通信をキャプチャするための証明書信頼などが面倒 • SAML Tracer • https://chrome.google.com/webstore/detail/saml-tracer/mpdajninpobndbfcldcmbpnnbhibjmch • https://addons.mozilla.org/ja/firefox/addon/saml-tracer/
- 27. Azure AD B2Cがinvalid_requestをfragmentでjwt.msへ返却 している その直前にAzure AD B2Cへのレスポンスの元となるYahoo へのリクエストパラメータを確認する • 認可エンドポイントへのアクセス • Yahoo!JAPANが期待しているパラメータとの差異がある 可能性あり
- 28. IDプロバイダ側の仕様を確認する • メタデータURLの中身を確認する • https://auth.login.yahoo.co.jp/yconnect/v2/.well-known/openid-configuration • 今回認可（Authorization）エンドポイントへのアクセスなので仕様を確認する • https://developer.yahoo.co.jp/yconnect/v2/authorization_code/authorization.html
- 29. メタデータURL { "issuer": "https://auth.login.yahoo.co.jp/yconnect/v2", "authorization_endpoint": "https://auth.login.yahoo.co.jp/yconnect/v2/authorization", "token_endpoint": "https://auth.login.yahoo.co.jp/yconnect/v2/token", "userinfo_endpoint": "https://userinfo.yahooapis.jp/yconnect/v2/attribute", "jwks_uri": "https://auth.login.yahoo.co.jp/yconnect/v2/jwks", "response_types_supported": [ "code", "token", "id_token", "code token", "code id_token", "token id_token", "code token id_token" ], "subject_types_supported": [ "public", "pairwise" ], "id_token_signing_alg_values_supported": [ "RS256" ], "scopes_supported": [ "openid", "email", "profile", "address" ], "token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ] ・・・ 被疑箇所のresponse_modeに関す る記述なし
- 33. Azure AD B2Cとresponse_mode • Microsoftの仕様は歴史的にIDプロバイダからのリクエストをクライアントへ渡すときはform_postを利 用する（ws-federationやSAML時代のライブラリの実装） • 当時のライブラリの有効活用＋複数プロトコルへ対応させるためにform_postを推し • もちろんレスポンスの中身をProxyサーバなどに横取りされない、などの利点もあり • ということでMSのクライアントライブラリではresponse_mode=form_postがデフォルトで付与されること が多く、Azure AD B2Cでもresponse_modeは外せない
- 34. ではどうするか • 基本的に管理ポータルからの設定ではどうしようもない • カスタムポリシー（Identity Experience Framework）を利用する • しかし、OpenID Connectを使う以上、カスタムポリシーを使ってもresponse_modeは消せない（パラメー タ指定をしなくても自動的にform_postが入る） • 仕方がないのでOAuthを利用 • OpenID Connectの基本的なプロトコルフローはOAuthと同じ • scopeパラメータにopenidを指定するとid_tokenが返ってくる • ただし、nonceなどのトークンリプレイ対策としてOpenID Connectから導入されたパラメータは送出されないの で注意
- 35. カスタムポリシー/Identity Experience Framework • Azure ADの機能を開発するための言語/Framework • XMLベースでルールや定義を記載していく特殊言語とフレームワーク • 色々できる • スキーマ拡張 • クレーム変換ルール（関数的なもの）の定義 • 画面定義 • IDプロバイダの呼び出し • 外部APIの呼び出し • セッション管理 • アプリケーションへのトークン発行 • ユーザージャーニーの定義 • B2CじゃないAzure ADも基本は中身はこれで書かれているはずなので、使いこなすとAzure ADの基本機能の 動きについてなんとなく想像がつくようになる
- 37. Yahoo! JAPANを繋ぐ • B2C_1A_TRUSTFRAMEWORKBASE.xml • ClaimsProviderの基本設定（共通部分） • フローへの組み込み（Yahoo! JAPANを使ったアカウント登録〜サインイン） • B2C_1A_TRUSTFRAMEWORKEXTENSIONS.xml • ClaimsProviderの個別設定（個別設定）
- 38. B2C_1A_TRUSTFRAMEWORKBASE.xml • Facebookのポリシーを参考に構成（Yahoo! JAPANのwell-known/openid-configurationより） • authorization_endpoint : 認可エンドポイント • AccessTokenEndpoint : トークンエンドポイント • ClaimsEndpoint : userInfoエンドポイント • client_secret : クライアントシークレット • OutputClaims : 属性マッピング 若干の調整として • HttpBindingはPOSTにする （TokenエンドポイントへのリクエストはPOST） • UsePolicyInRedirectUriは0にする （redirect_uriにポリシー名を含めない）
- 39. B2C_1A_TRUSTFRAMEWORKBASE.xml • Facebookのポリシーを参考に構成（Yahoo! JAPANのwell-known/openid-configurationより） • フロー（UserJourney）への追加
- 40. B2C_1A_TRUSTFRAMEWORKEXTENSIONS.xml • Facebookのポリシーを参考に構成（Yahoo! JAPANのwell-known/openid-configurationより） • client_id : クライアントID • scope : スコープ
- 41. ポリシーキーの追加 • ClaimsProviderに設定した名前でポリシーキーを作成 • Yahoo! JAPAN管理コンソールから取得したclient_secretを追加
- 42. ちゃんとつながる
- 43. デモ④ • カスタムポリシーでYahoo! JAPANを繋いでみる • IEF Starter PackのFacebook ClaimsProviderを参考に追加 • そのたもろもろ（時間があれば）
- 44. 応用 • カスタムポリシーのClaims Providerとして定義できるもの • 汎用プロトコル • OpenID Connect • OAuth1/2 • SAMLその他 • Technical Profileで実現可能なもの • REST API • Self-Asserted • 多要素認証 など
- 45. IEFのスキーマ定義 から見えるもの • None • OAuth1 • OAuth2 • SAML2 • OpenID Connect • WsFed • WsTrust • UProve11 • Proprietary https://github.com/Azure-Samples/active-directory-b2c-custom-policy- starterpack/blob/master/TrustFrameworkPolicy_0.3.0.0.xsd
- 47. まとめ • プロトコルがわかれば割と簡単にAzure AD B2Cと外部IDプロバイダを接続できる • 簡単なことはポータルから、複雑なことをやりたければカスタムポリシーを利用 • カスタムポリシーはクセはあるが慣れれば簡単 • 最近はAzureのドキュメントもちゃんと更新されるようになってきたので、たまに見ておくとよい