100121 Scis2010 Itoh

認証連携方式と認可取得方式の
統合方式の一提案

伊藤宏樹† 横澤成彦†

† 日本電信電話株式会社

© 2010 NTT Information Sharing Platform Laboratories

本発表の流れ
1. はじめに
1. 連携アイデンティティ管理
2. 認証連携と認可取得
2. 課題とアプローチ
1. 認証連携と認可取得の連携
2. SAML、OAuth
3. 連携方式提案の考え方
3. 連携方式の提案
1. 組み合わせ方式
2. シーケンスの重畳例
3. メッセージの重畳例
4. まとめ
JR高松駅

2 © 2010 NTT Information Sharing Platform Laboratories

1.1. 連携アイデンティティ管理
 アイデンティティの3要素
– 識別子 (Identifiers)
• アイデンティティ（ある組織や個人など）を識別するための情報
– 属性 (Attributes)
• アイデンティティを特徴づける情報
– クレデンシャル (Credentials)
• 識別子、属性の伝達時に、内容の正当性を示すための情報

 連携アイデンティティ管理とは
– 「アイデンティティ」をサービス間で連携して利用すること
属性情報の記述
認証連携 (Liberty ID-SIS、OpenID AX等)
(SAML、OpenID等)  個人プロフィール、従業員プロフィール
 位置情報、カレンダーサービス等
ユーザ合意
属性情報へのアクセスの取得
 シングルサインオン (XACML、Liberty ID-WSF、OAuth等)
 シングルログアウト  ユーザ属性の管理者の探索方式
 アカウント連携等  属性情報のアクセス権限取得方式
 属性情報のサービス間の共有方式等


1.2. 認証連携と認可取得
 認証連携 (Single Sign-On) 認証要求
– あるウェブ上のサービスで認証実施者
認証要求者
行ったユーザ認証結果を他
のサービスに提供すること認証応答

– 例： SAML、OpenID
ユーザID ユーザ

 認可取得権限委譲
– あるウェブ上のサービスで属性管理者
属性要求者
必要となるユーザの認可（ア
クセス権限）を、他のサービ属性要求・提供
スに委譲すること
ユーザ属性
– 例： XACML、Liberty ID- ユーザ
WSF、OAuth


本発表の流れ
1. はじめに
2. SAML、OAuth
4. まとめ
高松城跡


課題認可取得に必要なユーザ認証の簡素化

サービス間のアクセス権限委譲（認可取得）に際し、
属性要求者、属性管理者が、対象となるユーザを識別
する必要がある
Aさんの情報に限り
アクセスを許可します
(3) 権限委譲
属性要求者
属性管理者
(4) 属性要求・提供
(1) ユーザ認証
Aさん (5) サービス提供
Aさん
(2) ユーザ認証に
基づくアクセス許可ユーザ

サービス間の認可取得におけるユーザ操作の簡素化には、
ユーザ認証と統合したワンストップ化が有効

2.2. SAML と OAuth
 SAML
– 認証連携方式の一種、OASIS SSTC* にて規定
– ユーザの認証結果をウェブ上のサービス間で共有する、サービス間の認
証要求、応答メッセージ、プロトコルを規定
• 認証トークン、要求、応答メッセージ： XML文書
• プロトコル： HTTP、SOAP 等
– 主な事例： Google Apps、SalesForce.com、NTTドコモ

 OAuth
– 認可取得方式の一種、IETF** にて規定
– ユーザ個々の制限された情報をウェブ上のサービス間で共有するために
必要な、ユーザの許可（認可）情報をサービス間で共有する
• 認証トークン、要求、応答メッセージ： HTTPパラメータ
• プロトコル： HTTP、REST
– 主な事例： Twitter、Yahoo!、mixi、goo （OpenSocial の一部機能としての
採用も含む）
* http://www.oasis-open.org/committees/security/
** http://tools.ietf.org/wg/oauth/


SAML の基本シーケンス
ブラウザ SAML IdP SAML SP
(認証実施者) （認証要求者）

1. サービス要求

2. SAML 認証要求
（HTTP Redirect もしくは HTTP POST を用いた要求メッセージ送信）

3. ユーザ認証

4. SAML 認証応答
（HTTP POST を用いた応答メッセージ送信）

5. ユーザ属性に基づくサービス提供

規定外
SAML


OAuth の基本シーケンス
ブラウザ OAuth SP Consumer
（属性管理者） (属性要求者)

（本稿では以下、省略） 2. コールバックURLの要求
3. OAuth 「未認可」リクエストトークン取得

4. OAuth 「認可済」リクエストトークン要求

5. ユーザ同意
6. OAuth 「認可済」リクエストトークン送信

7. アクセストークン取得
8. アクセストークンをもとにユーザの属性を要求，取得規定外

9. ユーザ属性に基づくサービス提供 OAuth


2.3. 連携方式提案の考え方
 コンコーディア
– 本検討を含む、ID管理技術間の相互運用方式は、 ID管理に
関する標準化団体カンターラ・イニシアティブ* の一分科会、
コンコーディア** で議論されている
– コンコーディアでは実サービスをイメージしたユースケースに
基づき、ID管理技術間の相互運用方式、複数ID管理技術の
重畳方式を提案している
本検討も2方式の統合方式をユースケースに基づき提案する

 その他の事例
– OpenID と OAuth との連携方式 (OpenID OAuth Extension)
が D. Balfanz らにより提案*** されている
* http://kantarainitiative.org/
** http://kantarainitiative.org/confluence/display/concordia/
*** http://step2.googlecode.com/svn/spec/openid_oauth_extension/


本発表の流れ
1. はじめに
2. SAML、OAuth
4. まとめ
第八十五番札所八栗寺


3.1. 認証連携方式と認可取得方式との組み合わせ
 認証連携  認可取得
認証要求権限委譲
SAML SP Consumer
SAML IdP OAuth SP
認証応答属性要求・提供

方式 SAML IdP が持つ機能 SAML SP が持つ機能
1 OAuth SP Consumer
2 Consumer OAuth SP
OAuth SP （サービス1）
3 （なし）
Consumer （サービス2）
OAuth SP （サービス1）
（なし）
Consumer （サービス2）


方式1 「通販サイトでポータルサイトの属性を利用」
ポータルサイト通販サイト
1. 要求
認証実施者認証要求者

2. 応答
属性管理者属性要求者

1. 通販サイトはポータルサイトにサービス提供に必要なユーザ
認証およびユーザ属性（ユーザの住所、氏名等）を同時に要
求する
（ユーザはポータルサイトで認証および属性提供を承認）
2. ポータルサイトは通販サイトにユーザ認証結果、ユーザ属性
取得用認可トークンを同時に通知する
（ユーザは通販サイトにてユーザ属性に基づくサービスを受ける）


方式2：「ポータルサイトでプロフ管理サイトの属性を利用」
ポータルサイトプロフ管理サイト
1. 認証要求

認証実施者認証要求者
2. 認証応答 + 属性要求

属性要求者 3. 属性応答属性応答者

1. プロフ管理サイトはポータルサイトにユーザ認証を要求する
2. ポータルサイトはプロフ管理サイトに認証結果を通知すると同
時に、ユーザ属性を要求する
（ユーザはプロフ管理サイトでユーザ属性提供を承認）
3. プロフ管理サイトは通販サイトにユーザ属性取得用認可トーク
ンを通知する
（ユーザはポータルにてユーザ属性に基づくサービスを受ける）


方式3：「通販サイトでプロフ管理サイトの属性を利用」
ポータルサイト

認証実施者
1. 認証要求

2. 認証応答

認証要求者認証要求者
3. 属性要求

属性要求者 4. 属性応答属性応答者

通販サイトプロフ管理サイト


方式3：「通販サイトでプロフ管理サイトの属性を利用」（続）

1.
2.
1.
通販サイト 3. プロフ管理サイト

1. 通販サイトは、ポータルサイトにユーザ認証、ポータルサイトを
介してプロフ管理サイトにユーザ属性を要求する
（ユーザはポータルサイトにて認証に必要な手続きを実施）
2. ポータルサイトはプロフ管理サイトに認証結果を通知すると同
時に、ユーザ属性を要求する
（ユーザはプロフ管理サイトでユーザ属性提供を承認）
3. プロフ管理サイトは通販サイトにユーザ属性取得用認可トーク
ンを通知する
（ユーザは通販サイトにてユーザ属性に基づくサービスを受ける）


3.2. シーケンスの重畳（方式1のケース）
ポータル通販事業者
枠内は SAML のメッセージに OAuth
のメッセージが重畳される OAuth SP OAuth Consumer


2. SAML 認証要求 + OAuth リクエストトークン要求

3. ユーザ認証および属性提供にかかるユーザ同意

4. SAML 認証応答，OAuth リクエストトークン送信

シングルサインオンと認可取得が同時に
実施されることでユーザ操作はポータル
6. アクセストークンをもとにユーザの属性を要求，取得
サイトにおける 3. に集約可能

規定外 SAML OAuth


3.3. メッセージの重畳例（方式1のケース） [1/2]
 SAML 認証要求＋ OAuth リクエストトークン要求
<samlp2:AuthnRequest
Destination=“https://idp.example.jp:8443/samlidp/sso_redirect”
ForceAuthn=“false” ID=“IDLREQnx0WrENJomAE2lXJe68Wxsmecltk”
ConsumerKey は AttributeConsumingServiceIndex
IsPassive=“false” IssueInstant=“2010-02-21T10:35:00Z”
を利用してメタデータで指定する
ProviderName=“SAML SP” Version=“2.0”
AttributeConsumingServiseIndex=“0"
xmlns:saml2=“urn:oasis:names:tc:SAML:2.0:assertion”
xmlns:samlp2=“urn:oasis:names:tc:SAML:2.0:protocol”>
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://demo.liberty.ntt:8443/samlsp/provider
</saml2:Issuer>
<samlp2:NameIDPolicy Scopeの指定はExtensionsを利用する
AllowCreate="false" （ConsumerKeyに対してScopeを固定して、メタデータに記述してもよい）
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
<samlp2:Extensions>
<ext:OAuth xmlns:ext=“http://www.ntt.co.jp/saml20/ext”>
<ext:scope>http://oauthsp.example1.jp/</ext:scope>
</ext:OAuth>
</samlp2:Extensions>
</samlp2:AuthnRequest>


3.3. メッセージの重畳例（方式1のケース） [2/2]
 SAML 認証応答＋ OAuth リクエストトークン発行
<samlp2:Response>
Assertion中のAttributeStatementに
<samlp2:Status> .... </samlp2:Status>
<saml2:Assertion> ・RequestToken
<saml2:Issuer> .... </saml2:Issuer> ・TokenVerifier
<saml2:Subject> .... </saml2:Subject> ・Scope
<saml2:Conditions> .... </saml2:Conditions> を設定して返却
<saml2:AuthnStatement> .... </saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement> RequestToken
<saml2:Attribute Name=“OAuthRequestToken">
<saml2:AttributeValue>
1/F62n8QnroCQ-Vmkee4S8tGATiaQZnWPB51nTvo8n9Sw
</saml2:AttributeValue>
</saml2:Attribute>
TokenVerifier
<saml2:Attribute Name=“OAuthRequestTokenVerifier">
<saml2:AttributeValue>hdhd0244k9j7ao03</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name=“OAuthScope">
<saml2:AttributeValue>http://oauthsp.example1.jp/</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement> Scope
</saml2:Assertion>
</samlp2:Response>


本発表の流れ
1. はじめに
2. SAML、OAuth
4. まとめ
次に進む


まとめ
 課題
– サービス間の認可取得におけるユーザ操作の簡素化のために、ユー
ザ認証と認可取得とを統合する方式が必要

 アプローチ
– 認証連携方式の1つである SAML 方式と、認可取得方式の1つである
OAuth 方式との統合方式を提案する

 提案内容
– 認証連携方式と、認可取得方式の各機能の配置から、3通りの統合方
式（ユースケース、シーケンス、メッセージ）を提案した。
1. SAML IdP が OAuth SP を兼ねる
2. SAML IdP が OAuth Consumer を兼ねる
3. 2つの SAML SP がそれぞれ、OAuth SP、OAuth Consumer を兼ねる

 今後の課題
– プロトタイプ化によるフィージビリティ検証


ご清聴ありがとうございました

皆様の参加をお待ちしております

http://kantarainitiative.org/

方式1 「通販サイトでポータルサイトの属性を利用」
ポータルサイト + OAuth リクエストトークン要求通販事業者
+ OAuth リクエストトークン送信
SAML IdP SAML SP
5. OAuth アクセストークン取得
OAuth
OAuth SP
Consumer
6. OAuth ユーザ属性要求，取得


3. ユーザ認証および属
性提供にかかるユーブラウザ 7. ユーザ属性に基づく
ザ同意サービス提供

方式2：「ポータルサイトでプロフ管理サイトの属性を利用」
+ OAuth リクエストトークン要求プロフィール
管理サイト
4. OAuth リクエストトークン送信
SAML IdP SAML SP
5. OAuth アクセストークン取得
OAuth
OAuth SP
Consumer 6. OAuth ユーザ属性要求、取得

1. サービス要求，
ユーザ認証

7. ユーザ属性に基づくブラウザ 3. 属性提供にかかる
サービス提供ユーザ同意


方式3：「通販サイトでプロフ管理サイトの属性を利用」
+ プロフ管理サイトへの遷移要求
+ OAuth リクエストトークン要求 6. OAuth リクエストトークン送信
プロフィール
ポータルサイト通販事業者
7. OAuth アクセス管理サイト
SAML トークン取得 SAML
SP1 SP2
SAML IdP 8. OAuth ユーザ
OAuth 属性要求，取得 OAuth SP
Consumer

4. SAML 応答
1. サービス要求 + OAuth リクエストトークン要求
9. サービス提供

3. ユーザ認証
ブラウザ 5. 属性提供にかかるユーザ
同意


シーケンス：方式1
OAuth SP OAuth Consumer


2. SAML 認証要求 + OAuth リクエストトークン要求

3. ユーザ認証 (optional) および属性提供にかかるユーザ同意

4. SAML 認証応答，OAuth リクエストトークン送信






OAuth Consumer OAuth SP
1-1. サービス要求

1-2. ユーザ認証 (optional)

2. SAML 認証応答 + OAuth リクエストトークン要求

3. 属性提供にかかるユーザ同意

4. リクエストトークン送信



7. ユーザ属性に基づくサービス提供規定外 SAML OAuth


ポータルプロフィール
ブラウザ通販事業者
サイト管理サイト
2. SAML プロフ管理サイトへの遷移要求 + OAuth リクエストトークン要求

3. ユーザ認証 (optional)
4. SAML 認証応答 + OAuth リクエストトークン要求

5. 属性提供にかかるユーザ同意
6. リクエストトークン送信



100121 Scis2010 Itoh

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie 100121 Scis2010 Itoh

Ähnlich wie 100121 Scis2010 Itoh (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)

100121 Scis2010 Itoh