SAMLからOpenID Connectへ ~ フェデレーション技術の広がり

工藤達雄

株式会社野村総合研究所

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

SAMLからOpenID Connectへフェデレーション技術の広がり




Copyright 2013 OpenID Foundation Japan - All Rights Reserved.

SAML「から」OpenID Connectへ…?

そもそも、「従業員向けSaaS/ASP」において

SAMLは普及しているのだろうか?

SAML SP（サービス・プロバイダ）機能を備え

たSaaS/ASPは増えているが、大多数があまり利

用されていないのはなぜだろうか?

1


実は普及しているのは「特定SaaS/ASPのSAML」

2

年仕様製品・サービス（主要トピック）

2002 SAML 1.0 承認

ID-FF 1.0 公開

•SSOベンダがSAML対応を表明

2003 SAML 1.1 承認

ID-FF 1.1, 1.2 公開

•SAML対応SSO製品が複数登場（当初はオプション機能だったが、後に製品標準装備として提供されることが一般的に）

2004 •SAML対応Appサーバ、グループウェアなどが複数登場

2005 SAML 2.0 承認 •英語圏において、複数のASP（WebExなど）がSAML SP（サービス・プロバイダ）機能を実装

2006 •Google AppsがSAML 2.0 SP機能を実装

2007 •LDAPサーバやActive Directoryと連携し、従業員IDを用いてGoogle Appsにログインするためのゲートウェイ（Google Apps専用IdP）製品が複数登場

2008 •Salesforce.comがSAML 1.1 SP機能を実装

•複数のSAML対応SSO製品が、Google AppsやSalesforce.comと連携するためのIdP設定をかんたんに行える機能（ウィザードなど）を実装

•ゲートウェイ（Google Apps専用IdP）機能を提供するASPが複数登場

2009 •英語圏において、従業員IDで複数のSaaS/ASPにログインするためのゲートウェイ機能を提供するSaaS（IDaaS）が複数登場

…

SAMLの歴史（従業員向けSaaS/ASPの文脈で）


ID管理システム

プロビ

ジョニング

システム

SSO /

アクセス

管理

システム

「特定SaaS/ASPのSAML」であれば

利用企業側は連携環境を構築しやすい

3

GApps独自の

ユーザープロビジョニング

API

エンドユーザー

向けWeb

アプリケーション社内の

ユーザー追加・変更・削除

GAppsの

利用

管理者


利用企業A社 Google Apps

SFDC独自のユーザー・プロビジョニング

API


向けWeb

アプリケーション

Salesforce.com

SFDCの

利用

SFDC独自APIに

従い、SFDCの


GAppsのAPIに従い、

GAppsのユーザー

追加・変更・削除

GApps

独自の

方法で認証

結果・属性

情報要求

社内IDで

ログイン SFDC独自の方法でID管理結果・属性情報要求

人事情報

システム

社内の


GApps独自

接続機能

SFDC独自API

接続機能

SFDC独自方式

準拠API

GApps独自方式準拠API


SAML対応SaaS/ASPの「勝ち組」と「負け組」

勝ち組

• SSO製品が「設定ウィザード」を提供してくれる

• フル装備のSSOソリューションから単機能なゲートウェイまで、あるいはオンプレミスからサービス利用まで、幅広い選択肢がある

• （準勝ち組）SSO製品に広くサポートされているとはいえないものの、ニーズが高く、SAML IdP設定ノウハウが蓄積されつつある。また英語圏ではIDaaSが標準でサポートしている

負け組

• SSO製品がサポートしていないため、利用企業側が自前でSAML IdP設定をしなくてはならない

• 利用企業側でのIdP設定の難易度が高いため、費用がかかり、SAML連携が普及しない

• SAML連携が普及しないため、SSO製品による標準サポートが行われない

• そして負のスパイラルへ…

4


これから「従業員IDでログイン」機能を提供するSaaS/ASPが「負け組」にならないためには

いまからGoogle AppsやSalesforce.comの真似をしても無意味

利用企業ががんばってSAML IdPになったのは、彼らのサービスが魅力的で

あったから

多数のベンダがさまざまな「専用SAML IdP」を提供するようになったの

は、ユーザーベースが巨大だったから

利用企業側のコストとリスクを最小化しないといけない

独自SAMLプロフゔイルや独自仕様に対応するのは利用企業の負担となる

複数のASP/SaaSに対して連携できることが望ましい

5

SAML SPではなくOpenID Connect RP*になる *Relying Party （リライング・パーティ）


ID管理システム

プロビ

ジョニング

システム

SSO /

アクセス

管理

システム

利用企業とSaaS/ASPとの間のID連携仕様を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)

6


APIアクセス認可への拡張

7

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


SAMLだけではAPIアクセス認可まで対応できない

仕様 SAML 2.0 OAuth 1.0 OAuth 2.0 OpenID 2.0 OpenID Connect

ID受け入れ側（リライング・パーティ）の実装・運用の容易さ

×（XMLやSOAP、PKIなどのスキルが必要であり、通常はSAML処理ライブラリやミドルウェアの導入が必須）

△（署名処理が必要であり、通常はOAuth処理ライブラリなどの導入が必須）

○（ライブラリ等の導入が不要） △（鍵交換や署名処理が必要であり、通常はOpenID処理ライブラリなどの導入が必須）

○（ライブラリ等の導入が不要）

Webブラウザ以外（デスクトップアプリ、スマートフォンアプリなど）への対応

△（仕様上はWebブラウザ以外にも対応可能だが、実際に広く利用されているのはWeb

SSOのみ）

○ ○ ×（Webブラウザのリダイレクト機能に依存したプロトコルであり、Webブラウザ以外への対応は不可能）

○

認証結果の連携 ○ ×（仕様のスコープ外であり、OAuth

採用事業者の独自拡張が乱立） ×（仕様のスコープ外であり、OAuth

採用事業者の独自拡張が乱立） ○ ○

属性情報の連携 ○ ×（仕様のスコープ外であり、OAuth

採用事業者の独自拡張が乱立） ×（仕様のスコープ外であり、OAuth

採用事業者の独自拡張が乱立） ○ ○

APIアクセス認可（アクセストークン配布）への対応

×（仕様のスコープ外） ○ ○ △（OAuth 1.0とのハイブリッドにより対応）

○

複数のアクセストークンへの対応

×（仕様のスコープ外）

×（仕様のスコープ外） ×（仕様のスコープ外） ×（仕様のスコープ外） ○

認証結果・属性情報への署名や暗号化

○ ×（そもそも、認証結果・属性情報の連携は仕様のスコープ外）

×（そもそも、認証結果・属性情報の連携は仕様のスコープ外）

△（共有鍵による署名のみ可能。暗号化は仕様のスコープ外）

○

サイト間のセッション管理

○ ×（仕様のスコープ外）

×（仕様のスコープ外） ×（仕様のスコープ外） ○

機能の不十分なWebブラウザ（携帯電話等）への対応

× ○ ○ × ○

備考さまざまなユースケースに適用可能な仕様であるが、それゆえに複雑であり、結果的には企業内ID管理システムと企業向けSaaSとの間でのSSOに利用されるにとどまっている。

Web APIのアクセス認証プロトコルとして広く普及。ただしメッセージへの署名処理など、実装が難しい点もある。またID連携に関しては仕様のスコープ外のため、独自仕様が乱立している。

OAuth 1.0をベースに、より容易に実装できるように仕様を簡略化。OAuth 1.0を採用していた事業者は現在徐々にOAuth 2.0に移行しつつある。しかしOAuth 1.0同様、ID連携に関してはスコープ外。

Webサイト間の認証結果・属性情報の交換に特化したプロトコルであり、従前の仕様（SAML 2.0)に比較して単純なプロトコルであるが、鍵交換や署名処理など、まだ実装が容易ではない点が残る。

OAuth 2.0をベースに、ID連携のためのプロトコルを定義。OAuth 2.0の実装のしやすさを活かしつつ、ID連携に十分な機能を定義している。

Google、PayPal、日本経済新聞社、Yahoo! JAPANなどがすでに自社サービスに適用。

アイデンティティ関連仕様の比較

8


「アイデンティティ・フェデレーション」から「サービス・フェデレーション」へ

9

オーソリテイティブ・ソース（人事

システムなど）

プロビジョニング・システム

アイデンティティ・リポジトリ / SSO /

トークン管理システム

SaaS

プロバイダ

SaaS

プロバイダ

Web

サービス

Web

サービスユーザー・エージェント

（Webブラウザ）

ユーザー・エージェント

（モバイルApp）


（外部サービス）


（デスクトップApp）


（Webサービス）

企業

API

API

API

API

Documents

SAMLからOpenID Connectへ ~ フェデレーション技術の広がり