OSSTech OpenSSO社内勉強会資料

Transcription

1 Open Source Solution Technology OpenSSO 社内勉強会第二回 - SAML - オープンソース ソリューション テクノロジ株式会社 2009/12/1 野村健太郎 - 1 -

2 目次 概要 SAML とは SSO の全体像 SAMLによるSSO 実現のための準備 SSOの開始 詳細 SAMLの構成要素 SAMLアサーション SAMLプロトコル SAMLバインディング デモ その他 - 2 -

3 概要 - SAML とは? SAML:Secure Assertion Markup Lauguage 認証 認可 ユーザ属性情報などを XML で送受信するためのフレームワーク ( Markup Lauguage だが 言語だけの規約ではない ) 公式サイトより : XML-based framework for communicating user authentication, entitlement, and attribute information. 認証情報 を どんなフォーマット (XML) で どの通信プロトコルを使って 送受信するか規定する 最新バージョンが SAML

4 概要 - SAML 仕様の原文 から入手可能 saml-authn-context-2.0-os.pdf saml-bindings-2.0-os.pdf saml-conformance-2.0-os.pdf saml-core-2.0-os.pdf saml-glossary-2.0-os.pdf saml-metadata-2.0-os.pdf saml-profiles-2.0-os.pdf saml-sec-consider-2.0-os.pdf それぞれが数十ページ なんとか挫折せずに読める文章量 - 4 -

5 概要 - SAML での SSO 全体像 ユーザ 認証基盤 ID 管理 (1) ログイン エンティティと呼ぶ (entity: 主体 存在 ) ユーザ IdP SP Identity Provider (IdP) 認証情報 ( アサーション ) (2) サービスへアクセス ( ログイン操作なし ) ブラウザ経由の通信 認証情報 ( アサーション ) IdP-SP 間で通信 認証情報 ( アサーション ) 認証情報 ( アサーション ) XML で認証情報をやりとりする Cookie ではない Service Provider (SP) 事業者 A のサービス (hoge.com) 事業者 B のサービス (foo.com) - 5 -

6 概要 - SAML で SSO を実現するための準備 (1)IdP の設置 (3)CoT の構成 トラストサークル (Circle of Trust - Cot) (2)SP の設置 IdP アカウント連携 アカウント連携 SP アカウント連携 ID/ パスワード (4) アカウント連携の許諾 ( ユーザ毎 ) ユーザ情報 - 6 -

7 概要 - トラストサークル (Circle of Trust - CoT) 信頼の輪 CoT 内の SP に対してのみ SSO 可 SP1 SP2 IdP SP2 SP2 Circle of Trust 能 IdP-SP 間でお互いを事前に登録し CoT を構成しておく必要がある 一つの CoT 内に複数の IdP が存在することもある - 7 -

8 概要 - アカウント連携 (1) IdP のアカウントと SP のアカウントを紐付ける NameID というユーザ識別子を IdP と SP 間で共有することで実現する NameID には以下のものが使用される メールアドレス X.509 の Subject ユーザ属性情報 ( ユーザ ID など Google Apps はこのタイプ ) 仮名 : ランダムな文字列によるユーザ識別 - 8 -

9 概要 - アカウント連携 (2) IdP ユーザ A IdP ユーザ A uid attr abc 仮名 SP ユーザ 1 SP ユーザ 1 仮名による連携 IdPのアカウントとSPのアカウントを仮名 ( 仮 IDのようなもの ) で紐付ける IdP/SP 内のアカウント情報 ( ユーザ IDなど ) を隠蔽したままアカウント連携可能ユーザ毎に設定する : 初回のみ IdPとSPにそれぞれのID/ パスワードでログインする必要あり ユーザ属性情報による連携 IdPのアカウントとSPのアカウントをユーザ属性で直接連携自システム内の情報の一部を相手に知らせる必要がある Google Apps はこの方式 - 9 -

10 概要 - 認証連携 (SSO) CoT の構成 アカウント連携が完了して SSO 可能になる ユーザ 認証基盤 ID 管理 (1) ログイン Identity Provider (IdP) IdP-SP 間で通信 認証情報 ( アサーション ) ブラウザ経由の通信 認証情報 ( アサーション ) (2) サービスへアクセス ( ログイン操作なし ) 認証情報 ( アサーション ) Service Provider (SP) 事業者 A のサービス (hoge.com) 事業者 B のサービス (foo.com)

11 概要 - アカウントのライフサイクル アカウント作成 ~SSO の利用 ~ アカウント削除のサイクル アカウントの作成 アカウント連携 シングルサインオン IdP と SP の間でアカウントを連携することを許諾する サービス利用 ログアウト アカウント連携完了後にシングルサインオン可能となる アカウント連携の解除 アカウント削除

12 詳細 - SAML の構成要素 プロファイル Web SSO 等を実現するためのアサーション プロトコル バインディングの組み合わせ方法を規定 バインディング SAML 要求 応答メッセージを通信プロトコル (HTTP,SOAP など ) にマッピングする方法を規定 プロトコルアサーションをやりとりするための要求 応答メッセージを規定 アサーション認証情報 属性情報 権限許諾情報の格納方法を規定 ユーザが SP にアクセスすると SP は IdP に対して認証要求を送信し IdP は認証要求に対する認証応答を返す SAML 認証要求メッセージを base64 エンコードして HTTP メッセージボディに埋め込んで POST する 認証要求 (XML) に対して 情報 YYY を含んだ認証応答 (XML) を返す XML のこの要素に情報 XXX を格納する 分かり易くするために 不正確かもしれないので注意

13 詳細 - アサーション IdP が発行するユーザに関する証明情報の XML <saml:assertion xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" Version="2.0" ID="s bc6f588aeb045fca183d ec" IssueInstant=" T08:28:09Z"> アサーション発行者アサーションのデジタル署名アサーションの利用条件ユーザ識別子 (NameID) </saml:assertion>

14 詳細 SAML プロトコル 認証要求 (AuthnRequest) SP が IdP に対して ユーザの認証情報を要求する <samlp:authnrequest ID= xxx Version= 2.0 Destination= > 認証要求情報が入る </samlp:authnrequest> 認証応答 (Response) IdP が SP にユーザの認証情報 ( アサーション ) を送付する <samlp:response ID= xxx Version= 2.0 Destination > < saml:assertion...> アサーションが入る </saml:assertion> </samlp:authnrequest>

15 詳細 - バインディング (Binding) SAML メッセージを既存の通信プロトコル (HTTP SOAP など ) にマッピングする ( 埋め込む ) 方法を規定 IdP-SP 間の通信有無で分けてみる ( 一番使いそうなやつだけ抜粋 ) 無 :HTTP Redirect HTTP POST バインディング HTTP Redirect:Google Apps ( 認証要求 ) で利用されている HTTP POST:Google Apps( 認証応答 ) salesforce で利用されている 有 :HTTP Arifact バインディング

16 詳細 - HTTP Redirect/POST バインディング ブラウザが通信を中継し IdP-SP 間の通信が発生しない IdP (1) ログイン 認証情報 ( アサーション ) ユーザ (2) サービスへアクセス ( ログイン操作なし ) 認証情報 ( アサーション ) SP (2) アサーションが返される アサーションを HTTP Redirect もしくは HTTP Post で送信 方式説明特徴 HTTP Redirect SAML のメッセージを Base64 エンコードして URL パラメータに載せて GET メソッドで送信 (HTTP 302 を利用 ) URL が長すぎると ブラウザの URL の長さ制限に引っかかる可能性がある (IE は 2,083 文字らしい ) HTTP POST Base64 エンコードした SAML メッセージを HTML フォームに載せて POST メソッドで送信 JavaScript で自動的に POST リクエストを送信させるのが一般的? Google Apps salesforce はこのタイプ IdP へのログイン SP への遷移を自動化するには ブラウザで JavaScript が実行可能となっている必要がある

17 詳細 - HTTP Redirect/POST バインディング Browser SP IdP SPのコンテンツへアクセスユーザは未認証 SAML 認証要求メッセージ (AuthnRequest) HTTP Redirect or POST ログイン画面 ユーザ認証 ( ユーザ ID/ パスワード送信 ) SAML 認証応答メッセージ (Response 認証情報 ( アサーション ) を含む ) アサーション生成 HTTP Redirect or POST SP のコンテンツ

18 詳細 HTTP Artifact バインディング Artifact:SAML メッセージ識別用のランダム文字列 Artifact を利用して IdP-SP 間で直接 SAML メッセージを送受信する (SOAP を利用 ) アサーションがクライアントに渡ることがない ユーザ (1) ログイン Artifact IdP(SP) (4) アサーションを SP へ送信 認証情報 ( アサーション ) Artifact (2) ブラウザ経由で Artifact を SP に送信 (3)Artifact を使用して SAML メッセージを IdP へ問い合わせ SP(IdP) (5) サービスへアクセス ( ログイン操作なし )

19 詳細 HTTP Artifact バインディング Browser SP IdP SPのコンテンツへアクセスユーザは未認証 Artifact をリダイレクトリ Artifact 生成 ArtifactRequest メッセージ ArtifactResponse メッセージ SAML 認証要求メッセージ を要求 SAML 認証要求 ログイン画面表示 ユーザ認証 ( ユーザ ID/ パスワード ) Artifact をリダイレクトリ アサーションと Artifact を生成 SP のコンテンツ ArtifactRequest メッセージ ArtifactResponse メッセージ SAML 認証応答メッセージ を要求 SAML 認証応答

20 デモ 1. Google Apps の SAML 認証が HTTP POST バインディングで行われる様子を見てみる 2. LDAP に保存されている NameID を直接いじってみる OpenSSO にはユーザ A でログインし Google Apps にはユーザ B でログインする

21 詳細 シングルログアウトプロファイル SP1 SP2 IdP ログアウト要求メッセージ アサーションを発行した全ての SP にログアウト要求メッセージを送付 ログアウト要求メッセージ Artifact Redirect POST バインディング ログアウト結果送付 ログアウト結果送付 OpenSSO + Google Apps + Liferay + Alfresco のデモで Google Apps からログアウトすると Liferay からもログアウトするが これは SAML のシングルログアウトではない

22 詳細 - メタデータ SAML で SSO を利用するためには あらかじめ CoT の構成 アカウント連携などを行っておく必要がある これらの作業に必要な情報をまとめた XML データをメタデータという メタデータがあれば IdP SP の構築作業が楽になる 例 :Google Apps のメタデータ <EntityDescriptor entityid="google.com" xmlns="urn:oasis:names:tc:saml:2.0:metadata"> <SPSSODescriptor protocolsupportenumeration="urn:oasis:names:tc:saml:2.0:protocol"> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat> <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=" ドメイン名 /acs" /> </SPSSODescriptor> </EntityDescriptor>

23 詳細 - アサーションへの XML デジタル署名 アサーションの改竄によるユーザなりすましなどを防ぐために XML デジタル署名を付加する IdP の証明書を SP に登録しておく必要がある

24 参考 Liferay と Alfresco のログアウト OpenSSO(IdP) Session Google Apps(SP) アサーション Liferay 毎回 Cookei の正当性を確認 OpenSSO(IdP) チェック不合格 意図せずログアウト Google Apps Liferay Cookie Cookie ユーザ Cookie Alfresco 初回だけ Cookei の正当性を確認 ユーザ Cookie Alfresco Liferay と Alfresco は Cookie でログインセッションを管理 Google からログアウト (SAML シングルログアウトプロファイル ) ログインしたまま ( キャッシュしているため )

25 参考文献 LIBERTY ALLIANCE のセミナー資料 最初に読むならこれがおすすめ ( 今回の勉強会資料の元ネタ ) SAML 仕様の原文 実システムでの SAML Google Apps: ml salesforce