ID (アイデンティティ) フェデレーションに関する技術動向と今後の方向性

ID (アイデンティティ) フェデレーションに関する

技術動向と今後の方向性

2012年9月19日

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

Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.

概要

IT サービスが個々に管理しているユーザーの ID (アイデンティティ) 情報をひもづけることによって、サービス間のデータや機能をユーザーを中心に連携する「ID (アイデンティティ)

フェデレーション」について、その概念や、SAML (Security

Assertion Markup Language), OpenID, OAuth, OpenID

Connect などの関連技術仕様の動向、ならびに今後の方向性について概説します。

1


「ＩＤ統合」と「ＩＤ連携」は何が違うのか？

ID統合複数サービスのID関連情報を一ヶ所に集約し、一元管理することが目的

ユーザーベースがサービス間で共通である場合に向いている ▪ 組織内導入など

ID連携複数サービスのID関連情報を相互にひもづけ、サービス連携を行うことが目的

ユーザーベースがサービス毎に異なる場合に向いている ▪ 企業間の協業や他社サービス利用など

▪ 組織内であってもサービス間に技術的・政治的な壁がある場合など

サービスサービスサービス

サービス

各サービス固有のID情報を一ヶ所に集約

サービス（ユーザー認証のみ

外部化したい）

サービス（一部の属性情報

管理を外部化したい）

サービス

ひもづけ情報を交換

既存の ID情報 DBを廃止

複数の

サービスが

共用する

ID情報DBを

構築

既存の ID情報 DBはそのまま維持

サービス間のひもづけ情報を管理するDB

を構築

サービス（ひもづけに基づく

API連携を行いたい）

ユーザー

認証

属性提供

業務A

PI

ひもづけに

基づいて

ID情報や

業務機能を提供

2


ID連携の例

コンシューマー向けサイトに他サービスのIDでログイン

3

ネットスーパーに

ポータルサイトのIDでログイン

デジタルコンテンツ販売サイトに

ECサイトのIDでログイン

Source: https://kids.showtime.jp/users/login

Source: https://www.iy-net.jp/

https://kids.showtime.jp/users/login

https://www.iy-net.jp/




ID連携の例

社内IDを用いて社外システムにログインし、サービスを連携

4

ID情報

（部門、役職、内線、…）

1

2

3

4

8

5

6

7

企業

2. ユーザのID情報を要求（認証リクエスト）

4. ユーザのID情報を返却（認証レスポンス）

同時に「トークン」（API アクセス権の情報）を返却

5. 「トークン」を用いて、ユーザーに成り代わってWebサービスの

APIを呼び出し

会社A

ID連携システム

会社Aユーザ

会社A

Webサービス Webアプリケーション

6. 「トークン」の有効性・真正性を確認

7. 処理結果（業務データなど）を返却

8. 企業をまたがって

マッシュアップしたコンテンツを提供

全社共有情報

・インフルエンザ・CSR活動参加・海外渡航注意喚起・セミナー連絡などなど

部門向け情報個人向け情報・賞与・保険加入・人間ドック・申請状況一覧・○○部組合員情報など

プロジェクト

向け情報

3. 社内のIDでユーザ認証

会社A 共通IDシステム

会社AのIDでログイン

1. 社外のアプリケーションにアクセス

業務データ

Web

AP

I


ID連携の例

通信事業者のIDを使ってネット決済

5

My SoftBank認証

auかんたん決済

Source: https://id.auone.jp/payment/pc/guide/idm/index.html

Source: http://mb.softbank.jp/mb/support/procedure/service_terminal/mysb_auth/,

http://mb.softbank.jp/mb/support/procedure/service_terminal/mysb_auth/payment/

https://id.auone.jp/payment/pc/guide/idm/index.html

http://mb.softbank.jp/mb/support/procedure/service_terminal/mysb_auth/

http://mb.softbank.jp/mb/support/procedure/service_terminal/mysb_auth/payment/


ID連携の例

電子書籍サイトのコンテンツをパーソナル・クラウドに保存

6

1. 電子書籍サイトからパーソナル・クラウドのIDとのひもづけを開始

2. パーソナル・クラウドでユーザー認証を行い、電子書籍サイトからの接続を許可

３. 電子書籍サイトにて「同期」を実行

4. ローカルにダウンロードするのではなく、パーソナル・クラウドに保存完了

Source: https://members.oreilly.com/cs/members/edit

https://members.oreilly.com/cs/members/edit


ID連携の例

ネット証券の機能をパートナーサイトに提供

自社の株式取引サービスをAPI化

ユーザーがネット証券サイトに管理しているポートフォリオへのアクセスや、ユーザーの代理で売買注文を行う機能を提供

パートナーサイトはID連携によってユーザーの同意を確認

▪ パートナーサイトの例: ロボット売買、売買シグナルなど

7

ＷｅｂＡＰＩの提供

サービスの提供

Source: https://us.etrade.com/e/t/invest/apihome


ID連携技術の利用形態

8

サービス利用側サービス提供側

ID情報

管理機能

ID情報提供機能（Identity

Provider; IdP）

ID情報受入機能（Relying

Party; RP)

サービス

ID情報（認証結果、

属性情報など）の要求

ID情報の参照

ID情報の提供

ユーザ認証

ID情報の伝播

サービスへ

アクセス

ID情報

管理機能

ID情報の紐付け

ID連携技術の適用領域


ID連携に関連する仕様

SAML（Security Assertion Markup Language: サムル）

サービス間でのアイデンティティ情報（セキュリティ・アサーション）および流通方法を定義した汎用的な仕様

OpenID（オープンアイディー）

Webサイト間でのWebブラウザを介したアイデンティティ情報（認証結果と属性情報）の要求・提供プロトコルを定義した仕様

OAuth（オーオース）サービス間でのAPI (Application Programming Interface) のアクセス認可情報（アクセス・トークン）の要求・提供・利用を定義した仕様

OpenID Connect（オープンアイディー・コネクト）

OAuth（バージョン2.0）をベースに、APIアクセス認可とアイデンティティ情報の要求・提供を統合した仕様

9

SAML

10


SAMLとは

標準化団体OASIS Openにて仕様化されたアイデンティティ情報を安全に流通させるためのXML形式、及び通信仕様

11

出典：第一回Liberty Alliance技術セミナー資料

Single Sign On(SSO)を実現

IdPからSPに対して、SAMLアサーションを流通させる

一般的なブラウザが対応するHTTPプロトコル上でSSO

セキュアな情報交換

SSOだけでなく、IdP-SP間で安全に情報交換を行うサーバ間通信についても規定

Circle of Trustモデル

事前に情報交換を行う相手と強固な信頼関係を結ぶ（PKI鍵交換を含む）


SAMLとは

ID連携を実現する主要要素を4つに分解し、サービス連携のための包括的な仕様を構成アサーション

プロトコル

バインディング

プロファイル

SAMLのコアは

「アサーション」

XML形式

12

Profile

特定のユースケース（SSOなど）を実現するうえでの、アサーション、プロトコル、バインディングの組み合わせを規定。

Binding

リクエストおよびレスポンスの手続きを、実際にIdPとRP

の間でどのように実施するか規定。直接通信（SOAP）や、ユーザエージェントを介在させるHTTPリダイレクト通信な

どが存在。

Protocol

アサーションの送受信を実施するためのリクエストおよびレスポンスの手続き。

Assertion

ユーザのID名や認証方法およびそのユーザの属性や権限に関する表明。


SAML仕様構成要素

13

ユーザに関するアイデンティティ情報を以下のとおり表明します:

ユーザID: taro

認証方法: パスワード

氏名: 山田太郎

メールアドレス: …

アサーションプロトコル

バインディングプロファイル

アイデン

ティティ・プロバイダ

(IdP)

サービス

プロバイダ

(SP) (RP)

リクエスト

レスポンス

アサーション

アイデン


(IdP)

サービス

プロバイダ

(SP) (RP)

ユーザ・エージェント

レスポンス

アサーションブラウザをリダイレクトさせてレスポンスを伝達

アイデン


(IdP)

サービス

プロバイダ

(SP) (RP)

ユーザ・エージェント

レスポンス

アサーション

1. SPからIdPにアサーションをリクエスト

3. アサーションを提供

リクエスト

2.ログインを要求


仕様要素の組み合わせで多様なユースケースを実現

SAMLで最も代表的なユースケース(Web SSO) ブラウザ（Client）を介して、IdPからSP(RP)に対してアサーションを受け渡し

14

Client SP(RP) IdP

Binding：HTTP Redirect, POST

Protocol：Authentication Request, Response

Binding：Artifact, SOAP

Protocol：Authentication Request, Response,

Artifact Resolve

Client SP(RP) IdP

HTTP Redirect, POST

User Authentication

HTTP POST

Artifact

Artifact

Artifact Resolve( + SOAP)

Authenticati

onRequest

Response

Assertion

Authenticati

onRequest

Assertion

サービス提供

Response

Artifact

ArtifactResolve

Artifact

ArtifactResponse

Assertion

User Authentication

サービス利用開始サービス利用開始

サービス提供


SAMLプロトコル

15

# 名称概要

1 Authentication

Request

IdPに対してSPがユーザの認証を要求するために利用するSAMLメッセージを規定するプロトコル。

2 Response SPからの要求に対してアサーションを返却するために利用するSAMLメッセージを規定するプロトコル。

3 Artifact Resolve SPがArtifact（SAMLメッセージへの参照）をIdPに対して送信し、参照先であるSAMLメッセージ本体を取得するためのSAMLメッセージを規定するプロトコル。

ブラウザを介したSAMLメッセージの送受信経路の回線帯域が小さい場合や、ブラウザ送受信できるデータサイズの最大値がSAMLメッセージの送受信に必要な要件を満たさない場合に利用される。

4 Single Logout 同一のIdPから取得した認証アサーションによってログインが完了している全てのSPからログアウトするためのSAMLメッセージを規定するプロトコル。SOAPやHTTP Redirectバインディングと組み合わせて利用できる。

5 Assertion Query

and Request 認証済みユーザの認証アサーション、属性アサーション、認可決定アサーションを要求するためのSAMLメッセージを規定するプロトコル。

6 Manage NameID SPとIdPの間でユーザを特定するための紐付け用名前識別子（NameID）の洗い替え・削除を行うためのSAMLメッセージを規定するプロトコル。

7 NameID Mapping ユーザの名前識別子(NameID)のフォーマットを変換する、または別のSPで同じユーザを指す名前識別子に変換するために利用するSAMLメッセージを規定するプロトコル。


SAMLバインディング

16

# 名称概要

1 HTTP Redirect

(GET)Binding

一般的にブラウザリダイレクト(HTTPステータスコード302)を用いて、アクセスするサーバのURI

にSAMLメッセージを付与する(GETメソッドを利用する)方式。ブラウザ実装によっては、GETメソッドで扱えるURI長に制限がある。

2 HTTP POST

Binding

POSTメソッドを用いて、SAMLメッセージを送受信する方式。HTTP Redirect Bindingと比較して、多くの場合大きなサイズのSAMLメッセージを流通させることができる。

3 HTTP Artifact

Binding

HTTP Redirect/POST Bindingのようなブラウザを介した間接通信を行う経路が、ネットワーク帯

域的に制限されていたり、ブラウザ自体が取り扱えるデータ長に制限がある場合に、サイズの小さなArtifact(SAMLメッセージ本体への参照)を間接通信路で交換し、サイズの大きなSAMLアサーション本体はSPとIdPの直接通信で交換する方式。

4 SOAP Binding SAMLのメッセージをSOAPメッセージ上に載せる方式。

5 Reverse SOAP

Binding

サーバ（SPおよびIdP）とクライアント（ブラウザ）の関係を逆転させ、HTTP応答にSAML要求メッセージを含むSOAPメッセージを載せ、HTTP要求にSAML応答メッセージを含むSOAPメッセージを載せる方式。クライアントがSOAPおよびSAMLメッセージを処理できること（ECP:

Enhanced Client or Proxy）が前提となる。

6 SAML URI Binding URI形式のアクセスにより、アサーションを直接取得するための方式。


SAMLプロファイル

17

# 名称概要

1 Web Single Sign-

on & Federation

IdPとSPとの間で名前識別子(NameID)を連携、IdPからSPに対してSAML認証アサーションを受け渡すことで、同一のCircle of Trustに所属するSPに対してシングルサインオンを行うための手順を規定する。

2 Artifact Resolution IdPとSPとの間で受渡されたArtifactと引き換えに、SAMLメッセージ本体を取得する手順を規定する。

3 Single Logout 同一のIdPから取得した認証アサーションによってログインが完了している全てのSPからログアウトするための手順を規定する。

4 Identity Provider

Discovery

ユーザが現在利用中のIdPを、Cookieを介して、SPとIdPが発見する、および発見できるようにするための手順を規定する。

5 Manage NameID IdPとSPの間でユーザを特定するために共有されている名前識別子(NameID)を、変更・削除するための手順を規定する。

6 NameID Mapping SPが、あるユーザのことを指す名前識別子（NameID）を入手したり、フォーマットの異なる名前識別子に変換したり暗号化する手順を規定する。


SAMLの普及動向

Google AppsやSalesforce.comなどのSaaS提供事業者が、利用企業との間のID連携のベースとして採用

SaaS契約企業の社員が、社内SSO（シングル・サインオン）でユーザー認証を受け、社外のSaaSにログイン

その他、B2B（業務目的での企業間連携）や、高等教育機関でのフェデレーション・ネットワークのベースとして採用 cf. Global Trust Framework Survey - DG - Business Cases for Trusted Federations - Kantara

Initiative

http://kantarainitiative.org/confluence/display/bctf/Global+Trust+Framework+Survey

ただし、フェデレーション要件に応じてSAML仕様をどう使うか取り決める（プロファイリング）必要があるため、フェデレーション・ネットワーク間の相互運用性は低い

18

http://kantarainitiative.org/confluence/display/bctf/Global+Trust+Framework+Survey

OpenID

19


「OpenID 2.0」

ふたつのWebサイト間における、Webブラウザを用いたアイデンティティ情報（エンドユーザの認証結果と属性情報）の要求・提供を行うためのプロトコル

2007年12月に策定

仕様群

OpenID Authentication 2.0: 認証結果の要求・取得

拡張仕様 ▪ Attribute Exchange (AX) Extension 1.0: 属性情報の要求・取得

▪ Provider Authentication Policy Extension (PAPE) 1.0: 認証ポリシーの公告・要求・表明

▪ OpenID OAuth Extension (Draft): OpenID Authenticationの認証結果と同時に OAuth 1.0 トークンを要求・取得

▪ OpenID User Interface Extension 1.0 （Draft): ユーザー認証・同意ページのユーザー・インタフェースの指定

20


OpenID の概念と登場人物

ユーザがアイデンティティ (ID) 情報の提供サイトを選択（ただし実際にはホワイトリストによる運用が一般的） OpenID プロバイダ (OP): ID 情報 (認証結果や属性情報) を RP に提供するサイト

OpenID リライング・パーティ (RP): OP から提供された ID 情報を受け入れるサイト

21

RP (医療情報管理サービス) 「本人以外には決して公開しない」

RP (無料日記サービス)

「誰でも気軽にコメ

ントしてほしい」

RP(ホテル予約サービス)

「確かな属性情報がほしい」

OP(ポータルサイト)

誰でも即時アカウント取得可能

OP(航空券予約サービス) クレジットカード

番号等を管理

OP(高度認証サービス)

登録時に厳密な本人確認を行ない、多要素認証を実施

ID / パスワードでログイン

ID情報の提供

ID / 画像認証でログイン

ICカードの証明書でログイン

ID情報の提供

ID情報の提供

クレデンシャル情報（ID/PW等）の入力によるユーザの特定はOP側で行うため、RP側にクレデンシャル情報を流通させ

る必要がない

OP：ID情報の提供側 RP：ID情報の受入側


OP と RP 間のやりとりの仕組み

22

ユーザエージェント（ブラウザ）

RP OP

エンドユーザーの

ID/パスワード

OpenID入力 ①ディスカバリ

OpenID（URL）にアクセス

OP の通信先

（EndPoint URL）等を返却

②アソシエーション

共有秘密鍵の交換

③認証要求

リダイレクトによる OP への認証要求

（ユーザと OP 間の認証処理と ID 情報提供への同意）

④認証応答リダイレクトによる ID 情報返却

サービス提供

GET

https://www.google.com/accounts/o8/

ud

&openid.ns=http://specs.openid.net/a

uth/2.0

↑プロトコルバージョン

&openid.assoc_handle=AMlY****A9

↑②で交換した共有秘密鍵への参照キー

&openid.mode=checkid_setup

↑モード（認証要求） &・・・・

GET https://iknow.jp/open_ids

&openid.ns=http://specs.openid.net/a

uth/2.0

&openid.assoc_handle=AMlY****A9

&openid.mode=id_res

↑モード（認証応答） &openid.claimed_id=https://www.goo

gle.com/accounts/o8/id?id=AItO****aw

m

↑OP が認証した識別子（OpenID）&openid.sig=5aDmb****ExYmdwqaU

↑パラメータの共有秘密鍵による署名

要求リクエストのプロトコルバージョンを付与

秘密鍵への参照キーによる、メッセージの改ざん対策

OP で認証されたOpenID の返却

改ざん検知用のメッセージ署名


OpenID 2.0の普及動向

多数のユーザを抱えるWebサイトが、他社WebサイトにID情報を提供するための API（Application Programming

Interface）としてOpenIDを採用

インターネットサービス事業者（例： Yahoo!、Google、ミクシィ）

携帯通信事業者（例： NTTドコモ、KDDI、ソフトバンク）

ネット決済事業者（例：楽天（楽天あんしん支払いサービス）、PayPal）

米国において、民間のIdP (Identity Provider：たとえばポータル事業者や決済事業者など、市民に対してID を発行・運用する組織)と、連邦政府機関の市民向けWeb サイトとのID連携プロトコルの一つとして採用

23

OAuth

24


Web API: 自社以外のチャネルへ浸透するためのしくみ

コンテンツ/

機能

PC/携帯電話向け Webサイト

スマートフォン向け Webサイト/アプリ

エンドユーザー

サービス事業者

外部パートナー企業 /

開発者

Webサイト

アプリ

実店舗

PC、携帯端末以外のデバイス

25

サービス事業者のIDでログイン


外部向けAPI

（Web API）


Web API?

API (Application Programming Interface)

あるコンピューター・プログラムが自身のサービスを外部の

コンピューター・プログラムに提供する際の、サービスの機能や

アクセス方法の定義のこと

APIを利用することにより、異なるプログラム同士の連携が

容易となり、開発の手間を省くことができる

Web API

Webサービスが、外部のWebサイトやアプリケーションに対し、

インターネットを介して公開するAPI

26


Web APIの例

Yahoo! JAPAN

Google

楽天

ミクシィ

Facebook

Twitter

…

27


Webブラウザのトラフィック << Web APIのトラフィック

28

Source: “Open, Mobile, Social”, Cloud Identity Summit 2011 Proceedings

http://bit.ly/pBXcgM

Force.com の API / Web トラフィック比較

Source: Migrating Netflix from Datacenter Oracle to Global Cassandra

http://www.slideshare.net/adrianco/migrating-netflix-from-oracle-to-global-cassandra

Source: Developing for @twitterapi (Techcrunch Disrupt Hackathon)

http://www.slideshare.net/raffikrikorian/developing-for-twitterapi-techcrunch-disrupt-hackathon

21億リクエスト/月

4,000億リクエスト/月

20億リクエスト/月北米のインターネットトラフィックの20～30%


Web APIを外部に公開するサービスは急激に増加

29

2010年12月の段階で2,000超のWeb APIが存在

2012年9月には

7,144種類にまで増大

Source: Open API Ecosystem Overview: December 2010 <http://slidesha.re/g8irEO>

Source: ProgrammableWeb

http://www.programmableweb.com

Source: Open APIs and the Semantic Web 2011

http://www.slideshare.net/jmusser/j-musser-semtechjun2011


そして、Web APIのトレンドは民間企業だけではない

2012年5月、オバマ政権はデジタル政府戦略の一つとして、主要な連邦政府機関に対し、今後Web APIを公開するよう命令 “Digital Government: Building a 21st Century Platform to Better

Serve the American People”

http://www.whitehouse.gov/sites/default/files/omb/egov/digital-

government/digital-government-strategy.pdf

各機関は、12ヶ月以内に「Web API

化」を実行しなくてはならない

最低2つの主要システムのWeb API化

Web APIを利用する開発者向けに

“agency.gov/developer” ページの公開

30

Source“Digital Government: Building a 21st Century Platform to

Better Serve the American People”

http://www.whitehouse.gov/sites/default/files/omb/egov/digital-

government/digital-government-strategy.pdf

http://www.whitehouse.gov/sites/default/files/omb/egov/digital-government/digital-government-strategy.pdf















ただし、Web APIだけでは…

コンテンツ/

機能






開発者

Webサイト

アプリ

実店舗


31



外部向けAPI

（Web API）

パートナーID

でアクセス

パートナーID

でアクセス

パートナーID

でアクセス

パートナーサイトやアプリケーション単位でのAPIアクセスとなるため、その先にいるどのユーザーがサービスを利用しようとしているかわからない


Web APIによってチャネルを広げつつ、エンドユーザーとの接点を確保するためのしくみが「ID連携」

コンテンツ/

機能





外部向けAPI

（Web API）


開発者

Webサイト

アプリ

実店舗


32

サービス事業者のIDでの代理

アクセスを許可





サービス

事業者のIDで

代理アクセス

サービス

事業者のIDで

代理アクセス

サービス

事業者のIDで

代理アクセス



ID連携によってパートナーサイト/アプリケーションとサービス事業者のIDをひもづけ、どのエンドユーザーがWeb APIにアクセスしているかを把握する


利用イメージ

33

会員情報の登録

を登録お客さまの

1. パートナーサイトの

会員情報に、自分の

「ECサイトのID」を登録

「ECサイトID」

パートナーサイト

会員情報の登録

ECサイトID:

[email protected]

4. 登録完了


2. ECサイトにログイン

ログインキャンセル

ID:

パスワード:

[email protected]

********

ECサイト

あなたへのおすすめ商品があります

Powered by 「ECサイト」 •…

•…

•…

パートナーサイトから出ることなく、ECサイトの

商品情報とショッピングカートにアクセス

ECサイト内での行動履歴を元に

パートナー提携ショップでの体験を最適化パートナーが開発した個別デバイス向けアプリケーションに情報を提供

ECサイトに登録してあるID情報を用いたパーソナライズや、ECサイトのカート機能をパートナーに提供

カートに入れる




3. ECサイト上のサービスへのアクセスを許可

パートナーが提供するサービス経由でECサイトの「ほしい物リスト」「クチコミ投稿」「カート機能」を

利用できるようにします

OK キャンセル

ECサイト


OAuth の登場

「トークンによる API アクセス制御」のフレームワークトークン: ユーザーに成り代わってアクセスすることを示す符号

広く使われているのは「API プロバイダーがエンドユーザを直接認証するフロー」 APIクライアントが介在しないため、そこからの「ID/パスワードの流出」がなくなる ▪ API クライアントが管理するのはID/パスワードではなくトークン

API 提供側はユーザー単位でのアクセス管理が可能 ▪ トークンはエンドユーザとひもづいている

まもなくOAuth 2.0がRFC標準となる見込み現行のOAuth 1.0はobsoleteに

34


API クライアント

API プロバイダ


ID/パスワード

APIプロバイダのID/パスワードを入力

トークンをリクエストに付加し、 APIを呼出／応答

サービスを提供

サービスにアクセス

APIプロバイダーに「特定のサービスにアクセスするための

トークン」を要求

「APIプロバイダーのID/パスワードを入力してください」

トークンを APIクライアントに返却

アクセス範囲を限定したトークンを要求することができる

ID/パスワードが APIクライアントに漏えいしない


OAuthの普及動向

APIアクセス認可の事実上の標準フレームワークとして広く普及

ソーシャル・ネットワーク: Facebook, Twitter, mixi, Google+,

GREE, Ameba, Windows Live, LinkedIn, …

エンタープライズ: Google Apps, Microsoft Office 365,

Salesforce.com, …

EC/決済/ポイント: 楽天、Yahoo!、PayPal、…

銀行/証券: AXA Banque, E*TRADE, …

その他多数

35


OpenIDとOAuthの組み合わせ

OpenID は意外と実装が難しい鍵交換や署名の付与・検証を自力で実装することは比較的難易度が高い

これらの処理を行うライブラリは多数あるが、環境によっては組み込みが難しい

OAuth は単純には認証に使えないトークンはAPIアクセスのためであり、認証結果としては利用できない

API の権限設定が粗いと、トークンが必要以上の権限を持つ

悪意のあるユーザ、サイトによって、権限の乱用や他人に成り済ましたトークン利用が可能となる

OpenID と OAuth を組み合わせる仕様 (OpenID/OAuth Hybrid) も考案されているが… 仕様がドラフトのままアップデートされていない ▪ OAuth は1.0プロトコルベース

両プロトコルをそれぞれ実装する手間がかかる

36

OpenID Connect

37


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

OpenIDの次期バージョン

OAuth 2.0 仕様をベースに拡張

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

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

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

署名と暗号化をサポート

仕様のモジュラー化

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

38


OpenID Connectの系図

39

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

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






OpenID 2.0

40

OpenIDプロバイダ（OP） RPのリクエストに基づきユーザー認証を行いその認証結果と属性情報を提供

OpenIDリライング・パーティ（RP） OPに認証結果や属性情報をリクエストし

その情報をもとにユーザーにサービスを提供

ユーザー

RPへのアクセスを試みる過程においてOPからRPへの認証結果と属性情報の提供を許可

PCのWebブラウザ

1. 「OPのIDでログイン」

2. OPの場所を特定し、リクエスト/ レスポンスに用いる署名鍵を交換

4. ユーザー認証の実施と認証結果と属性情報の提供可否の確認

6. アクセスを許可しサービスを提供

3. 認証リクエスト（ブラウザをリダイレクト）

5. 認証レスポンス（ブラウザをリダイレクト）


OpenIDプロバイダ（OP） RPのリクエストに基づきユーザー認証を行いその認証結果と属性情報を提供

Web API （ID情報、ｌセッション管理、ソーシャル、決済、アクティビティ、…）

OpenID 2.0の課題 (≒ OpenID Connectの注力分野)

41

OpenIDリライング・パーティ（RP） OPに認証結果や属性情報をリクエストし

その情報をもとにユーザーにサービスを提供

ユーザー

RPへのアクセスを試みる過程においてOPからRPへの認証結果と属性情報の提供を許可

PCのWebブラウザ

1. 「OPのIDでログイン」

2. OPの場所を特定し、リクエスト/ レスポンスに用いる署名鍵を交換

3. 認証リクエスト（ブラウザをリダイレクト）

4. ユーザー認証の実施と認証結果と属性情報の提供可否の確認

5. 認証レスポンス（ブラウザをリダイレクト）

6. アクセスを許可しサービスを提供

「携帯電話のWebブラウザや、 Webブラウザ以外のユーザー・エージェント

（ネイティブ・アプリケーションやJavaScriptクライアントなど）

にも対応したい」

「認証リクエスト/ レスポンスに対して、公開鍵を用いて

暗号化・署名したい」

「OP/RP間の設定をもっとかんたんに、もしくは省略したい」

「OPの提供する他のAPIとかんたんに

組み合わせたい」


OpenID Connectの特徴

42


API クライアント

API プロバイダー


ID/パスワード

アクセストークンによる API呼出／応答

サービスを提供

サービスにアクセス

認証・同意

認可要求

APIプロバイダーに「特定のサービスにアクセスするためのトークン」を要求

認可応答

認可コードをAPIクライアントに返却

アクセストークン要求・応答

UserInfo要求・応答

OAuth の認証では不十分だった、認証コンテキスト（いつ、誰が、誰を認証したのか等）を「ID トークン」として提供

属性提供を行う UserInfo API が規定され、API アクセスの標準ルールが策定

（認可コードとアクセストークンを引換え/IDトークンの返却）

OAuth2.0 ベースによる、トークンを利用した全体的なフロー・OAuth2.0 に対応済みであれば、一部の拡張で OpenID Connect に対応可能


OpenID Connectのフロー（概要）

43

認可

サーバー

ユーザー

情報

（クレーム）

3. ユーザー

認証・認可

クライアント

5. ユーザー属性提供要求

クレーム

プロバイダ

クレーム

ソース

UserInfo

エンドポイント


認可

エンドポイント

1. サービスにアクセス

OpenID

プロバイダ

3

1

2

4

2. トークン

取得要求

（ブラウザの

リダイレクト） 4. アクセス・トークンとID

トークンを返却

（ブラウザの

リダイレクト）

5

6

6 . ユーザー属性提供

7.（オプション）:ユーザー属性提供要求

7

8

8. （オプション）: ユーザー属性提供

9 . サービス提供

9


OpenID Connect Protocol Suite

「公式マップ」 http://openid.net/connect

…が、以下のほうが実態に近い気がする

44

Bindings •Basic Client Profile

•Implicit Client Profile

•Standard

•Other Vendor Proprietary / Community Specific Bindings

Endpoints and

associated message

formats •Messages

Optional Functionality •Discovery

•Dynamic Client Registration

•Session Management

•Other Vendor Proprietary /

Community Specific Functionality

Underpinnings


OpenID Connect のユースケース

1. シンプルな認証結果と属性情報の取得

OpenID Connectフローの処理の結果、クライアントは認可サーバーからid_tokenとアクセス・トークンを得る

認証結果: id_tokenから抽出 id_token

▪ JWT(JSON Web Token)形式 ▪ JWS (JSON Web Signature)により署名

▪ 発行者（iss）、エンドユーザーの識別子（user_id）、トークンのオーディエンス（aud)、有効期間（exp)、発行時間（iat）などが含まれている

検証方法 ▪ 取得したクライアント自身がid_tokenを検証

属性情報: アクセス・トークンを用いて取得クライアントはフロー開始時（認可リクエスト）のscopeに、取得したい「クレーム」を指定

▪ 指定可能なクレームはprofile (一般的なユーザー属性(address, emailを除く)), address (住所), email (メールアドレス) 、phoneの4種類（複数同時に指定可能）

取得したアクセス・トークンを用いてUserInfoエンドポイントにアクセスし、属性を取得 ▪ JSON形式

45



2. 仕様に規定されている以外の属性の取得

認可リクエストのscopeに独自の「クレーム」を指定

さらに認可リクエストに「リクエスト・オブジェクト」を付加し、要求する属性を指定

リクエスト・オブジェクト

認可サーバーへのリクエスト・パラメータをJWT化したもの

認可リクエストへの付加方法 ▪ requestパラメータの値としてリクエスト・オブジェクトを指定

▪ request_uriパラメータの値として、リクエスト・オブジェクトの場所を指定

例: もし「edupersonクレーム」を作る場合

scopeにedupersonを指定

リクエスト・オブジェクトとして以下の内容を指定

UserInfoにアクセスすることにより、以下の属性を取得

46

{

"user_id": null,

"urn:mace:dir:attribute-def:cn" : {"optional": true},

"urn:mace:dir:attribute-def:sn" : {"optional": true},

"urn:mace:dir:attribute-def:givenName" : {"optional": true},

"urn:mace:dir:attribute-def:mail" : null

}

{

"user_id": "248289761001",

"urn:mace:dir:attribute-def:cn" : "John Bradley",

"urn:mace:dir:attribute-def:sn" : "Bradley",

"urn:mace:dir:attribute-def:givenName" : "John",

"urn:mace:dir:attribute-def:mail" "[email protected]"

}

mailto:[email protected]



3. ユーザー認証の保証レベルの指定

認可リクエストに付加する「リクエスト・オブジェクト」に、要求する保証レベルを指定

ユーザー認証後得られたid_tokenに、保証レベルが含まれる

例

リクエスト・オブジェクトとして以下の内容を指定

ユーザー認証後取得したid_tokenに以下の内容が

含まれる

47

"id_token":

{

"claims":

{

"auth_time": null,

“acr": { "values":["2"] }

},

"max_age": 86400,

}

“acr": {"values":["3","2"]}



4. UserInfoエンドポイントの外部にあるクレームの取得

UserInfoから提供する外部のクレームとして、「集約（aggregated）クレーム」と「分散（distributed）クレーム」を規定

集約（aggregated）クレーム

UserInfoエンドポイントから提供されるクレームの中に、外部クレームの「実体」が含まれる ▪ その「実体」はJWT形式に変換して含まれることにより、他のクレームと区別される

分散（distributed）クレーム

UserInfoエンドポイントから提供されるクレームの中に、外部クレームを取得するための情報が含まれる ▪ 場合によっては、取得するための情報としてアクセス・トークンが指定されている

48



5. クライアントによるOpenIDプロバイダのディスカバリ

OpenID Connect Discovery

エンドユーザーが指定した識別子をもとに、OpenIDリライング・パーティがOpenIDプロバイダを発見する仕組みを定義

▪ OpenID 2.0にて実現されていた機能と同様

識別子は以下のどちらかであるべきである (SHOULD)

▪ メールアドレス or URL

識別子を元にOpenIDリライング・パーティは、SWD (Simple Web

Discovery) により、OpenIDプロバイダを発見する

49

GET /.well-known/simple-web-discovery?principal=joe%40example.com&service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer

HTTP/1.1 Host: example.com

HTTP/1.1 200 OK

Content-Type: application/json

{

"locations":["https://server.example.com"]

}



6. クライアント情報の動的な登録

OpenID Connect Dynamic Client Registration

OpenIDプロバイダとOpenIDリライング・パーティとが、動的に信頼関係を確立する仕組みを定義

▪ OpenID 2.0にて実現されていた機能と同様

OpenIDリライング・パーティがOpenIDプロバイダの「クライアント登録エンドポイント」に、自身を登録するようリクエスト

▪ 成功した場合、レスポンスとしてclient_id/client_secretが返却される

50

POST /connect/register HTTP/1.1

Accept: application/x-www-form-urlencoded

Host: server.example.com

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X

type=client_associate

&redirect_uris=https://client.example.org/callback %20https://client.examp

le.org/callback2 &logo_url=https://client.example.org/logo.png

&user_id_type=pairwise &sector_identifier_url=

https://othercompany.com/file_of_redirect_uris_for_our_sites.js

&token_endpoint_auth_type=client_secret_basic

&jwk_url=https://client.example.org/my_rsa_public_key.jwk

&userinfo_encrypted_response_alg=RSA1_5

&userinfo_encrypted_response_enc=A128CBC

&userinfo_encrypted_response_int=HS256

HTTP/1.1 200 OK

Content-Type: application/json

Cache-Control: no-store

{

"client_id":"s6BhdRkqt3",

"client_secret":

"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e58858

05d",

"expires_at":2893276800

}



7. セッション管理

OpenID Connect Session Management

OpenIDプロバイダ（認可サーバー）におけるユーザーのログイン/ログアウトの状況を、OpenIDリライング・パーティ（サードパーティ）が継続的にモニターする仕組みを定義

OP/RPの通信にiframeを利用

51


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

現在Implementer’s Draftが公開中

今後最終仕様に

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

（予定含む）

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

Vordel、…

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

52


まとめ

IDフェデレーションを活用したサービスは、コンシューマー/エンタープライズ/公共/文教を問わず、多方面に普及しつつある

これまでID連携はSSO/属性流通のためという側面が強かったが、近年、APIアクセス認可の基盤としての活用が増えている

SAML、OpenID、OAuthを統一する仕様としてOpenID Connectが注目されている

53

http://flic.kr/p/5iJp6M

ID (アイデンティティ) フェデレーションに関する技術動向と今後の方向性

Documents

Transcript of ID (アイデンティティ) フェデレーションに関する技術動向と今後の方向性