SCIM and OpenID Connect Intro

SCIM と OpenID Connect の概要

2012年10月18日

工藤達雄株式会社野村総合研究所 IT基盤インテグレーション事業本部 DIソリューション事業部

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)

SCIM

2


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


利用企業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社


（RESTful API)

SaaS B社

JSON/XML

SCIM

Consumer

JSON/XML

http://www.simplecloud.info/


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

5


（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認可情報


例: ユーザー生成レスポンス

6


（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およびXMLへのバインディングを規定 ▪ スキーマを表現できない場合 (JSON) を考慮し、schemas属性を定義

スキーマ拡張モデル

LDAPのObjectClassの考え方を援用

しかしLDAPと異なり、スキーマの継承はない

7


SCIM Protocol

アプリケーション・レベルのAPIを定義

HTTPメソッドを利用

GET: リソース取得（全体/部分）

POST: 新規リソース生成

PUT: リソースの変更（指定した内容で置き換え）

PATCH: リソースの変更（部分更新）、パスワード変更

DELETE: リソース削除

Well knownなエンドポイントを定義

/Users, /Groups, /ServiceProviderConfigs, /Schemas, /Bulk

API認可はOAuth 2.0を推奨

8


これまでの流れ

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


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

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

OpenID Connect

11


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

OpenIDの次期バージョン

OAuth 2.0 仕様をベースに拡張

「シンプルな認証結果と属性情報の取得」 (後述) の範囲であれば、一般的なOAuth 2.0認可 + API アクセスのフローとほぼ同様

メッセージ形式にJSONを採用

加えてJWT (JSON Web Token) を活用することにより、

署名と暗号化をサポート

仕様のモジュラー化

かんたんなことをシンプルにする一方、複雑なことも実現可能に

12

http://openid.net/connect


OpenID Connectの系図

13

Source: http://civics.com/openid-connect-webinar/

http://civics.com/openid-connect-webinar/






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）


OpenID Connectによる認証結果の要求・取得の例 (*)

1. WebブラウザからRPの「ログイン」ボタンをクリック

15

認可

サーバークライアント認可


OpenID

プロバイダ OpenID


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 を元に作図

トークン


http://www.thread-safe.com/2012/07/how-simple-is-openid-connect-basic.html














OpenID Connectによる認証結果の要求・取得の例

2. WebブラウザがOPに認可リクエストを送信

16

認可

サーバークライアント

OpenID

プロバイダ

(OP)

OpenID


GET /authorize?grant_type=code&scope=openid&client_

id=3214244&state=af1Ef HTTP/1.1

Host: server.example.com

認可


トークン




3. OPがユーザーを認証

17

認可


OpenID

プロバイダ

(OP)

OpenID


何らかの方法でユーザーを認証

例: ID/パスワード、OTP、クッキー、…

認可


トークン




4. OPがWebブラウザをRPにリダイレクト

18

認可


OpenID

プロバイダ

(OP)

OpenID


Location: https://client.example.com/cb?code=8rFowi

dZfjt&state=af1Ef

OPがcodeを返却

認可


トークン




4. WebブラウザがRPに、OPから受け取ったcodeを送信

19

認可


OpenID

プロバイダ

(OP)

OpenID


GET /cb?code=8rFowidZfjt&state=af1Ef HTTP/1.1

Host: client.example.com

Webブラウザ経由でRPにcodeが渡る

認可


トークン




5. RPがOPにcodeを送信し、id_tokenをリクエスト

20

認可


OpenID

プロバイダ

(OP)

OpenID


GET /token?code=8rFowidZfjt HTTP/1.1

Host: server.example.com

Authorization: Basic …

codeを送信

認可


トークン




6. OPがRPに、codeにひもづくid_token他を返却

21

認可


OpenID

プロバイダ

(OP)

OpenID


{

"access_token": "SlAV32hkKG",

"token_type": "Bearer",

"refresh_token": "8xLOxBtZp8",

"expires_in": 3600,

"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.

eyJpc3MiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsInVz

ZXJfaWQiOiIyNDgyODk3NjEwMDEiLCJhdWQiOiJodHRwOi

8vY2iwiZXhwIjoxxpZW50LmV4YW1wbGUuY29tIMzExMjgxOTcwfSA.

eDesUD0vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ"

}

アクセス・トークン (*)

id_token

(*) UserInfoやその他のAPIアクセスに使用。本例では省略

認可


トークン




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に払い出されたユーザー識別子



8. RPがWebブラウザにコンテンツを返却

23

認可


OpenID

プロバイダ

(OP)

OpenID


OPから払い出されたユーザーID: 248289761001 にひもづくユーザーがすでに存在するか?

Yes → 「ようこそ、太郎さん!」 No → 「既存ユーザーとのひもづけ or 新規登録をお願いします」

認可


トークン



OpenID Connectの今後のロードマップ

現在Implementer’s Draftが公開中

今後最終仕様に

OpenID Connectをサポートする製品・サービスベンダー

（予定含む）

Gluu、IBM、Layer7、Microsoft、野村総合研究所、Ping Identity、

Vordel、…

AOL、Google、日本経済新聞社、PayPal、楽天、Salesforce.com、Yahoo! JAPAN、…

24

SCIM and OpenID Connect Intro

Technology

Transcript of SCIM and OpenID Connect Intro