OpenID ConnectとSCIMの標準化動向

Transcript

1. 工藤達雄 株式会社野村総合研究所 http://www.linkedin.com/in/tatsuokudo OpenID ConnectとSCIMの 標準化動向
2. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. ID管理システム プロビ ジョニング システム SSO / アクセス 管理 システム OpenID ConnectとSCIM ユーザー・ プロビジョニング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)
3. OpenID Connect 2
4. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. OpenID Connectとは http://openid.net/connect OAuth 2.0 仕様をベースに「ゕ゗デンテゖテゖ 層」を拡張した、OpenIDの次期バージョン 3 • OP（認可サーバー）へのユーザー認証の一元化 RP（クライアント）間の シングル・サインオン • OP側へのユーザーのクレデンシャル（パスワードなど） 管理の一元化 RP側のセキュリティ 向上と管理負荷の低減 • OPからのユーザー属性情報取得 RPでの新規ユーザー 登録の容易化 • エンドユーザーの認証とAPIアクセス認可の一体化 ユーザー利便性の向上
5. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. OpenID Connectによるフェデレーションの中心は 「IDトークン」  エンドユーザの関与の元、 RPがOPに「IDトークン」 というデータを要求する （認可リクエスト）  OPはエンドユーザーの認証 と、情報およびサービス 提供に関する同意を確認 し、IDトークンをRPに返却  RPはこの「IDトークン」を 用いてエンドユーザーを 識別し、ゕクセス可否を 行う 4
6. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. IDトークンの中身  OPにおけるユーザ認証゗ベントの情報  「このエンドユーザーは◦◦で、何時何分に、こういう方法で認証を受け、認証レ ベルは◦で、…」  RPは主に、IDトークンに含まれる以下のクレーム（OPがユーザーに関して表 明する情報）を用いて、エンドユーザーのゕクセス認可を行う  エンドユーザーを識別する値（識別子）  IDトークンの有効期限  ユーザ認証を実施した日時  認証コンテクスト・クラス・リフゔレンス  認証手段リフゔレンス  IDトークンにはこの他に ユーザー属性が含まれる こともある 5
7. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. RPからOPへのIDトークンの要求  RPは認可リクエストに際し、IDトークンに含めてほしいクレームや、IDトー クン生成にあたりどのような認証゗ベントを求めるかを指定  OPはその指定を考慮した上でIDトークンを返却  指定可能な内容の例  クレームのセット  認証および同意確認の際のUI  認証や同意の再実行の要否  エンドユーザを明示的に認証してからの経過時間  UIやクレームのロケール  OPがエンドユーザを 認証する際のヒント  認証コンテクスト・ クラス・リフゔレンスの値 6
8. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. プロトコル・フロー (1): 認可コードフロー IDトークンをRP/OP間で直接授受  フロー概要  RPからOPへエンドユーザを経由して 認可リクエストを送信  OPが「認可コード」と呼ばれる値を エンドユーザ経由でRPに返却  RPがその認可コードをOPに送信して IDトークン（ならびにゕクセストーク ン）取得  特徴  IDトークンのやりとり（トークン・ リクエスト/レスポンス）がRPとOPとの 直接通信によって行われれる ▪ OPによるIDトークンへの署名は基本的には 不要となり、RP側での署名検証処理も発生 しない 7
9. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. プロトコル・フロー (2): Implicitフロー OPがIDトークンをエンドユーザ経由でRPに返却  フロー概要  エンドユーザ経由でOPがIDトークン （ならびにゕクセストークン）をRPに 返却  特徴  IDトークンの授受に関し、RPからOP への通信が発生しない ▪ RPからOPへの直接通信が行えない環境 にも適用することが可能 ▪ OPによるIDトークンへの署名、および RP側での署名検証処理は必須  OPはIDトークンをURLフラグメントに エンコードしてRPに返却 ▪ RPはWebブラウザになんらかのスクリプ トをダウンロードさせて、そのスクリプ トによってフラグメントからIDトークン を抽出し、Webサーバー・ゕプリケー ションに送信させることとなる 8
10. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. ユーザー属性のリクエスト  認可リクエストのscopeパラメーターを用いて「クレームの セット」を指定する方法が一般的  OpenID Connectではクレームのセットとして以下を定義  profile（既定のプロフゔ゗ル）、email（メールゕドレス）、 address（住所）phone（電話番号）  OPが独自に定義した「ユーザ属性のセット」をRPが指定する ことも可能 9 scope=openid profile email http://example.com/employeeAttrs
11. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. ユーザー属性の提供  OpenID Connect仕様では二通りの方法を定義  RPに返却するIDトークンに含める（前述）  RPがゕクセス可能なUserInfoエンドポ゗ントを用意する  UserInfoエンドポ゗ント  OPがRPにユーザー情報を提供するためのAPI  OAuth 2.0仕様の「保護されたリソース（Protected Resource）」 ▪RPは、認可リクエストの際にIDトークンと同時にOPから取得 したゕクセストークンを用いて、このUserInfoエンドポ゗ント にゕクセスする  UserInfoエンドポ゗ントは、ユーザー情報を、通常は JSON形式にてRPに返却する 10 RP OP
12. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. OpenID Connectの今後のロードマップ 現在Implementer’s Draftが公開中  今後最終仕様に OpenID Connectを実装した製品・サービスの例 Yahoo! JAPAN (YConnect)、日本経済新聞社 （日経ID）、東急電鉄、Google、PayPal (Log In with PayPal)、野村総合研究所（Uni-ID）、 Ping Identity （PingFederate）、Gluu (OX)、Layer 7 11
13. SCIM 12
14. Copyright 2013 OpenID Foundation Japan - 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に対応しなくて はならない 13
15. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 利用企業A社 SCIM (System for Cross-domain Identity Management) http://www.simplecloud.info/  ゕ゗デンテゖテゖ管理のための「スキーマ」と「プロトコル」を定義  スキーマ ▪ユーザーやグループなどのJSON表現 ▪要件に応じて拡張可能  プロトコル ▪RESTful API ▪CRUD (生成/参照/更新/削除)、検索、デゖスカバリ、一括（バルク）処理 14 プロビ ジョニング システム SCIM Service Provider （RESTful API) SaaS A社 SCIM Service Provider （RESTful API) SaaS B社 JSON SCIM Consumer JSON
16. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 例: ユーザー生成リクエスト 15 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認可情報
17. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 例: ユーザー生成レスポンス 16 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
18. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. Core Schema  ユーザー/グループを表現する最小限のスキーマと、スキーマの拡張モデルを 定義  スキーマ  既存のクラウドサービス事業者のAPI、Portable Contacts、LDAPなどを参考に定義 ▪ユーザー、エンタープラ゗ズ・ユーザー、グループ、サービス・プロバ゗ダの設定情報、リソー ス  JSONへのバ゗ンデゖングを規定 ▪スキーマを表現できない場合 (JSON) を考慮し、schemas属性を定義  スキーマ拡張モデル  LDAPのObjectClassの考え方を援用  しかしLDAPと異なり、スキーマの継承はない 17
19. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. SCIM Protocol  ゕプリケーション・レベルのAPIを定義  HTTPメソッドを利用  GET: リソース取得（全体/部分）  POST: 新規リソース生成  PUT: リソースの変更（指定した内容で置き換え）  PATCH: リソースの変更（部分更新）、パスワード変更  DELETE: リソース削除  Well knownなエンドポ゗ントを定義  /Users, /Groups, /ServiceProviderConfigs, /Schemas, /Bulk  API認可はOAuth 2.0を推奨 18
20. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 今後の予定  ゗ンタロップ @ Cloud Identity Summit 2013 (来週)  Core SchemaおよびProtocolのフゔ゗ナラ゗ズ 19 マイルストーン（当初の予定） 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