OpenID ConnectとSCIMの標準化動向

工藤達雄
株式会社野村総合研究所
http://www.linkedin.com/in/tatsuokudo
OpenID ConnectとSCIMの
標準化動向

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)

OpenID Connectとは
http://openid.net/connect
OAuth 2.0 仕様をベースに「ゕ゗デンテゖテゖ
層」を拡張した、OpenIDの次期バージョン
3
• OP（認可サーバー）へのユーザー認証の一元化
RP（クライアント）間の
シングル・サインオン
• OP側へのユーザーのクレデンシャル（パスワードなど）
管理の一元化
RP側のセキュリティ
向上と管理負荷の低減
• OPからのユーザー属性情報取得
RPでの新規ユーザー
登録の容易化
• エンドユーザーの認証とAPIアクセス認可の一体化ユーザー利便性の向上

OpenID Connectによるフェデレーションの中心は
「IDトークン」
 エンドユーザの関与の元、
RPがOPに「IDトークン」
というデータを要求する
（認可リクエスト）
 OPはエンドユーザーの認証
と、情報およびサービス
提供に関する同意を確認
し、IDトークンをRPに返却
 RPはこの「IDトークン」を
用いてエンドユーザーを
識別し、ゕクセス可否を
行う
4

IDトークンの中身
 OPにおけるユーザ認証゗ベントの情報
 「このエンドユーザーは○○で、何時何分に、こういう方法で認証を受け、認証レ
ベルは○で、…」
 RPは主に、IDトークンに含まれる以下のクレーム（OPがユーザーに関して表
明する情報）を用いて、エンドユーザーのゕクセス認可を行う
 エンドユーザーを識別する値（識別子）
 IDトークンの有効期限
 ユーザ認証を実施した日時
 認証コンテクスト・クラス・リフゔレンス
 認証手段リフゔレンス
 IDトークンにはこの他に
ユーザー属性が含まれる
こともある
5

RPからOPへのIDトークンの要求
 RPは認可リクエストに際し、IDトークンに含めてほしいクレームや、IDトー
クン生成にあたりどのような認証゗ベントを求めるかを指定
 OPはその指定を考慮した上でIDトークンを返却
 指定可能な内容の例
 クレームのセット
 認証および同意確認の際のUI
 認証や同意の再実行の要否
 エンドユーザを明示的に認証してからの経過時間
 UIやクレームのロケール
 OPがエンドユーザを
認証する際のヒント
 認証コンテクスト・
クラス・リフゔレンスの値
6

プロトコル・フロー (1): 認可コードフロー
IDトークンをRP/OP間で直接授受
 フロー概要
 RPからOPへエンドユーザを経由して
認可リクエストを送信
 OPが「認可コード」と呼ばれる値を
エンドユーザ経由でRPに返却
 RPがその認可コードをOPに送信して
IDトークン（ならびにゕクセストーク
ン）取得
 特徴
 IDトークンのやりとり（トークン・
リクエスト/レスポンス）がRPとOPとの
直接通信によって行われれる
▪ OPによるIDトークンへの署名は基本的には
不要となり、RP側での署名検証処理も発生
しない
7

プロトコル・フロー (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

ユーザー属性のリクエスト
 認可リクエストのscopeパラメーターを用いて「クレームの
セット」を指定する方法が一般的
 OpenID Connectではクレームのセットとして以下を定義
 profile（既定のプロフゔ゗ル）、email（メールゕドレス）、
address（住所）phone（電話番号）
 OPが独自に定義した「ユーザ属性のセット」をRPが指定する
ことも可能
9
scope=openid profile email http://example.com/employeeAttrs

ユーザー属性の提供
 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

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

これまでのアイデンティティ・プロビジョニング
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

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

例: ユーザー生成リクエスト
15
（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認可情報

例: ユーザー生成レスポンス
16
（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

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

SCIM Protocol
 ゕプリケーション・レベルのAPIを定義
 HTTPメソッドを利用
 GET: リソース取得（全体/部分）
 POST: 新規リソース生成
 PUT: リソースの変更（指定した内容で置き換え）
 PATCH: リソースの変更（部分更新）、パスワード変更
 DELETE: リソース削除
 Well knownなエンドポ゗ントを定義
 /Users, /Groups, /ServiceProviderConfigs, /Schemas, /Bulk
 API認可はOAuth 2.0を推奨
18

今後の予定
 ゗ンタロップ @ 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

OpenID ConnectとSCIMの標準化動向

OpenID ConnectとSCIMの標準化動向

More Related Content

OpenID ConnectとSCIMの標準化動向