「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>SAML]] * 目次 [#a06b9ed3] #contents *概要 [#vbc3dabd] 汎用認証サイトに[[SAML2.0を実装>SAMLを実装する。]]するため仕様を読む。 -ターゲットはSP Initiated な Web Browser SSO Profileに絞る。 -ココに書いた情報は、SAML の Technical Overviewと他社コンテンツの情報の範囲。 **ロードマップ [#sf77f12f] ***Technical Overview [#pd627a26] SAML2.0 の 技術概要 ***[[Profiles>#m2dca880]] [#kb883fb8] 特定のユースケースを実現するための組み合わせ方を定義。 -セキュリティ情報を伝達するためのSAMLの豊富で柔軟な~ 構文を使用および制限するための一連の特定の規則を定義。 -属性プロファイルの構文の側面をカバーするいくつかの関連する小さなスキーマ。 ***[[Bindings>#k4afd6db]] [#g931e8e8] -SAMLアサーションと要求/応答プロトコル・メッセージを交換する方法を定義 -SAMLのメッセージを実際の通信プロトコル(HTTPなど)にマッピングする方法を定義。 ***Core ([[Assertions>#i94f5010]] and [[Protocols>#w2f5d61a]]) [#c88e28ae] -認証、属性、許可情報を記述したプロトコル・メッセージを伝達する~ XMLエンコードアサーションを作成するための構文とセマンティクス -アサーション用とプロトコル用のスキーマを定義する。 --認証情報を表す用のXMLのスキーマ(SAML Assertions) --メッセージ交換のプロトコル用のXMLのスキーマ(SAML Protocols) ***[[SAML Metadata>#fcb8eb3c]] [#q8f094d8] -SAMLパーティ間で設定情報を表現および共有するXMLのスキーマを定義 -SPがIdPを利用するための情報を記述して、IdPとSPの信頼関係を構築できる。 --エンティティのサポートされているSAMLバインディング --運用上の役割(IDP、SPなど) --識別子情報、サポートID属性 --および暗号化と署名のための鍵情報 ***[[Authentication Context>#fcb8eb3c]] [#s446c19b] -認証メカニズムを記述するAuthentication Context宣言を記述するための構文を定義 -認証のタイプと強度に関する詳細な情報をSPが要求し、IdPは、これに応答する。 --Authentication Context宣言を作成するためのメカニズムを定義する一般的なXMLスキーマ --一般的に使用されるSAMLのAuthentication Contextクラスのセットがあります。 ***XML Signature Syntax and Processing [#tfaf9dfe] XMLデジタル署名処理規則と構文 **ユースケース [#n6964f09] ***参加者 [#b51c01cb] -システム・エンティティ~ システム・エンティティは、さまざまなSAMLロールで動作するが、~ 最低限、SAML交換は、以下のシステム・エンティティ間で行われる。 --アサーティング・パーティ(SAMLオーソリティ) ---SAMLアサーションを行うシステム・エンティティ ---ユーザもアサーティング・パーティの参加者である可能性がある。 --リライング・パーティ(RP)~ 受け取ったアサーションを使用するシステム・エンティティ -リクエスタ / レスポンダ --アサーティング・パーティとリライング・パーティは、SAMLリクエスタにもレスポンダにもなりうる。 --アサーティング・パーティの情報に依存するという回答側の意向は、アサーティング・パーティとの信頼関係に依存 -ロール --SSOのロール ---Identityプロバイダ(IdP)~ ≒ アサーティング・パーティ(SAMLオーソリティ) ---Serviceプロバイダ(SP)~ ≒ リライング・パーティ --のロール ---属性リクエスタ~ アイデンティティ属性クエリ ---属性機関の役割~ アイデンティティ属性クエリに応答してSAMLエンティティがアサーションを生成 -サブジェクト≒プリンシパル --殆どのSAMLアサーションの中心にある対象 --通常は人間、それ以外にも会社やコンピュータなどエンティティを表す。 -あとは、だいたい、[[OpenID Connect]]と同じ。 ***Web-SSO [#rc0fec8e] -マルチドメインWebシングルサインオン -SAMLが適用される最も重要なユースケース -これも、あとは、だいたい、[[OpenID Connect]]と同じ。 ***IDフェデレーション [#vb0acf73] -考慮しなければならない多くの質問 --ユーザーは、既存のローカルIDをサイトに持っているか? --ユーザーの連合IDの確立と終了は静的か?動的か? --ユーザーは連合IDの確立に明示的に同意する必要があるか? --ユーザーに関するID属性を交換する必要があるか? --IDフェデレーションは、SessionIDなどの識別子に依存するべきか? --情報が暗号化されるべきか?交換される情報のプライバシーは大きな関心事か? -連合ID機能を強化するための2つの機能 --フェデレーション名識別子の動的確立と管理をサポートする、新しい構成とメッセージ --プライバシー保護の特徴を持った2つの新しいタイプの名前識別子 -プロバイダー間のユーザー情報の維持および更新 --追加のフローは必要のないケース。 --追加のフローが必要になるケース。~ SAML V2.0メッセージ交換の外部で行われるケース ---IdPにおけるデータソースによって駆動され、 ---SPに伝播されるバッチまたはオフラインのIDフィードを利用 ***アカウントリンク [#q6750564] -連合IDをローカルIDと関連付けるプロセスは、アカウントリンクと呼ばれる。 --IdP検出機能を使用し、SPからIdPにアカウントリンクするかしないかをユーザに問う。 --ユーザが、フェデレーションに同意するとIdPにリダイレクトされる。 --IdPでSPのフェデレーション名識別子が生成され、IdP上のアカウントにリンクされる。 --IdPでSPは、後続のトランザクションでこの識別子を使用してユーザを参照する。 --IdPからSPにリダイレクトされた後、この識別子をSPのローカル・アカウントに関連付ける。 ※ 追加のサイトとアカウントリンクする場合は、~ 新たにフェデレーション名識別子を生成し、上記手順を繰り返す。 *アーキテクチャ [#n8e9f1a2] **基本概念 [#ddcc00d7] ***基本的なSAMLの概念 [#f1f1efc7] (Profile(Binding(Protocol(Assertion)))) ・Metadata ・Authentication Context ***[[Assertions>#ob41551e]] [#i94f5010] アサーティング・パーティが真実であると主張するプリンシパルに関する~ ステートメントを伝えるXMLスキーマによって定義されたアサーション。 -リライング・パーティからの要求に基づいてアサーティング・パーティによって作成される。 -特定の状況下では、アサーションは未承諾の方法でリライング・パーティに配信できる。 ***[[Protocols>#c03d25d8]] [#w2f5d61a] -SAMLのリクエスト / レスポンスを行うプロトコル。 -これにより、アサーションの入手や、IDマネジメントを行う。 ***[[Bindings>#tf061676]] [#k4afd6db] 参加者間でSAMLプロトコル・メッセージを転送するために下位レベルの~ 通信またはメッセージングプロトコル(HTTPまたはSOAPなど)を使用する方法 ***[[Profiles>#ddf7fc83]] [#m2dca880] -WebブラウザSSOプロファイルなどの特定のユースケースを満たすように定義される。 -SAMLアサーション、プロトコル、およびバインディングの内容に対する制約を定義する。 -プロトコルメッセージやバインディングを参照しない属性プロファイルもある。~ (X.500 / LDAP、DCEなどの一般的な使用環境と一致する方法でアサーションを使用) ***構築と展開の2つの概念 [#fcb8eb3c] -[[SAML Metadata]] -[[Authentication Context]]~ Authentication Contextの例 |#|Authentication Context|説明|h |1|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|パスワードを提示して認証したことを示す| |2|urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession|セッション等を使用し、&br;・すでに認証済みであること示す。&br;・過去のある時点で認証したこと示す。| |3|urn:oasis:names:tc:SAML:2.0:ac:classes:X509|デジタル署名により認証したことを示す。| |4|urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified|不特定の方法で認証したことを示す。| ***高度な概念 [#g32a27e9] -Subject Confirmation --Assertionsには、SubjectConfirmationという要素を含めることができる。 --実際的には、Subject Confirmationは、 ---Assertionの利用者が許可されている条件 ---≒ SPが検証を行うための手段を提供する。 --Method属性に3つの値を定義することによって、~ 3つの異なるセキュリティシナリオに対応する。 ---urn:oasis:names:tc:SAML:2.0:cm:bearer~ 所謂、一つの、[[持参人切符>トークン#b38de47f]] ---urn:oasis:names:tc:SAML:2.0:cm:holder-of-key~ SubjectConfirmationDataを使用した、[[記名式切符>トークン#b38de47f]] ---urn:oasis:names:tc:SAML:2.0:cm:sender-vouches~ どのRPがそのClaimを使用することを許可されるべきかを決定する際に他の基準を使用 **SAML Components [#z682ff17] ***[[Assertions>SAML Assertions]] [#ob41551e] 通常、アサーションは以下から構成される。 -アサーションのsubject --subject(主題) --subjectが存在しない場合、他の方法で識別される。~ 例えばsubjectの確認に使用された証明書 -アサーションの検証条件 -アサーション・ステートメント --Authentication statements ---ユーザーを正常に認証した当事者によって作成される。 ---最低でも、認証に使用される特定の手段と認証が行われた特定の時間を説明。 --Attribute statements ---サブジェクトに関する特定の識別属性 ---例えば、ユーザー"John Doe"は"ゴールドカードステータス"を持つ。 --Authorization decision statements ---対象がする権利があるものを定義する ---例えば、ユーザー"John Doe"は"特定の品目を購入すること"が許可されている。 ***[[Protocols>SAML Protocols]] [#c03d25d8] いくつかの一般化された要求/応答プロトコルを定義する。 -Authentication Request Protocol --以下を含むアサーションを要求できるようにする手段を定義。 ---Authentication statements ---Attribute statements --Web Browser SSO Profile~ SPからIdPにユーザをリダイレクトするときに使用する。 -Single Logout Protocol --プリンシパルのアクティブ・セッションのログアウト・メカニズムを定義。 --ログアウトは以下の様なエンティティが開始できる。 ---ユーザ(直接開始 ---SP/IdP(Sessionタイムアウト、管理者コマンド -Assertion Query and Request Protocol~ アサーションを取得するための一連のクエリを定義 -Artifact Resolution Protocol~ アーティファクトと呼ばれる小さな固定長の値を使用して、~ メッセージを参照によって渡すことができるメカニズムを提供 -Name Identifier Management Protocol --要求の発行者は、SP/IdPのどちらでもかまわない。 --プリンシパルを参照するために使用される名前識別子に関するメカニズムを提供。 ---形式を変換する ---関連付けを開始 / 終了する -Name Identifier Mapping Protocol --適切なポリシー制御に従って、名前識別子を~ 別の名前識別子にマッピングするためのメカニズムを提供 --アプリケーション統合シナリオでは、あるSPがIdPから~ 別のSPで使用できるユーザーの名前識別子を要求することを許可する。 ***[[Bindings>SAML Bindings]] [#tf061676] トランスポート層上で、プロトコルメッセージをどのように伝達するか? -HTTP Redirect Binding~ リダイレクト(302応答)を使用してプロトコルメッセージを転送する方法を定義 -HTTP POST Binding~ HTMLのformコントロール(base64)でプロトコルメッセージを転送する方法を定義 -HTTP Artifact Binding --Artifact Resolution Protocolを使用して、プロトコルメッセージを転送する方法を定義 --HTMLのformコントロールと、URL中のQuery stringを使用する方法がある。 -SAML SOAP Binding~ SOAP 1.1を使用して、プロトコルメッセージが転送される方法を定義 -Reverse SOAP (PAOS) Binding --HTTPクライアントをSOAPレスポンダにする多段階のSOAP / HTTPメッセージ交換を定義 --IDPディスカバリをサポートする拡張クライアントおよびゲートウェイ・プロキシで使用 -SAML URI Binding~ URIを解決することによって既存のSAMLアサーションを取得するための手段を定義 ***[[Profiles>SAML Profiles]] [#ddf7fc83] 特定シナリオでアサーション、プロトコル、バインディングの組合せ(制約)を定義 -Web Browser SSO Profile~ 標準のWebブラウザでシングルサインオンを実現する --以下の使用方法を定義する。 ---Authentication Request Protocol ---SAML Response messages & assertion --バインディングの組合せを定義 ---HTTP Redirect Binding ---HTTP POST Binding ---HTTP Artifact Binding -Enhanced Client and Proxy (ECP) Profile --特殊クライアントまたはゲートウェイ・プロキシ用の --Reverse-SOAP (PAOS) や SOAPを使用する特殊SSOプロファイルを定義す。 -Identity Provider Discovery Profile~ ユーザが以前に訪問したことのあるIdPについてSPが知るためのメカニズムを定義 -Single Logout Profile --以下の使用方法を定義する。 ---Single Logout Protocol ---SAML Response messages & assertion --バインディングの組合せを定義 ---HTTP Redirect Binding ---HTTP POST Binding ---HTTP Artifact Binding ---SAML SOAP Binding -Assertion Query and Request Profile --同期バインディング --以下の使用方法を定義する。 ---Assertion Query and Request Protocol ---SAML Response messages & assertion -Artifact Resolution Profile --以下の使用方法を定義する。 ---Artifact Resolution Protocol --バインディングを定義 ---SAML SOAP Binding -Name Identifier Management Profile --以下の使用方法を定義する。 ---Name Identifier Management Protocol --バインディングの組合せを定義 ---HTTP Redirect Binding ---HTTP POST Binding ---HTTP Artifact Binding ---SAML SOAP Binding -Name Identifier Mapping Profile --以下の使用方法を定義する。 ---Name Identifier Mapping Protocol --バインディングを定義 ---SAML SOAP Binding ***EndPoint [#rffd6c08] この項目は、SAMLの公式資料にはないが、図を見ると、~ EndPointには以下の様な名称が付与されている。 -Single sign-on --SAML Requestを受けるEndPoint~ SSO Service --SAML Responseを受けるEndPoint~ Assertion Consumer Service -Artifact --Artifact Requestを発行するEndPoint ---SSO Service(RequestでArtifactを使用する場合) ---Assertion Consumer Service(ResponseでArtifactを使用する場合) --Artifact Requestを受けるEndPoint~ Artifact Resolution Service -Single logout --SAML Requestを受けるEndPoint~ Single logout Service --Logout Request/Responseを受けるEndPoint~ Single logout Service --SAML Responseを受けるEndPoint~ Assertion Consumer Service -Termination --ManageIDNameRequest (Termination) を受けるEndPoint~ Manage NameID Service --ManageIDNameRequest (Affirmative) を受けるEndPoint~ ? **SAML XML構造と例 [#t9f9470e] ***SAMLコンポーネントとの関係 [#f15c31d8] Transport Protocol -Transport Protocol ヘッダ -Transport Protocol ペイロード --レスポンス(アサーション) ---Authentication statements ---Other statements ***Assertion、Subject、Statementの構造 [#da3c974b] -単一のAuthentication statementを含むAssertionの例を含むXMLフラグメント 1: <saml:Assertion 2: xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 3: Version="2.0" IssueInstant="2005-01-31T12:00:00Z"> 4: <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity>> ... Nature of the assertion. 5: http://idp.example.org 6: </saml:Issuer> 7: <saml:Subject> ... Subject of the assertion. 8: <saml:NameID 9: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> 10: j.doe@example.com 11: </saml:NameID> 12: </saml:Subject> 13: <saml:Conditions ... Additional conditions of period. 14: NotBefore="2005-01-31T12:00:00Z" 15: NotOnOrAfter="2005-01-31T12:10:00Z"> 16: </saml:Conditions> 17: <saml:AuthnStatement ... Authentication statement 18: AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772"> 19: <saml:AuthnContext> 20: <saml:AuthnContextClassRef> 21: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 22: </saml:AuthnContextClassRef> 23: </saml:AuthnContext> 24: </saml:AuthnStatement> 25: </saml:Assertion> -NameIDのフォーマット --Email address --X.509 subject name --Windows domain qualified name --Kerberos principal name --Entity identifier --Persistent identifier ---プライバシー保護仮名を使用する。 ---通常単一のSPでのみ使用するために確立される。 ---明示的に削除されるまでローカルIDと関連付けられたままになる。 ---Name Identifier Mapping Protocolにより所属という概念に対するサポートも提供。 --Transient identifier ---プライバシー保護仮名を使用する。 ---IdPで作成された使い捨て識別子に対応するため、SPでの匿名性をサポート。 ---SPで特定のローカルIDと関連付けられておらず、セッションが終了すると破棄される。 ***Attribute statementsの構造 [#pac907bc] -SAMLの属性構造は、特定のタイプの --データストア --データタイプ >が属性に使用されているとは想定していない。 -注意 --単一のステートメントに複数の属性を含めることができる。 --属性名は、属性名を解釈するか名前形式で修飾される。 1: <saml:AttributeStatement> 2: <saml:Attribute ... SAML X.500 / LDAP属性プロファイル 3: xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" 4: NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 5: Name="urn:oid:2.5.4.42" FriendlyName="givenName"> 6: <saml:AttributeValue xsi:type="xs:string" x500:Encoding="LDAP"> 7: John 8: </saml:AttributeValue> 9: </saml:Attribute> 10: <saml:Attribute 11: NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" 12: Name="LastName"> 13: <saml:AttributeValue xsi:type="xs:string"> 14: Doe 15: </saml:AttributeValue> 16: </saml:Attribute> 17: <saml:Attribute 18: NameFormat="http://smithco.com/attr-formats" 19: Name="CreditLimit"> 20: xmlns:smithco="http://www.smithco.com/smithco-schema.xsd" 21: <saml:AttributeValue xsi:type="smithco:type"> 22: <smithco:amount currency="USD">500.00</smithco:amount> 23: </saml:AttributeValue> 24: </saml:Attribute> 25: </saml:AttributeStatement> ***Message構造とSOAP Binding [#v1fef9e7] -SAMLパーティがSOAP対応である環境では、~ SOAP Bindingを使用してSAML要求/応答プロトコルメッセージを交換できる。 -HTTP Response --SOAP envlope ---SOAP ヘッダ ---SOAPボディ~ SAMLリクエスト~ or SAMLレスポンス -例 --Attribute Query in SOAP Envelope 1: <?xml version="1.0" encoding="UTF-8"?> 2: <env:Envelope 3: xmlns:env="http://www.w3.org/2003/05/soap/envelope/"> 4: <env:Body> 5: <samlp:AttributeQuery 6: xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 7: xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 8: ID="aaf23196-1773-2113-474a-fe114412ab72" 9: Version="2.0" IssueInstant="2006-07-17T20:31:40Z"> 10: <saml:Issuer> 11: http://example.sp.com 12: </saml:Issuer> 13: <saml:Subject> 14: <saml:NameID 15: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> 16: C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu 17: </saml:NameID> 18: </saml:Subject> 19: <saml:Attribute 20: NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 21: Name="urn:oid:2.5.4.42" FriendlyName="givenName"> 22: </saml:Attribute> 23: </samlp:AttributeQuery> 24: </env:Body> 25: </env:Envelope> --Response in SOAP Envelope 1: <?xml version="1.0" encoding="UTF-8"?> 2: <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> 3: <env:Body> 4: <samlp:Response 5: xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 6: xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 7: ID="i92f8b5230dc04d73e93095719d191915fdc67d5e" 8: Version="2.0" IssueInstant="2006-07-17T20:31:41Z" 9: InResponseTo="aaf23196-1773-2113-474a-fe114412ab72 "> ... 応答先の要求を参照 10: <saml:Issuer> 11: http://idp.example.org 12: </saml:Issuer> 13: <samlp:Status> 14: <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> 15: </samlp:Status> 16: ...SAML assertion... 17: </samlp:Response> 18: </env:Body> 19: </env:Envelope> **プライバシー [#z85ac213] 情報技術の文脈では、プライバシは一般に、 -自分のIDデータがどのように共有され使用されるかを制御するユーザの能力 -複数のSPでの彼らの行動が不適切に関連付けられるのを妨げるメカニズム の両方を指す。 ***ユーザの能力 [#uda60bf5] -IDデータの共有を制御するユーザの能力必要になる。 -この同意がどのように、行われるかは、SAMLの範囲外。 -SAMLは、IDデータの共有を制御するため、以下をサポートする。 --[[Authentication Context>#fcb8eb3c]]により十分な保証レベルでユーザを認証できる。 --特定の操作に同意したユーザのクレームをプロバイダ間で表現する。 ***メカニズム [#x431e44b] 仮名の確立をサポート **セキュリティ [#qc3f7d57] ***公開鍵基盤(PKI)に依存する信頼関係を推奨 [#b3dd1c10] ***HTTP over SSL 3.0またはTLS 1.0を推奨 [#k488dfbb] *主要ProfileとFederationのUseCase [#sa60a89a] **Web Browser SSO Profile [#b0db7a6e] 使用される可能性が高い典型的なフロー ***概要 [#iebc3741] 主に2つのオプションがある。 -1つ目はフローがSP開始またはIdP開始のどちらであるか --SP開始:SPで開始されるWeb SSOモデル ---ユーザはSPにログインしていないため、リソースへのアクセスを許可する前に、 SPはユーザをIdPに送信する。 ---IdPでユーザを認証し、IdPは、アサーションを作成し、アサーションをSPに送り返す。 ---SPは、アサーションを検証し、ユーザにリソースへのアクセスを許可するかどうかを決定。 --IdP開始:IdPで開始されるWeb SSOモデル ---ユーザは既に認証されていて、IdP上のSPへのリンクをクリック。 ---IdPはアサーションを作成し、、アサーションをSPに送信。 ---SPは、アサーションを検証し、ユーザにリソースへのアクセスを許可するかどうかを決定。 -2つ目はIdPとSP間のメッセージ配信に使用されるバインディング --Authentication Request message ---HTTP Redirect Binding ---HTTP POST Binding ---HTTP Artifact Binding --Authentication Response message ---HTTP POST Binding ---HTTP Artifact Binding ***SP-Initiated SSO: Redirect/POST Bindings [#r4f7a760] SP-Initiated SSO -Authentication Request message~ HTTP Redirect Bindingでリクエスト --HTTP Redirect https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token --SAML Request <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_1" Version="2.0" IssueInstant="2004-12-05T09:21:59Z" AssertionConsumerServiceIndex="1"> <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> </samlp:AuthnRequest> -Authentication Response message~ HTTP POST Bindingでレスポンス --HTML Form <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...> <input type="hidden" name="SAMLResponse" value="response" /> <input type="hidden" name="RelayState" value="token" /> ... <input type="submit" value="Submit" /> </form> --HTTP POST POST /SAML2/SSO/POST HTTP/1.1 Host: sp.example.com Content-Type: application/x-www-form-urlencoded Content-Length: nnn SAMLResponse=response&RelayState=token --SAML Response <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_2" InResponseTo="identifier_1" Version="2.0" IssueInstant="2004-12-05T09:22:05Z" Destination="https://sp.example.com/SAML2/SSO/POST"> <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_3" Version="2.0" IssueInstant="2004-12-05T09:22:05Z"> <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- a POSTed assertion MUST be signed --> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ... </ds:Signature> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"> 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData InResponseTo="identifier_1" Recipient="https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter="2004-12-05T09:27:05Z"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2004-12-05T09:17:05Z" NotOnOrAfter="2004-12-05T09:27:05Z"> <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2004-12-05T09:22:00Z" SessionIndex="identifier_3"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response> -その後 --SAML Responseのデジタル署名を検証 --内容を処理し、SPでのローカルログオンセキュリティコンテキストを作成 --SPはRelayStateデータによって、最初に要求されたリソースURLを呼び戻す。 --アクセス検査が行われ、検査に合格すると、リソースがブラウザに返される。 ***SP-Initiated SSO: POST/Artifact Bindings [#e47777e6] SP-Initiated SSO -Authentication Request message~ HTTP POST Bindingでリクエスト --HTML Form <form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...> <input type="hidden" name="SAMLRequest" value="request" /> <input type="hidden" name="RelayState" value="token" /> ... <input type="submit" value="Submit" /> </form> --HTTP POST POST /SAML2/SSO/POST HTTP/1.1 Host: idp.example.org Content-Type: application/x-www-form-urlencoded Content-Length: nnn SAMLRequest=request&RelayState=token --SAML Request~ [[同上>#r4f7a760]] -Authentication Response message --HTTP Redirect Bindingでレスポンス ---HTTP Redirect~ Technical Overviewに記載なし。 ---SAML Response~ [[同上>#r4f7a760]] --HTTP Artifact Bindingでアサーションを取得 ---Artifact Resolve <samlp:ArtifactResolve xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_2" Version="2.0" IssueInstant="2004-12-05T09:22:04Z" Destination="https://idp.example.org/SAML2/ArtifactResolution"> <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <!-- an ArtifactResolve message SHOULD be signed --> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ... </ds:Signature> <samlp:Artifact> artifact </samlp:Artifact> </samlp:ArtifactResolve> ---Artifact Response <samlp:ArtifactResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="identifier_3" InResponseTo="identifier_2" Version="2.0" IssueInstant="2004-12-05T09:22:05Z"> <!-- an ArtifactResponse message SHOULD be signed --> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status> <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_4" InResponseTo="identifier_1" Version="2.0" IssueInstant="2004-12-05T09:22:05Z" Destination="https://sp.example.com/SAML2/SSO/Artifact"> <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_5" Version="2.0" IssueInstant="2004-12-05T09:22:05Z"> <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- a Subject element is required --> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> user@mail.example.org </saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData InResponseTo="identifier_1" Recipient="https://sp.example.com/SAML2/SSO/Artifact" NotOnOrAfter="2004-12-05T09:27:05Z"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2004-12-05T09:17:05Z" NotOnOrAfter="2004-12-05T09:27:05Z"> <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2004-12-05T09:22:00Z" SessionIndex="identifier_5"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response> </samlp:ArtifactResponse> -その後 --Artifact Responseのデジタル署名を検証 --内容を処理し、SPでのローカルログオンセキュリティコンテキストを作成 --SPはRelayStateデータによって、最初に要求されたリソースURLを呼び戻す。 --アクセス検査が行われ、検査に合格すると、リソースがブラウザに返される。 ***IdP-Initiated SSO: POST Binding [#m39f4f39] もともとSAML v1でサポートされていたIdP-Initiated SSOユースケースを引き続きサポート -Authentication Request message~ N/A -Authentication Response message~ HTTP POST Bindingでレスポンス(リクエストはないが) **ECP Profile [#p2c54799] Enhanced Client and Proxy(ECP)プロファイル ***概要 [#ef2e92cd] -特別な機能を持たない市販のブラウザで動作する、 --拡張クライアントデバイス --ゲートウェイ・プロキシ >を考慮に入れたプロファイル ※ 昔の携帯電話(ガラケー)など機能の貧弱なDEVICEを想定して~ 作成された仕様であるため、昨今はあまり使われないと思う。 ***ECP Profile Using PAOS Binding [#n878b63b] PAOS(Reverse SOAP)という単一のバインディングを定義 -SOAPヘッダとSOAP本文を使用 -SAML Request、ResponseをすべてSOAPで処理する。 -これらの処理は、SP、IdP、ゲートウェイ・プロキシが協調して行う。 **Single Logout Profile [#xbb68d08] ***概要 [#x4189f24] -SAMLのシングルログアウトのプロファイル -シングルログアウト ≒ Oneアクションで複数のSP & IdPからログアウト出来る的な。 -1つのSPで開始され、IdPのSingle Logout Serviceから各SPのSingle Logout Serviceに要求が送信される。 ***SP-Initiated Single Logout with Multiple SPs [#xcb8883d] -シングルログアウトのメッセージは以下のBindingを使用できる。 --Synchronous? ---SOAP over HTTP binding --Asynchronous? ---HTTP Redirect bindings ---HTTP POST bindings ---HTTP Artifact bindings -Cookie認証チケットを削除する場合、 ブラウザをSPにリダイレクトする必要がある。 --だったら、最初からHTTP Redirect bindingsを使えと言う気もするが、 --そもそも、SOAP over HTTP bindingの場合、どうやって処理するのか? **Establishing and Managing Federated Identities [#b76fc656] Federated Identitiesを確立・管理するSAMLメカニズムの説明 ***概要 [#eb5ff25f] フェデレーションスタイル ***Federation Using Out-of-Band Account Linking [#xfc5c2d9] -SAML1.0でサポートされている唯一のスタイル(SAML2.0でも引き続きサポート)。 -SAML仕様の外でアカウント同期が行われる(Hybrid-IdP の Azure AD Connectみたいな)。 ***Federation Using Persistent Pseudonym Identifiers [#o15eda62] -IdPは、永続的なSAML名識別子を使用して、SPのローカルIDと関連付ける。 -SAML2.0では、AuthnRequestにNameIDPolicy要素を提供して、SPの動的動作を強制できる。 -以下の様なスキーマになるらしい(linked IDで、SP / Idp間のlocal IDを紐付ける) |#|>|>|SP1||>|>|IdP1|h |~|local ID|IdP|linked ID||local ID|SP|linked ID|h |1|XXX|IdP1|111|<->|AAA|SP1|111| -(初回時)動的動作で、ユーザーは、 --SPでローカルの資格情報を提供するよう求められる。 --2つのアカウントを統合したいかどうかを尋ねられる。 ***Federation Using Transient Pseudonym Identifiers [#e525246e] -一時的な仮名識別子を使用して、SSOセッションの存続期間中にSPのローカルIDと関連付ける。 -以下の様なスキーマになるらしい(SP側が一時的な仮名識別子を使用) |#|>|>|SP1||>|>|IdP1|h |~|local ID|IdP|linked ID||local ID|SP|linked ID|h |1|N/A|IdP1|111|<->|AAA|SP1|111| -連携される属性 --基本、メンバーシップレベル属性のみで匿名ユーザとして処理できる。 --必要に応じて、SAML属性クエリを属性機関に送信し、ユーザーID属性を取得できる。 ***Federation Termination [#n59fe96e] 既存のフェデレーションの終了。 -ManageIDNameRequest(Termination)をIdPのManage NameID Serviceに送信する。 -これにより、[[Federation Using Persistent Pseudonym Identifiers>#o15eda62]]の関連付けを解除する。 **Use of Attributes [#t4f28c82] SAMLアサーションによる、属性転送機能と、その属性の使い方。 ***プロファイル情報の転送 [#red0b94b] IdPからSPへユーザプロファイル情報を伝達して使用する。 ***属性に基づく承認 [#ee5e628b] -メンバーシップレベル属性のみで匿名ユーザとして処理できる。 -IdPとSPは、属性名と値に関する事前の合意を必要とする。 *詳細 [#kee3fb45] **[[SAML Profiles]] [#k63747ad] **[[SAML Bindings]] [#qf8444c6] **[[SAML Core]] [#kf601332] ***[[SAML Protocols]] [#q0a3a414] ***[[SAML Assertions]] [#ld170892] ***[[SAML Signature or Encryption]] [#ad02795d] **構築と展開の2つの概念 [#mb5fb627] ***[[SAML Metadata]] [#e5f2eb63] ***[[Authentication Context]] [#l3c09df0] **[[SAMLを実装する。]] [#z5f336d0] *以下、参考 [#f7980123] -SAML認証に関する自分なりのまとめ~ なんとな~くしあわせ?の日記~ https://nantonaku-shiawase.hatenablog.com/entry/2016/07/13/081053 -SAML Profiles ~ SSOだけじゃなく色んなシナリオあるって知ってた? ~ - Qiita~ https://qiita.com/samiii/items/6096723dfbebf049ec73 *OASIS [#j3a3bbae] OASISは「SGML Open」として1993年、 >主に「研修活動を通じたSGMLの採用促進を目的として」結成された、 SGMLツール業者の業界団体。 **SAML 1.0 [#nc13d236] -http://www.oasis-open.org/committees/download.php/2290/oasis-sstc-saml-1.0.zip -SAML 1.0(XML Security Assertion Markup Language)~ http://www.oasis-open.org/committees/security/#documents --Assertions and Protocol[SAML Core]~ http://www.oasis-open.org/committees/security/docs/cs-sstc-core-01.pdf ---SAMLのAssertionsのスキーマと要求/応答プロトコルを定めた仕様 --Bindings and Profiles[SAML Bind]~ http://www.oasis-open.org/committees/security/docs/cs-sstc-bindings-01.pdf ---SAMLをSOAPとHTTPにバインドする仕組みとSSOプロファイルの規定 --Security and Privacy Considerations[SAML Sec]~ http://www.oasis-open.org/committees/security/docs/cs-sstc-sec-consider-01.pdf ---SAMLのセキュリティ要件を考察したもの --Conformance Program Specification[SAML Conform]~ http://www.oasis-open.org/committees/security/docs/cs-sstc-conform-01.pdf ---SAMLの相互運用性を確保するために適合性要件をまとめたもの --Glossary[SAML Gross]~ http://www.oasis-open.org/committees/security/docs/cs-sstc-glossary-01.pdf **SAML 1.1 [#bbfbf034] -http://www.oasis-open.org/committees/download.php/3400/oasis-sstc-saml-1.1-pdf-xsd.zip **SAML 2.0 [#ta30f79c] http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip -Security Assertion Markup Language (SAML) V2.0 Technical Overview - OASIS~ http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html -以下を読むとイイらしい。~ >某[[Qiita>SAMLを実装する。#q968ebd8]]の記事を参考にすると、TechnicalOverview をざっと眺めて、~ どの Profile か選択してから Profile, binding, core と見ていくとイイらしい。 -https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf -https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf -https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf -https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf -https://www.w3.org/TR/xmldsig-core1/ -その他、ロードマップに含まれるもの。 --SAMLAuthnCxt~ http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf --SAMLMeta~ http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf **Reference [#r10980ea] ***用語集 [#obb9527d] -SAML仕様全体を通して使用される用語を規範的に定義 -可能な限り、用語は他のセキュリティ用語集で定義されている用語と一致させてある。 -SAMLGloss~ http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf ***適合要件 [#t20f88fb] -SAMLConform~ http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf ***セキュリティとプライバシーに関する考慮事項 [#k221450f] SAMLのセキュリティとプライバシーの特性について分析/説明。 -SAMLSec~ http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf ***Security [#kdc1295a] http://www.oasis-open.org/committees/security/. -SAMLExecOvr --エグゼクティブの概要 --SAMLとその主な利点についてエグゼクティブレベルで簡単に説明(非規範的な文書)。 -SAMLMDV1x~ SAML V1.x OASIS規格をサポートするSAMLエンティティ~ を記述するためのSAML V2.0メタデータ構成体の使用 -SAMLMDExtQ~ クエリ要求者用のSAMLメタデータ拡張 -SAMLProt3P --サードパーティの要求に対するSAMLプロトコルの拡張を定義 --SAMLプロトコルの拡張意図された応答受信者以外のエンティティによる要求を容易にするため -SAMLX509Attr~ X.509認証ベースシステム用のSAML属性共有プロファイル -SAMLXPathAttr~ 属性名としてXPath URIを使用するためのSAML属性の使用をプロファイル -SAMLErrata --正誤表 --SAML準拠ソフトウェアの実装者によって使用される可能性のある解釈へのガイド --SAML V2.0規格の矛盾や不明確である点の解釈を明確化する。 ***WSS [#wd2114df] http://www.oasis-open.org/committees/wss/ -WSS~ Web Services Security: SOAP Message Security 1.1 (WS-Security 2004). -WSSSAML~ Web Services Security: SAML Token Profile 1.1. OASIS WSS-TC, February 2006. ***XML(W3C) [#ce725f0c] -XMLSig~ XML署名の構文と処理~ http://www.w3.org/TR/xmldsig-core/ -XMLEnc~ XML暗号化の構文と処理~ http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/ ***Else [#r47c9a91] -ShibReqs~ Shibbolethの概要と要件~ http://shibboleth.internet2.edu/docs/draft-internet2-shibboleth-requirements-01.html -XACML~ OASIS拡張アクセス制御マークアップ言語(XACML)バージョン2.0~ http://www.oasis-open.org/committees/xacml **参考 [#j9247af2] -OASIS | Advancing open standards for the information society~ https://www.oasis-open.org/ -OASIS (組織) - Wikipedia~ https://ja.wikipedia.org/wiki/OASIS_(%E7%B5%84%E7%B9%94) *SAML XML.org [#ed1566a6] SAML 公式サイト -Online community for the SAML OASIS Standard~ http://saml.xml.org/ -SAML Specifications~ http://saml.xml.org/saml-specifications -SAML Open Source Implementations~ http://saml.xml.org/wiki/saml-open-source-implementations *医療分野共通認証基盤整備コンソーシアム [#dad59934] -SAML 実装仕様書 第 1.0 版~ https://www.keieiken.co.jp/medit/pdf/240423/7-data.pdf --第Ⅰ編 概要、用語及び参考文献 --第Ⅱ編 フレームワーク(SAML) --第Ⅲ編 機能仕様 --第Ⅳ編 実装規約 --第Ⅴ編 試験仕様 --第Ⅵ編 セキュリティとプライバシに関する考慮事項 **用語 [#t3b8e824] |#|用語|説明|h |1|Principal&br;プリンシパル|ID が認証可能なSystem Entity(通常は、ユーザ)。| |2|Subject&br;主体|SAMLアサーションに含まれるプリンシパル| |3|Profile&br;プロファイル|いくつかの目的のひとつのルールの集合。| |4|System Entity&br;システムエンティティ|コンピュータ/ネットワークシステムのアクティブな要素。| |5|Provider&br;プロバイダ|IdPとSPの総称(System Entity)。| |6|Identity Provider(IdP)&br;アイデンティティプロバイダ|プリンシパルの ID 情報を作成、維持、及び管理し、他のサービスプロバイダに契約の範囲でプリンシパルの認証を提供するプロバイダ。| |7|Service Provider(SP)&br;サービスプロバイダ|プリンシパルまたは他のSystem Entityにサービスを提供するプロバイダ。| |8|Attribute Assertion&br;属性アサーション|Subjectの属性に関する情報を伝えるAssertion。| |9|Authentication Assertion&br;認証アサーション|Subjectに対して行われた認証に関する情報を伝達するアサーション。| |10|Authorization Decision Assertion&br;認可決定アサーション|Subjectに対して決定された認可に関する情報を伝達するアサーション。| |11|Security Assertion&br;セキュリティアサーション|セキュリティアーキテクチャのコンテキストで精査されたアサーション。| |12|SAML Authority&br;SAML オーソリティ|Assertionを発行する抽象的なSystem Entity。| |13|Attribute Authority&br;属性オーソリティ|属性アサーションを生成するSystem Entity。| |14|Authentication Authority&br;認証オーソリティ|認証アサーションを生成するSystem Entity。| |15|Session Authority&br;セッションオーソリティ|セッションに関連する状態を保持しているSystem Entityの役割≒IdP。| |16|Party&br;当事者|1つ以上の不特定のプリンシパル。| |17|Asserting Party&br;アサーティングパーティ|形式的には、一つ以上の SAML オーソリティをホストする管理ドメイン。非公式には、そのインスタンス。| |18|Relying Party(RP)&br;当事者|別のSystem Entityからの情報に基づいて動作が決まるSystem Entity。| |19|Policy Enforcement Point(PEP) &br;ポリシー実行点|PDP に認可決定要求を送信し、応答で送信される認可決定アサーションを受け付ける。| |20|Policy Decision Point(PDP)&br;ポリシー決定点|PEP から認可決定要求を受け付けて、応答の認可決定アサーションを生成する。| |21|SAML Requestor&br;SAMLリクエスタ|サービス要求のために SAML プロトコルを利用するSystem Entity| |22|SAML Responder&br;SAMLレスポンダ|サービス要求に応答するために SAML プロトコルを利用するSystem Entity| |23|SAML Artifact&br;SAMLアーティファクト|固定サイズの構造化されたデータオブジェクトで間接参照して SAML プロトコルメッセージを取得する| |24|Front Channel&br;フロントチャンネル|UAなどの仲介者を経由するエンドポイント| |25|Back Channel&br;バックチャネル|UAなどの仲介者を経由しないエンドポイント| **機能概要 [#s75b6881] -ユーザはUA(ブラウザ)を使用して、SP に対してリソース要求を送信する。 -SP は、認証されていないユーザからのリソース要求の場合、~ SP に対する<AuthnReq>のRedirect要求をユーザのUAに返却する。 -ユーザのUAは、SSLで IdPにRedirect要求の<AuthnReq>を転送。 -IdP は、ユーザを認証して認証アサーションを作成、~ 認証アサーションのArtifactのRedirect要求をユーザのUAに返却する。 -ユーザのUAは、Redirect要求のArtifactを SP に転送する。 -SP は、IdP に対して<ArtifactResolve>でArtifactを提示して認証アサーションを要求。 -IdP は、SP に対して<ArtifactResponse>で認証アサーションを応答する。 **[[通信フローの概要>SAMLを実装する。#i6ecd2e5]] [#fe338b0b] *OSSTech [#i952f8dc] **OpenSSO社内勉強会第二回 - SAML - [#d78049dd] https://www.osstech.co.jp/_media/techinfo/opensso/osstech-opensso-study-02-saml.pdf ***概要 [#deef9de1] -SAMLとは --認証情報の送受信の方法を規定する ---フォーマット(XML) ---通信プロトコル --仕様の原文~ http://www.oasis-open.org/specs/index.php から入手可能 ---saml-core-2.0-os.pdf ---saml-bindings-2.0-os.pdf ---saml-profiles-2.0-os.pdf ---saml-authn-context-2.0-os.pdf ---saml-metadata-2.0-os.pdf ---saml-conformance-2.0-os.pdf ---saml-sec-consider-2.0-os.pdf ---saml-glossary-2.0-os.pdf -SSO実現のための準備~ 信頼の輪(Circle of Trust - Cot)の準備 --CoT内のSPに対してのみSSO可能 --IdP-SP間でお互いを事前に登録(CoTを構成) --一つのCoT内に複数のIdPが存在することもある -アカウント連携 --NameIDというユーザ識別子をIdPとSP間で共有 --IdPのアカウントとSPのアカウントを紐付ける --NameIDには以下のものが使用される ---メールアドレス ---ユーザー名 ---ユーザID(GUIDなどの識別子) ---仮名:ランダムな文字列によるユーザ識別 ---X.509のSubject -アカウント・ライフサイクル~ サインイン・サインアウト < 連携・解除 < 作成・削除 -SSOの開始 --CoTの構成・アカウント連携が完了して、SSO可能に --[[OpenID Connect]] の Authorization Code Flow の Tokenリクエストが無い感じ。 ***詳細 [#g8efb8ed] SAMLの構成要素 -アサーション~ IdPが発行するXML形式のユーザに関する証明情報 <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="s2907181983bc6f588aeb045fca183d671224506ec" IssueInstant="2009-11-18T08:28:09Z"> アサーション発行者 アサーションのデジタル署名 アサーションの利用条件 ユーザ識別子(NameID) </saml:Assertion> -プロトコル --認証要求(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> -バインディング --メッセージを既存の通信プロトコルに埋め込む方法を規定 --IdP-SP間の通信有無で分類すると...。 ---無:HTTP Redirect、HTTP POST~ [[OAuth 2.0 Form Post Response Mode]] みたいな~ (SAMLでは、RequestとResponseの両方に適用されるのがポイント) ---有:HTTP Artifact~ アサーションがクライアントに渡ることがない、~ [[OpenID Connect]] の Authorization Code Flow の code みたいな~ ただ、SAML Responseだけでなく、SAML Requestにも使えるので、その辺りが異なる。 -メタデータ --CoTの構成、アカウント連携に必要な情報 --これにより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="https://www.google.com/a/ドメイン名/acs" /> </SPSSODescriptor> </EntityDescriptor> **クラウド時代の シングルサインオン [#bc874894] https://www.osstech.co.jp/_media/techinfo/seminar/hbstudy-20110416-sso.pdf ***概要 [#g7fa118a] -SAML : Secure Assertion Markup Lauguage -認証、認可、ユーザ属性情報などを[[XML]]で送受信するための仕様 -Webアプリの”認証処理”を、外部で代行してもらうための仕組み。 ***用語 [#t41413c4] -SP/IdP --Identity Provider(IdP) ---認証・認可の情報を提供する役割を担う。~ ---IdPで認証されたユーザーは SP のサービスにアクセスできるようになる。 --Service Provider(SP) ---シングルサインオン対象の Web アプリケーションなどを意味する。 ---IdP が発行した認証・認可の情報に応じてクライアントにサービスを提供する。 -トラストサークル(Circle Of Trust)~ --IdP と SP の間で結ばれた信頼関係を意味する。 --シングルサインオンを実現するためには、~ IdP と SP との間で事前に信頼関係を結んでおく必要がある。 --IdP-SP 間でお互いを事前に登録し、&color(red){お互いの証明書を交換する。}; --一つのトラストサークル内に複数の IdP が存在することもある >※同じ言葉でも、他のプロトコルでは意味が違うことがあるので注意 -[[アカウント連携>#deef9de1]] ***シーケンス [#of7ce633] -認証シーケンス --SP-initiated SSO ---ユーザーは最初にSPにアクセスし、IdPでの認証に成功した後に、再びSPにアクセスする。 ---SPがIdPにリクエストする際に、RelayStateというパラメタに遷移先情報を埋め込む。 --IdP-initiated SSO ---ユーザーは最初にIdPにアクセスし、IdPでの認証に成功した後にSPにアクセスする。 ---IdPがSPにアサーションをレスポンスする際に、RelayStateというパラメタに遷移先情報を埋め込む。 -メッセージの送受信方法 --HTTP Redirect / HTTP POST Binding ---IdP-SP間の直接的な通信が発生しない ---ブラウザが通信を中継する(HTTP Redirect/HTTP POST を利用) --HTTP Artifact Binding ---アサーションへのリファレンスである Artifact をブラウザを介してIdPとSPの間で送受信する。~ IdPと SP は Artifact を利用して直接相手に SAML 認証要求/認証応答メッセージを問い合わせる。 ---IdP-SP間の直接的な通信が発生する。 ---Artifact のデータサイズは小さい。 -リソース・アクセス~ リソースが格納されているuriを格納したRelayStateパラメタを使用してリダイレクトする。 ***アサーション [#gb7ace7c] 事前に IdP の証明書を SP に登録しておく必要がある([[JWT]]みたいなもの) <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="s2907181983bc6f588aeb045fca183d671224506ec" IssueInstant="2009-11-18T08:28:09Z"> アサーション発行者 アサーションのデジタル署名 ユーザー識別子(NameID) </saml:Assertion> ***認証要求・認証応答 [#uc6a393c] -認証要求(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> ***ネットワーク構成 [#md96ac81] -IdPを社内LANに設置~ SPへのアクセスを社内のみからに制限することが可能 -IdPをDMZに設置~ 社外からSPにアクセスすることが可能 **OpenAMのSAML利用時の認証方式の指定について [#l06dcf33] https://www.osstech.co.jp/_media/techinfo/openam/saml_authncontext_20150417.pdf ***認証方式の指定 [#e2816212] <AuthnContextClassRef>を使用する。 -SPで、利用するIdPに認証方式を指定する。 --SAML RequestのRequestedAuthnContexを使用して指定する。 ---RequestedAuthnContexは省略可能(多くのSPで使用していない) ---SPはIdPに対して[[Authentication Context>#fcb8eb3c]]を通知できる。 <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="XXXX" Version="2.0" IssueInstant="2015-04-13T04:59:38Z" Destination="xxxxxx" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="XXXXX"> <samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact"> <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest> --RequestedAuthnContextの構成 ---<AuthnContextClassRef>要素~ Authentication Context Classを一つ以上記述 ---Comparison属性~ Authentication Context Classの比較手法を指定~ (exact(既定値)、minimum、maximum、better) -IdPで、SPに実施した認証方式に応答する。 --これにより、SPは、IdPでどのような認証が行われたか判断できる。 --SAML ResponseのAssertionには必須(MUST)の要素 AuthnStatement -> AuthnContext -> AuthnContextClassRef ***OpenAMの実装を把握する [#qcb55eb8] -OpenAMをSPとして構築した場合 --SAML RequestのRequestedAuthnContexにAuthentication Context Classを指定可能 ---既定値では、PasswordProtectedTransportを指定。 ---QueryStringでAuthnContextClassRefを指定することもできる。 ---「|」(パイプ)で区切ることで複数の<AuthnContextClassRef>を指定することが可能 --SAML ResponseとSAML RequestののAuthentication Context Classを比較 ---指定したAuthentication Context Classとマッチしなかった場合はエラー ---デフォルト設定ではPasswordProtectedTransport のみ許容。 ---許容しないAuthentication Context Classの場合も同様のエラー -OpenAMをIdPとして構築した場合 --SAML RequestのAuthentication Context Classを、 ---既定値は、PasswordProtectedTransportとして解釈。 ---デフォルト設定ではPasswordProtectedTransport のみ許容 ---許容しない値の場合はエラー --SAML ResponseのAuthentication Context Classは、~ Assertion -> AuthnStatement -> AuthnContext -> AuthnContextClassRefに指定される。 *Cybozu [#a583f88d] **サイボウズエンジニアのブログ [#b96fa2da] -SAML認証ができるまで - Cybozu Inside Out~ http://developer.cybozu.co.jp/tech/?p=4224 SAMLはSecurity Assertion Markup Languageの略で、OASIS3によって策定された、~ 異なるセキュリティドメイン間で、認証情報を連携するための[[XML]]ベースの標準仕様。 ***用語 [#n5a6bfc5] -認証情報を提供する側を、Identity Provider(IdP) -認証情報を利用する側を、Service Provider(SP) ***仕様 [#ge5ed415] -Core~ 認証情報を表す[[XML]]のスキーマ(Assertions)と、~ メッセージ交換のプロトコル(Protocols)を定義。 -Bindings~ メッセージを実際の通信プロトコル(HTTPなど)にマッピングする方法を定義。 -Profiles~ 特定のユースケースを実現するための組み合わせ方を定義。 --Assertions --Protocols --Bindings -Metadata~ IdPやSPに関する情報を表現するための[[XML]]のスキーマを定義(IdPとSPの信頼関係を構築)。 ***シーケンス [#ada0fdf2] Web Browser SSO Profileのシーケンス -ユーザーがSPにアクセスする -ユーザーが未ログイン状態な場合、SPが認証要求メッセージを生成する -ユーザーがSPから認証要求メッセージを受け取り、それをIdPに送る -IdPが認証要求メッセージを受け取り、ユーザーを認証する -IdPが認証応答メッセージを作成する -ユーザーがIdPから認証応答メッセージを受け取り、それをSPに送る -SPが認証応答メッセージを受け取り、検証する -メッセージの内容に問題がない場合、ユーザーはSPにログインできる ***要件 [#a31dde47] Web Browser SSO Profileの要件 -IdPとの信頼関係の構築機能の設計 --SPに信頼するIdPを登録する。 ---IdPが認証要求メッセージを受け取るURL ---IdPが認証応答メッセージの署名の検証に使用する公開鍵 ---SPからログアウトした後に遷移するURL~ (IdPのログアウト用URLへのリダイレクト) --IdPが信頼するSPの登録~ IdPの管理画面で手動で設定するか、SPが提供するメタデータを読み込む。 ---管理画面で手動で設定~ NameIDFormat要素、AssertionConsumerService要素に相当する情報 ---SPが提供するメタデータを読み込む <md:EntityDescriptor entityID="https://(sub_domain).cybozu.com"> <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified </md:NameIDFormat> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://(sub_domain).cybozu.com/saml/acs" index="0"/> </md:SPSSODescriptor> </md:EntityDescriptor> -メッセージ処理機能の設計 --認証要求メッセージの作成 --認証要求メッセージをIdPに送る ---HTTP Redirect Binding :~ Deflateエンコード -> Base64エンコード -> URLエンコード ---HTTP POST Binding :~ Base64エンコード -> URLエンコード --IdPが発行した認証応答メッセージを受け取る ---HTTP Redirect Binding :~ Deflateエンコード -> Base64エンコード -> URLエンコード ---HTTP POST Binding :~ Base64エンコード -> URLエンコード --認証応答メッセージを検証する ---Version属性の評価 ---<Status>要素の評価 ---<SubjectConfirmation>要素のmethod属性の評価 ---<SubjectConfirmationData>要素の内容の評価 ---<Conditions>要素の評価 ---<AudienceRestriction>要素の評価 ---<Assertion>要素の署名の検証 **cybozu.com ヘルプ [#pc6e3eb9] -SAML認証を使用したシングルサインオンを設定する~ https://jp.cybozu.help/general/ja/admin/list_externalservices/list_saml/saml_settings.html ***SP Initiated な Web Browser SSO Profile [#sf3ea9a0] SAMLリクエストとSAMLレスポンスには、次のバインディングを使用する。 -SAMLリクエスト:HTTP Redirect Binding -SAMLレスポンス:HTTP POST Binding ***フロー [#o46a0b4c] -ユーザがSPにアクセスする。 -SPがSAMLリクエストを生成する。 -ユーザがSPからSAMLリクエストを受け取る。 -IdPがユーザを認証する。 -IdPがSAMLレスポンスを生成する。 -ユーザがIdPからSAMLレスポンスを受け取る。 -SPがSAMLレスポンスを受け取り、検証する。 -SAMLレスポンスの内容に問題がない場合、~ ユーザがSPにログインした状態になる。 ***設定 [#m15838b1] -IdPにSPを登録する --手入力する場合。 ---エンティティID URLの最後に"/"(スラッシュ)をつけないでください。 ---SPのエンドポイントURL ---ユーザーを識別する要素:NameID --メタデータファイルを使用する場合。~ ...。 -SPにIdPを登録する --SPでSAML認証を有効化し、 --SPにIdPの情報を設定。 ---IdPのSSOエンドポイントURL(HTTP-Redirect) ---SPからのログアウト後に遷移するIdPのURL ---IdPが署名に使用する公開鍵の証明書 *Wikipedia [#ha1d962a] **en [#hd81af2f] -Security Assertion Markup Language~ https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language --SAML 1.1~ https://en.wikipedia.org/wiki/SAML_1.1 --SAML 2.0~ https://en.wikipedia.org/wiki/SAML_2.0 --SAML Metadata~ https://en.wikipedia.org/wiki/SAML_Metadata **ja [#re9f6f6f] -Security Assertion Markup Language~ https://ja.wikipedia.org/wiki/Security_Assertion_Markup_Language ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:SAML]]