OpenID ConnectとSCIMの標準化動向

工藤達雄

株式会社野村総合研究所

http://www.linkedin.com/in/tatsuokudo

OpenID ConnectとSCIMの

標準化動向

http://www.linkedin.com/in/tatsuokudo

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

2


OpenID Connectとは http://openid.net/connect

OAuth 2.0 仕様をベースに「ゕデンテゖテゖ

層」を拡張した、OpenIDの次期バージョン

3

• OP（認可サーバー）へのユーザー認証の一元化 RP（クライアント）間のシングル・サインオン

• OP側へのユーザーのクレデンシャル（パスワードなど）管理の一元化

RP側のセキュリティ向上と管理負荷の低減

• OPからのユーザー属性情報取得 RPでの新規ユーザー登録の容易化

• エンドユーザーの認証とAPIアクセス認可の一体化ユーザー利便性の向上

http://openid.net/connect


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

SCIM

12


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

http://www.simplecloud.info/


例: ユーザー生成リクエスト

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

https://datatracker.ietf.org/wg/scim/charter/

Technology

OpenID ConnectとSCIMの標準化動向