Open Source Solution Technology

hbstudy#22

クラウド時代のシングルサインオン
オープンソース・ソリューション・テクノロジ株式会社
野村 健太郎2011/4/16
Copyright © 2011 Open Source Solution Technology

- 1 -

目次
 自己紹介 シングルサインオンとは？ なぜ今シングルサインオン？
 OpenAMの紹介
 シングルサインオンの方式
 SAMLによるシングルサインオン
 ID管理との組み合わせで導入効果倍増！

※プロトコル（SAML）の話が大半なので、眠くなるかも…。
適宜デモをはさんでいきます。
Copyright © 2011 Open Source Solution Technology

- 2 -

自己紹介
 野村 健太郎

http://d.hatena.ne.jp/nomtech/– @nomnux– あまり更新してない…
–

 オープンソース・ソリューション・テクノロジ（株）に勤務

http://www.osstech.co.jp/– オープンソースや“認証”が得意な人が集まってま– OpenLDAP、OpenAM（SSO）、Samba–

主に SSO を担当 Software Design 2010年9月号に統合認証・シングルサインオンの記事を執筆しました。

Copyright © 2011 Open Source Solution Technology- 3 -最初に教えてくださいシングルサインオンシステムを日常的に何かしら使っているシングルサインオンシステムを開発・構築している

OpenAM（OpenSSO）を使ったことがある

Copyright © 2011 Open Source Solution Technology- 4 -シングルサインオンとは？

Copyright © 2011 Open Source Solution Technology- 5 -システムには必ず必要な「認証」

企業・組織内ActiveDirectory

クラウド
Google Apps
Salesforce

ファイルサーバ
ファイル
LDAP
サーバー

メールサーバー
Client/ServerWindowsログオン/
LDAP 認証

ログイン

Webアプリ

ログイン

ログイン

ユーザー
Copyright © 2011 Open Source Solution Technology- 6 -シングルサインオンとは一度のログイン操作さえ完了すれば、複数のWebアプリケーションに認証操作することなくアクセスすることが可能になる。（以後、SSO と略すことも）ActiveDirectory

Google Apps
Salesforce

ファイルサーバ

ファイル
サーバー

LDAP

メールサーバー/クラサバ

クラウド

Webアプリ

SSO
Windowsログオン/
LDAP 認証

ログイン

ログイン

ユーザー
Copyright © 2011 Open Source Solution Technology

今日はこの部分のお話- 7 -なぜ今シングルサインオン？

Copyright © 2011 Open Source Solution Technology- 8 -SSO（ID管理）の需要推移
さらなる需要が見込まれる

需要

J-SOX法対応（内部統制）

2008年

クラウドの普及

2009年

2010年

Copyright © 2011 Open Source Solution Technology

2011年

時期
- 9 -

今後の需要 クラウド（外部のWebサービスの業務利用）が普及したことで、ID管理・シングルサインオンの需要が急上昇

 よくある問い合わせ–

社内にある多数ありWebアプリ（オンプレミス）へのアクセスをシングルサインオンで管理し、利便性を向上させたい–

社内のWebアプリと外部のWebサービス（GoogleApps、Salesforceなど）をシングルサインオン連携したい（クラウドサービス利用者）–

クラウド基盤の構成コンポーネントの一つとして、シングルサインオンサービスを提供したい（クラウドサービス提供者）

Copyright © 2011 Open Source Solution Technology- 10 -

OpenAM （旧OpenSSO）の紹介

Copyright © 2011 Open Source Solution Technology- 11 -

OpenAMとは
 Webアプリケーションにおけるシングルサインオンを実シングルサインオン現するためのプラットフォームとなるソフトウェア

 SAML 、 OpenID 、 OAuth 、 ID-WSFなどの認証・認
ID-WSF可に関連した複数のプロトコルをサポート

 機能豊富で管理インタフェースも充実 （悪く言えば複雑…）

Copyright © 2011 Open Source Solution Technology- 12 -

OpenAMの歴史 - その1

AOLによる買収

AOLからの分離

開発
主体

Netscape

iPlanet

製品名dsame

Identity Server

認証連携
機能の強化

オープンソース化！

Sun Microsystems

Access Manager

Copyright © 2011 Open Source Solution Technology

OpenSSO- 13 -

OpenAMの歴史 - その2
Oracleによる買収

OpenSSO は非戦略的な製品という位置づけ

Sun

OracleOpenSSO

Oracle OpenSSO

ForgeRock社
Oracleから分離

OpenAM
新プロジェクトの開始 !

Copyright © 2011 Open Source Solution Technology- 14 -

シングルサインオンの方式※OpenAM を前提とした説明ですが、他の SSO ソフトウェア・SSO 製品でもだいたい同じような感じのはずです

Copyright © 2011 Open Source Solution Technology- 15 -

シングルサインオンの方式（1）
SAML
Identity Provider (IdP)
・認証基盤
・ID管理

Service Provider (SP)（１）ログインアサーション（認証情報）

ユーザー（２）サービスへアクセス（ログイン操作なし）

Web
SAML Application
WebアプリがSAMLに対応している必要がある※この図は、HTTP Redirect Binding/HTTP POST Binding の場合の例です。
Copyright © 2011 Open Source Solution Technology- 16 -

シングルサインオンの方式（2）エージェント方式
認証サーバ（3）Cookieの正当性を確認（１）ログイン
CookieAgent

Webサーバー
ユーザ
情報

ユーザー （2）Webアプリへアクセス

Web
Application

リバースプロキシ方式
リバースプロキシ
・HTTPヘッダー
・ID/PWを代理POST

ユーザー（1）ログイン

Web
Application（3）Webアプリへアクセス（2）ユーザー認証

認証サーバ
Copyright © 2011 Open Source Solution Technology- 17 -

シングルサインオン方式の比較
方式

SAML

エージェント方式

リバース
プロキシ方式

Webアプリケー
ションの改修長所・短所

SAMLに対応していれば不要■標準的な仕様に準拠したSSOシステムを構築可能。他製品・サービスとの互換性が高い■WebアプリケーションがSAMLに対応している必
要がある

必要

■Webアプリケーションへの全ての通信をエージェントがフックする。細かなアクセス制御が可能■Webサーバー/APサーバーに対応したエージェ
ントが必要必要/不要■Webアプリケーションへのアクセスは必ずリバースプロキシを経由する。細かなアクセス制御が可能■ユーザー情報をHTTPヘッダーで渡す場合は改修が必要な場合あり■ID/PWを代理でHTTP POSTする場合は改修不要■リバースプロキシがボトルネックになる可能性もある※OpenAM を前提とした比較内容です
Copyright © 2011 Open Source Solution Technology- 18 -

シングルサイオン方式の採用基準
WebアプリケーションがSAMLに対応しているかNo
Webアプリケーションの改修が可能か

Yes

No

SAMLを採用
リバースプロキシ方式(ID/PWの代理POST)を採用

Yes
Yes
WebアプリケーションをSAMLにSAMLを実装対応させることができるかNo
エージェントがYes
Webサーバ/APサーバ
エージェント方式を採用に対応しているかNo

リバースプロキシ方式(ユーザー情報のヘッダー渡し)を採用

Copyright © 2011 Open Source Solution Technology- 19 -

設計上のポイント
ドメインやホスト名は充分吟味して決定する––

Webアプリの SSO においては、ドメインやホスト名は非常に重要（Cookie、SSLなどに影響）
一度 SSO 環境を構築すると変更するのが大変

Cookie ドメインの範囲は可能な限り限定する


–––––

SSOの方式によっては、Cookieを複数Webアプリ間で共有することもある
Cookie ドメインの範囲が広すぎると、やたらブラウザから Cookie が送出されて気持ち悪い…
 .example.com とか、.example.co.jp とかかといって、ホスト Cookie ではSSO環境の構築が困難
理想は、シングルサインオン対象のWebアプリ間でのみ有効なドメインとするのがよいかも .sso.example.com、.sso.example.co.jp など
SAML に関してはこの限りではない（異なるドメイン間におけるSSOを想定している）
Copyright © 2011 Open Source Solution Technology- 20 -

SAMLによるシングルサインオン- 概要 -

Copyright © 2011 Open Source Solution Technology- 21 -

SAMLとは SAMLとはSecure Assertion Markup Lauguage– 認証、認可、ユーザ属性情報などをXMLで送受信するための仕様– 標準的な仕様にしたがって複数のWebサイト間におけるシングルサインオンを実現することが可能– Google Apps(SAML SP)、Salesforce(SAML SP/SAMLIdP)、学術認証フェデレーションなどが採用– 公式サイト：http://saml.xml.org/– 仕様原文：http://www.oasisopen.org/specs/index.php#saml–Copyright © 2011 Open Source Solution Technology- 22 -

SAMLとは…
抽象的でよくわからん…
独断と偏見により要約すると、Webアプリにおける” 認証処理 ”を、外部のWebアプリで代わりにやってもらうための仕組みとひとまず覚えてくださいm(_ _)m

Copyright © 2011 Open Source Solution Technology- 23 -

何が違う？「認証」と「認可」

認証（Authentication）– 本人性を確認する– ID/パスワード認証、生体認証、ワンタイムパスワード認証認可（Authorization）– あるリソースへアクセスするための権限を与える（認証後のアクセス制御）※SAMLでは認可に関連した仕様も定められている。
今日は認証関連のお話
Copyright © 2011 Open Source Solution Technology- 24 -

SAMLキーワード


Identity Provider （IdP）：認証・認可の情報を提供する役割を担う。IdPで認証されたユーザーは SP のサービスにアクセスできるようになる。

Service Provider （SP）：シングルサインオン対象の Web アプリケーションなどを意味する。IdP が発行した認証・認可の情報に応じてクライアントにサービスを提供する。

アサーション：・IdPが発行する認証・認可の情報。

トラストサークル（Circle Of Trust）：IdP と SP の間で結ばれた信頼関係を意味する。シングルサインオンを実現するためには、IdP と SP との間で事前に信頼関係を結んでおく必要がある。

アカウント連携：IdP と SP の間でユーザーアカウントを紐付けることを意味する。IdP と SP は信頼関係を結んだ後、アカウント連携を行う必要がある。

Federation：「連携」の意味。SAML、OpenIDなどの認証・認可に関わるプロトコルやその仕組みの総称として使われることがある※同じ言葉でも、他のプロトコルでは意味が違うことがあるので注意
Copyright © 2011 Open Source Solution Technology- 25 -

SAMLによるシングルサインオン
Identity Provider (IdP)
・認証基盤
・ID管理
Service Provider (SP)（１）ログインアサーション（認証情報）

ユーザー（２）サービスへアクセス（ログイン操作なし）

Web
SAML Application
WebアプリがSAMLに対応している必要がある

基本的に、セッションはユーザーとIdP間、ユーザーとSP間それぞれで管理※この図は、HTTP Redirect Binding/HTTP POST Binding の場合の例です。
Copyright © 2011 Open Source Solution Technology- 26 -

どこで SAML を使うか？
通常のWebアプリのログイン処理
ユーザーがアクセス

SAMLの場合のWebアプリのログイン処理
ユーザーがアクセスセッション有り

セッション確認セッション無し

認証処理（本人性の確認）セッション有りセッション確認セッション無し

SAMLによる認証

セッション生成セッション生成サービス提供サービス提供※Cookie を利用したセッション管理を行なう Web アプリの場合の例
Copyright © 2011 Open Source Solution Technology- 27 -

WebアプリのSAML対応(SAML SP化)

自力でゼロから実装

Yes

神Yes

認証処理部分の改修必要。
フレームワークの場合は改修が大変かも。

マンドクセ…

各プログラミング言語のSAMLサイブラリを活用
マンドクセ…
SAMLを話すリバースプロキシ/アプライアンス的なものを導入

Yes

既存アプリの改修不要。
お値段は安くはないでしょう。

Copyright © 2011 Open Source Solution Technology- 28 -

参考 - その他の認証・認可のプロトコル

認証（Authentication）：本人性を確認する
認可（Authorization）：あるリソースへアクセスするための権限を与える

プロトコル

SAML

役割
認証
認可

OpenID

OAuth

特徴■B to B での採用が多い■Google Apps、Salesforce、学術認証フェデレーション(Shibboleth)■属性情報の提供方法なども定義されている■実際のWebサービスなどでは、ほとんどが認証用途で使われている

認証■B to C での採用が多い■Google、Yahoo!、mixi、はてな、livedoor、ATND■属性情報の提供方法なども定義されている

認可■Twitter、Facebook、Google■Webアプリ間でユーザー情報を共有する際に、ユーザー自身が、情報が共有されることを”認可”する■WebAPI(REST)へのアクセス制御などに利用

Copyright © 2011 Open Source Solution Technology- 29 -

デモ

実際にSAMLでシングルサインオン
してみる
インターネット

LAN（ノートPC内に環境を構築）

SAML IdP

SAML SPOpenAM

Google Apps
Salesforce

ログイン
アサーションユーザー
Copyright © 2011 Open Source Solution Technology- 30 -

SAMLによるシングルサインオン- シングルサインオン環境の構築 -Copyright © 2011 Open Source Solution Technology- 31 -

SAMLによるシングルサインオン環境の構築（３）IdPとSP間で信頼関係を結ぶ(トラストサークルの構成)（１）IdPの構築（２）SPの構築

トラストサークル

IdP

アカウント連携

SPアカウント連携
アカウント連携

ID/パスワードなど（４）アカウント連携
Copyright © 2011 Open Source Solution Technology

ユーザー情報- 32 -

SAML - トラストサークル
 信頼の輪を意味する（Circle

SP2
SP1

IdP

SP2

SP2

トラストサークル

Of Trust - CoT）
 トラストサークル内の SP に対してのみ SSO 可能
 IdP-SP 間でお互いを事前に登録し、トラストサークルを構成しておく必要がある お互いの証明書を交換する
 一つのトラストサークル内に複数の IdP が存在することもある

Copyright © 2011 Open Source Solution Technology- 33 -

SAML - アカウント連携（1） アカウント連携：IdP のアカウントと SP のアカウントを紐付ける
 NameID というユーザー識別子を IdP と SP 間で共有することで実現する
 NameID には以下のものが使用される
メールアドレス– ユーザー属性情報（ユーザー名など。Google Apps はユー
ザー名を Name ID として使用する）– 仮名：ランダムな文字列によるユーザー識別– X.509 の Subject–Copyright © 2011 Open Source Solution Technology- 34 -

SAML - アカウント連携（2）仮名による連携
SPIdP





ユーザーA

abc

ユーザーB

仮名

IdP のアカウントと SP のアカウントを仮名（仮 ID のようなもの）で紐付ける
基本的にユーザー毎に設定する。
初回のみ、IdP と SP にそれぞれのID/パスワードでログインする必要がある
IdP/SP 内のアカウント情報(ユーザー ID など)を隠蔽したままアカウント連携可能

ユーザー属性情報による連携
IdPSP


ユーザーA
uidattr

ユーザーA

IdP のアカウントと SP のアカウントをユーザー属性で直接連携
Google Apps はこの方式（トラストサークルに入ることで自動的に全ユーザーのアカウント連携が有効化）
自システム内のユーザー属性情報の一部を相手に知られる

Copyright © 2011 Open Source Solution Technology- 35 -

SAMLにおけるアカウントライフサイクル
SAML を利用したシングルサインオン環境における[アカウント作成→SSO→アカウント削除] のサイクル
アカウントの作成
アカウント連携
シングルサインオン
サービス利用

各ユーザーがIdPとSPの間でアカウントを連携することを許諾するアカウント連携完了後にシングルサインオン可能となる

ログアウト
アカウント連携の解除
アカウント削除

Copyright © 2011 Open Source Solution Technology- 36 -

デモ

実際にSAMLのシングルサインオン設定をやってみる
IdP の設定

SP の設定SAML IdP

SAML SPOpenAM

Google Apps
ログイン

アサーション

Salesforce

ユーザー
Copyright © 2011 Open Source Solution Technology- 37 -

SAMLによるシングルサインオン- シーケンス -Copyright © 2011 Open Source Solution Technology- 38 -

2通りの認証シーケンス
 SP-initiated SSO–

ユーザーは最初にSPにアクセスし、IdPでの認証に成功した後に、再びSPにアクセスする

 IdP-initiated SSO–

ユーザーは最初にIdPにアクセスし、IdPでの認証に成功した
後にSPにアクセスする

Copyright © 2011 Open Source Solution Technology- 39 -

SAMLにおけるSSO（SP-initiated SSO）
IdP（OpenAM）

SP

4
アサーション（認証情報）

3

2

1

5

ユーザー
1.ユーザーが未認証の状態で SP にアクセスする
2.SP は SAML 認証要求を IdP に送信する
3.IdP はユーザーを認証する
4.IdP での認証に成功すると、IdP は SP に SAML 認証応答（アサーションを含む）を送信する
5.SP は認証応答を受け取るとユーザーにコンテンツを提供する※この図は、HTTP Redirect Binding/HTTP POST Binding の場合の例です
Copyright © 2011 Open Source Solution Technology- 40 -

SAML 認証のシーケンス（SP-initiated SSO）

ユーザー(ブラウザ)（1）SPへアクセス

IdP（OpenAM）

SP
認証要求
生成

HTTP Redirect /HTTP POST（2）SAML認証要求メッセージ（AuthnRequest）（3-a）ユーザー認証（ログイン画面の表示）（3-b）ユーザー認証（ログインID/PWの送付）（4）SAML認証応答メッセージ（Response。アサーションを含む）(5)コンテンツ

アサーション
生成

HTTP Redirect /HTTP POST※この図は、HTTP Redirect Binding/HTTP POST Binding の場合の例です
Copyright © 2011 Open Source Solution Technology- 41 -

SAMLにおけるSSO（IdP-initiated SSO）
IdP（OpenAM）

SP

3
アサーション（認証情報）

2

1

4

ユーザー
1.ユーザーが未認証の状態で IdP にアクセスする
2.IdP はユーザーを認証する
3.IdP での認証に成功すると、IdP は SP に SAML 認証応答（アサーションを含む）を送信する
4.SP は認証応答を受け取るとユーザーにコンテンツを提供する※この図は、HTTP Redirect Binding/HTTP POST Binding の場合の例です
Copyright © 2011 Open Source Solution Technology- 42 -

SAML 認証のシーケンス（IdP-initiated SSO）

User Agent(ブラウザ)

IdP（OpenAM）

SP（1）IdPへアクセス（2-a）ユーザー認証（ログイン画面の表示）（2-b）ユーザー認証（ログインID/PWの送付）（3）SAML認証応答メッセージ（Response。アサーションを含む）(4)コンテンツ

アサーション
生成

HTTP Redirect /HTTP POST※この図は、HTTP Redirect Binding/HTTP POST Binding の場合の例です
Copyright © 2011 Open Source Solution Technology- 43 -

SAML – メッセージの送受信方法
 HTTP Redirect/HTTP POST Binding––

ブラウザが通信を中継する（HTTP Redirect/HTTP POST を利用）
IdP-SP間の直接的な通信が発生しない方式

説明

特徴

HTTP Redirect

SAML メッセージを Base64 エンコードし URL パラ
メータに埋め込んで GET メソッドで送信(HTTP ス
テータスコード 302/303 を利用)。Google Apps はSAML認証要求で使用。

URL が長すぎると、ブラウザの URL の長さ制限に抵触する可能性がある。古い携帯ブ
ラウザでは使えないことも。

HTTP POST

Base64 エンコードした SAML メッセージを HTMLフ
Form に埋め込んで POST メソッドで送信。GoogleApps、Salesforce が採用。Google Apps はSAML認
証応答で使用。

IdP へのログイン→SP への遷移を自動化するには、JavaScript を利用して自動的にPOST リクエストを送信させる必要がある。

 HTTP Artifact Binding––

IdP-SP間の直接的な通信が発生するアサーションへのリファレンスである Artifact をブラウザを介してIdPとSPの間で送受信する。IdPと SP は Artifact を利用して直接相手に SAML 認
証要求/認証応答メッセージを問い合わせる。Artifact のデータサイズは小さい。
HTTP POST Binding で Javascript が使われている場合は、セキュリティ系のツールに引っかかるかも…
Copyright © 2011 Open Source Solution Technology- 44 -

SAML RelayState
IdPで認証が完了した後に、SPの特定のURLに遷移させる

User Agent(ブラウザ)（1）SPへアクセス

SP

認証後に、最初にアクセスしようとしたコンテンツを表示させたい（2）SAML認証要求メッセージ（AuthnRequest）

IdP（OpenAM）

RelayStateというパラメーターに遷移先情報を埋め込む（3-a）ユーザー認証（ログイン画面）の表示（3-b）ユーザー認証（ログインID/PWの送付）（4）SAML認証応答メッセージ（アサーションを含む）(5)コンテンツ

RelayStateで指定された遷移先へリダイレクトさせる※この図は、HTTP Redirect Binding/HTTP POST Binding の場合の例です
Copyright © 2011 Open Source Solution Technology- 45 -

SAMLによるシングルサインオン- アサーション -Copyright © 2011 Open Source Solution Technology- 46 -

SAML - アサーション
 IdP が発行する、ユーザーに関する認証情報の XML アサーションの改竄によるユーザーなりすましなどを防ぐために、XML デジタル署名を付加する–

事前に IdP の証明書を SP に登録しておく必要がある<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0"ID="s2907181983bc6f588aeb045fca183d671224506ec" IssueInstant="2009-1118T08:28:09Z">
アサーション発行者
アサーションのデジタル署名
ユーザー識別子(NameID)</saml:Assertion>

Copyright © 2011 Open Source Solution Technology- 47 -

SAML - 認証要求・認証応答
 認証要求（AuthnRequest）–

SPがIdPに対して、ユーザーの認証情報（アサーション）を要求するメッセージ<samlp:AuthnRequest ID=”xxx” Version=”2.0” Destination=”http://idp.osstech.co.jp/idp/sso”>

認証要求情報</samlp:AuthnRequest>

 認証応答（Response）–

IdPがSPにユーザーの認証情報（アサーション）を送付する
メッセージ<samlp:Response ID=”xxx” Version=”2.0” Destination”http://sp.osstech.co.jp/sp/sso”>< saml:Assertion ...>

アサーション</saml:Assertion></samlp:AuthnRequest>

Copyright © 2011 Open Source Solution Technology- 48 -

デモ

実際にSAMLメッセージを覗いてみる
ユーザー(ブラウザ)（1）SPへアクセス

ここSPIdP（OpenAM）（2）SAML認証要求メッセージ（AuthnRequest）（3-a）ユーザー認証（ログイン画面）の表示（3-b）ユーザー認証（ログインID/PWの送付）

ここ（4）SAML認証応答メッセージ（Response。アサーションを含む）(5)コンテンツ
Copyright © 2011 Open Source Solution Technology- 49 -

SAML 製品/サービス選定のポイント
 SAML仕様をフルスペックで実装している製品/サービスは少ないと思われる

 特に、SAML SP 側ではその（SPが提供する）サービスに必要なSAML 仕様しか実装されていないことも– IdP-initiated SSO には対応しているが、SP-initiated SSOには対応していない– RelayState に対応していない

SAML 対応製品/サービスを選定する際はSAML 仕様がどこまで実装されているか確認することが大切（ “イケてない”SSO環境になってしまうことも… ）Copyright © 2011 Open Source Solution Technology- 50 -

SAMLによるシングルサインオン- ネットワーク構成 -Copyright © 2011 Open Source Solution Technology- 51 -

SAML IdP のネットワーク上の配置 - その１
 認証を行なうSAML IdP（OpenAM）を社内LANに設置すること

で、SAML SP（Google Apps、Salesforceなど） へのアクセスを社内のみからに制限することが可能 「俺専用 IdP」を作ることも可能（実用性はあまり無い…）
社内LAN

インターネット

IdP（OpenAM）

SP

HTTP(HTTPS)
HTTP/HTTPSHTTP/HTTPS
認証情報

ログイン
ユーザー

ユーザー

Copyright © 2011 Open Source Solution Technology- 52 -

SAML IdP のネットワーク上の配置 - その２
 社外からも SAML SP（Google Apps、Salesforceなど） にアクセスする場合は、SAML IdP（OpenAM）を社外からアクセス可能な場所に設置する（DMZなど）
社内LAN

DMZ

インターネットIdPSPHTTP/HTTPS

ログイン

HTTP/HTTPS
認証
情報

認証
情報

ユーザー

ログイン

Copyright © 2011 Open Source Solution Technology

ユーザー- 53 -

ID管理との組み合わせで効果倍増！

Copyright © 2011 Open Source Solution Technology- 54 -

ID 管理 & SSO
ID 管理ツール

ID管理
システム管理者

ID 連携
ActiveDirectory

Google Apps
Salesforce
ファイルサーバ

ファイル
サーバー

LDAP

メールサーバー/
クラサバ

クラウド

Webアプリ

SSO
Windowsログオン/
LDAP 認証

ログイン
ログイン

ユーザー
Copyright © 2011 Open Source Solution Technology- 55 -

ID管理との連携
 シングルサインオンとID管理は一緒に使うことで最大の効果を発揮する
ユーザーID/パスワードはシングルサインオンシステムで一元管理可能でも、各アプリケーション/サービスに必要なユー
ザー情報は、基本的には個々に管理される– ID管理ツールなどを利用したID一元管理をしなければ、シングルサインオンは破綻することも– クラウドサービスにおいてもID管理は必要

クラウドサービス側にもユーザー情報を保存することから、ID管理の対象となる– ID管理用のAPI（プログラムインタフェース）を備えているものも多い（Google Apps、Yahoo! など）–Copyright © 2011 Open Source Solution Technology- 56 -参考情報










LIBERTY ALLIANCE のセミナー資料（SAML）– http://wiki.projectliberty.org/images/9/94/080215_JapanSIG_Techni
cal_Seminar.pdf– SAML を調べるのであれば、まず最初に読むのがおすすめ
SAML 公式サイト– http://saml.xml.org/– オープンソースの SAML 実装：http://saml.xml.org/wiki/saml-opensource-implementations
SAML 仕様の原文– http://www.oasis-open.org/specs/index.php#saml
Google Apps の SAML シングルサインオンの解説– http://code.google.com/intl/ja/apis/apps/sso/saml_reference_imple
mentation.html
Salesforce の SAML SSO 設定（IdPとしてOpenSSOを想定）– http://wiki.developerforce.com/index.php/Single_SignOn_with_SAML_on_Force.com
OSSTechのOpenSSO勉強会資料– http://www.osstech.co.jp/techinfo/opensso
Copyright © 2011 Open Source Solution Technology- 57 -

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

Copyright © 2011 Open Source Solution Technology- 58 -