Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SCIM and OpenID Connect Intro

SCIM and OpenID Connect Intro

Prepared for a new working group to be formed in OpenID Foundation Japan

Avatar for Tatsuo Kudo

Tatsuo Kudo

October 18, 2012
Tweet

More Decks by Tatsuo Kudo

Other Decks in Technology

Transcript

  1. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    ID管理システム プロビ ジョニング システム SSO / アクセス 管理 システム SCIMとOpenID Connect ユーザー・ プロビジョニングAPI (SCIM Server) エンドユーザー向けWeb アプリケーション (OpenID Connect RP) 社内の ユーザー追加・ 変更・削除 サービスAの 利用 管理者 エンドユーザー 利用企業A社 SaaS A社 ユーザー・ プロビジョニングAPI (SCIM Server) エンドユーザー向けWeb アプリケーション (OpenID Connect RP) SaaS B社 サービスBの 利用 SCIM APIに従い、 サービスBの ユーザー追加・ 変更・削除 SCIM APIに従い、 サービスAの ユーザー追加・ 変更・削除 OpenID Connectで認 証結果・属性 情報要求 社内IDで ログイン OpenID Connectで ID管理結果・属性情 報要求 人事情報 システム 社内の ユーザー追加・ 変更・削除 ID連携API (OpenID Connect IdP) プロビジョニン グ機能(SCIM Client)
  2. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    これまでのアイデンティティ・プロビジョニングAPIの標準化動向 SPML (Service Provisioning Markup Language) 仕様 OASIS プロビジョニング・サービ ス技術委員会(PSTC) が策定し た、 XMLによってサービス・プロ ビジョニング情報を交換するため のフレームワーク ▪ 2001年のPSTC発足後、2003年 にバージョン1.0を、2006年にバー ジョン2.0をOASIS標準として承認 しかし、仕様の複雑さや、対応す る製品・サービスが少ないことか ら、普及していない ▪ SPML 2.0の確定以降、PSTCは 実質的に活動を停止し、2012年8 月に閉会 一方、「クラウド・サービス」の 多くがユーザー・プロビジョニン グAPIを提供しているが、標準 的な仕様が存在しない 「クラウド・サービス」ごとにAPIが まちまちであり、互換性がな い そのためユーザー企業が自社ID 管理システムからプロビジョニン グを行うためには、たとえばユー ザの追加・削除といった単純な操 作で あっても、クラウド・サービス ごとに異なるAPIに対応しなくて はならない 3
  3. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    利用企業A社 SCIM (System for Cross-domain Identity Management) http://www.simplecloud.info/ アイデンティティ管理のための「スキーマ」と「プロトコル」を定義 スキーマ ▪ ユーザーやグループなどのJSON/XML表現 ▪ 要件に応じて拡張可能 プロトコル ▪ RESTful API ▪ CRUD (生成/参照/更新/削除)、検索、ディスカバリ、一括処理 4 プロビ ジョニング システム SCIM Service Provider (RESTful API) SaaS A社 SCIM Service Provider (RESTful API) SaaS B社 JSON/XML SCIM Consumer JSON/XML
  4. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    例: ユーザー生成リクエスト 5 SCIM Service Provider (RESTful API) リクエスト SCIM Consumer POST /Users HTTP/1.1 Host: example.com Accept: application/json Content-Type: application/json Authorization: Bearer h480djs93hd8 Content-Length: ... { "schemas":["urn:scim:schemas:core:1.0"], "userName":"bjensen", "externalId":"bjensen", "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara“ } } /Users エンドポイント にPOST ユーザー情報 JSON形式 のレスポンス を要求 JSON形式 にてユーザー 情報を送信 API認可情報
  5. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    例: ユーザー生成レスポンス 6 SCIM Service Provider (RESTful API) レスポンス SCIM Consumer HTTP/1.1 201 Created Content-Type: application/json Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 ETag: W/"e180ee84f0671b1" { "schemas":["urn:scim:schemas:core:1.0"], "id":"2819c223-7f76-453a-919d-413861904646", "externalId":"bjensen", "meta":{ "created":"2011-08-01T21:32:44.882Z", "lastModified":"2011-08-01T21:32:44.882Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d- 413861904646", "version":"W¥/¥"e180ee84f0671b1¥"" }, "name":{ "formatted":"Ms. Barbara J Jensen III", "familyName":"Jensen", "givenName":"Barbara" }, "userName":"bjensen" } ステータス コード 201 生成された ユーザー 情報の表現 このユーザー 情報のURL
  6. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    Core Schema ユーザー/グループを表現する最小限のスキーマと、スキー マの拡張モデルを定義 スキーマ 既存のクラウドサービス事業者のAPI、Portable Contacts、LDAPな どを参考に定義 ▪ ユーザー、エンタープライズ・ユーザー、グループ、サービス・プロバイダの設定 情報、リソース JSONおよびXMLへのバインディングを規定 ▪ スキーマを表現できない場合 (JSON) を考慮し、schemas属性を定義 スキーマ拡張モデル LDAPのObjectClassの考え方を援用 しかしLDAPと異なり、スキーマの継承はない 7
  7. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    SCIM Protocol アプリケーション・レベルのAPIを定義 HTTPメソッドを利用 GET: リソース取得(全体/部分) POST: 新規リソース生成 PUT: リソースの変更(指定した内容で置き換え) PATCH: リソースの変更(部分更新)、パスワード変更 DELETE: リソース削除 Well knownなエンドポイントを定義 /Users, /Groups, /ServiceProviderConfigs, /Schemas, /Bulk API認可はOAuth 2.0を推奨 8
  8. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    これまでの流れ  2010年7月  Cloud Identity Summitのアンカンファレンスの「Cloud LDAP」セッションを契機に、UnboundID、Salesforce.com、Google、 Ping Identityのキーパーソンが同名プロジェクト(のちに「Cloud Directory」に変更)を立ち上げ  2010年11月  IIW (Internet Identity Workshop) 11 にて、上記のメンバーおよびMicrosoft他によるF2Fを開催  2011年4月  名称をSCIMに変更し、草案を一般に公開  2011年5月  IIW 12 にて議論  UnboundID, Salesforce.com, Cisco, Ping IdentityがOWF Contributor Agreementに署名  2011年12月  バージョン1.0仕様をリリース  2012年3月  BoF at IETF 83  2012年6月  WG chartered  2012年7月  バージョン1.1 仕様をリリース  第一回WG会合 @ IETF84 9
  9. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    SCIMのマイルストーン 10 Source: System for Cross-domain Identity Management (scim) – Charter https://datatracker.ietf.org/wg/scim/charter/ 年 マイルストーン 2012 •6月: Initial adoption of SCIM use cases, as a living document •6月: Initial adoption of SCIM core schema •8月: Initial adoption of SCIM restful interface draft •11月: Initial adoption of SCIM LDAP inetOrgPerson mapping draft •12月: Snapshot version of SCIM use cases to IESG as Informational (possibly) •12月: Proposal for client targeting of SCIM endpoints 2013 •2月: SCIM core schema to IESG as Proposed Standard •5月: SCIM restful interface to IESG as Proposed Standard •6月: SCIM LDAP inetOrgPerson mapping to IESG as Informational •7月: Initial adoption of SCIM SAML bindings draft •8月: Client targeting of SCIM endpoints to IESG as Proposed Standard •9月: Snapshot update of SCIM use cases as Informational (possibly) •11月: SCIM SAML bindings to IESG as Proposed Standard 2014 •1月: Work completed; discuss re-charter
  10. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectとは http://openid.net/connect OpenIDの次期バージョン OAuth 2.0 仕様をベースに拡張 「シンプルな認証結果と属性情報の取得」 (後述) の範囲であれば、 一般的なOAuth 2.0認可 + API アクセスのフローとほぼ同様 メッセージ形式にJSONを採用 加えてJWT (JSON Web Token) を活用することにより、 署名と暗号化をサポート 仕様のモジュラー化 かんたんなことをシンプルにする一方、複雑なことも実現可能に 12
  11. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectの系図 13 Source: http://civics.com/openid-connect-webinar/
  12. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectのフロー(概要) 14 認可 サーバー ユーザー 情報 (クレーム) 3. ユーザー 認証・認可 クライアント 5. ユーザー属性 提供要求 クレーム プロバイダ クレーム ソース UserInfo エンドポイント エンドユーザー 認可 エンドポイント 1. サービスに アクセス OpenID プロバイダ 3 1 2 4 2. トークン 取得要求 (ブラウザの リダイレクト) 4. アクセス・ トークンとID トークンを返却 (ブラウザの リダイレクト) 5 6 6 . ユーザー 属性提供 7.(オプション): ユーザー属性 提供要求 7 8 8. (オプショ ン): ユーザー 属性提供 9 . サービス 提供 9 OpenID リライング・ パーティ (RP)
  13. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 (*) 1. WebブラウザからRPの「ログイン」ボタンをクリック 15 認可 サーバー クライアント 認可 エンドポイント OpenID プロバイダ OpenID リライング・ パーティ (RP) example.comの IDでログイン! <a href="https://server.example.com/authorize?grant _type=code&scope=openid&client_id=3214244&state=af1 Ef">example.comのIDでログイン!</a> (*) 本ページ以降の例示は http://www.thread- safe.com/2012/07/how-simple-is-openid-connect- basic.html を元に作図 トークン エンドポイント
  14. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 2. WebブラウザがOPに認可リクエストを送信 16 認可 サーバー クライアント OpenID プロバイダ (OP) OpenID リライング・ パーティ (RP) GET /authorize?grant_type=code&scope=openid&client_ id=3214244&state=af1Ef HTTP/1.1 Host: server.example.com 認可 エンドポイント トークン エンドポイント
  15. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 3. OPがユーザーを認証 17 認可 サーバー クライアント OpenID プロバイダ (OP) OpenID リライング・ パーティ (RP) 何らかの方法でユーザーを 認証 例: ID/パスワード、OTP、 クッキー、… 認可 エンドポイント トークン エンドポイント
  16. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 4. OPがWebブラウザをRPにリダイレクト 18 認可 サーバー クライアント OpenID プロバイダ (OP) OpenID リライング・ パーティ (RP) Location: https://client.example.com/cb?code=8rFowi dZfjt&state=af1Ef OPがcodeを 返却 認可 エンドポイント トークン エンドポイント
  17. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 4. WebブラウザがRPに、OPから受け取ったcodeを送信 19 認可 サーバー クライアント OpenID プロバイダ (OP) OpenID リライング・ パーティ (RP) GET /cb?code=8rFowidZfjt&state=af1Ef HTTP/1.1 Host: client.example.com Webブラウザ 経由でRPに codeが渡る 認可 エンドポイント トークン エンドポイント
  18. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 5. RPがOPにcodeを送信し、id_tokenをリクエスト 20 認可 サーバー クライアント OpenID プロバイダ (OP) OpenID リライング・ パーティ (RP) GET /token?code=8rFowidZfjt HTTP/1.1 Host: server.example.com Authorization: Basic … codeを送信 認可 エンドポイント トークン エンドポイント
  19. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 6. OPがRPに、codeにひもづくid_token他を返却 21 認可 サーバー クライアント OpenID プロバイダ (OP) OpenID リライング・ パーティ (RP) { "access_token": "SlAV32hkKG", "token_type": "Bearer", "refresh_token": "8xLOxBtZp8", "expires_in": 3600, "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9. eyJpc3MiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsInVz ZXJfaWQiOiIyNDgyODk3NjEwMDEiLCJhdWQiOiJodHRwOi 8vY2iwiZXhwIjoxxpZW50LmV4YW1wbGUuY29tIMzExMjgxOTcwfSA. eDesUD0vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ" } アクセス・ トークン (*) id_token (*) UserInfoやその他のAPIアクセスに 使用。本例では省略 認可 エンドポイント トークン エンドポイント
  20. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 7. RPがid_tokenを復号し、OPが返却したuser_idを取得 22 { "iss": "https://server.example.com", "user_id": "248289761001", "aud": "3214244", "iat": 1311195570, "exp": 1311281970 } eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9. eyJpc3MiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsInVz ZXJfaWQiOiIyNDgyODk3NjEwMDEiLCJhdWQiOiJodHRwOi 8vY2iwiZXhwIjoxxpZW50LmV4YW1wbGUuY29tIMzExMjgxOTcwfSA. eDesUD0vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ <?php $res = json_decode($response, true); $id_token = $res['id_token']; $id_array = mb_split(".", $id_token); $id_body = base64url_decode($id_array[1]); ?> RP側での復号処理 (例はPHPによる実装例。 ピリオド “.” で3分割し、2番目の パートをbase64urlデコード) 認証結果 (JWT Claims Set) RPが受け取った id_tokenの値 認証結果 ( base64urlデコードされた JWT Claims Set) user_idの値 = OPからRPに 払い出された ユーザー識別子
  21. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectによる認証結果の要求・取得の例 8. RPがWebブラウザにコンテンツを返却 23 認可 サーバー クライアント OpenID プロバイダ (OP) OpenID リライング・ パーティ (RP) OPから払い出されたユーザーID: 248289761001 にひもづくユーザーが すでに存在するか? Yes → 「ようこそ、太郎さん!」 No → 「既存ユーザーとのひもづけ or 新規登録をお願いします」 認可 エンドポイント トークン エンドポイント
  22. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

    OpenID Connectの今後のロードマップ 現在Implementer’s Draftが公開中 今後最終仕様に OpenID Connectをサポートする製品・サービスベンダー (予定含む) Gluu、IBM、Layer7、Microsoft、野村総合研究所、Ping Identity、 Vordel、… AOL、Google、日本経済新聞社、PayPal、楽天、Salesforce.com、 Yahoo! JAPAN、… 24