websocket
javascript
api
oidc
Power Automate
Power Automate for desktop 活用事例集! | てじらぼ
ここ読んで業務効率化して楽する!
OpenAMとO365のSAML連携
環境
CentOS7
OpenAM14
※セットアップはカスタムセットアップで実施
手順 4: ユーザーデータストア設定
上記のみ"OpenAM のユーザーデータストア"を選択。他はデフォルト。
手順
①OpenAMインスト
以下を参考
OpenAM 14を最速で構築する10分間クッキング - Qiita
※初期設定からやり直す場合は、以下ディレクトリを削除
/usr/share/tomcat/openam/
②OpenAM設定
以下を参考
【仕事メモ】OpenAM(Ver13) Office365との認証連携(1) - Qiita
【仕事メモ】OpenAM(Ver13) Office365との認証連携(2) - Qiita
※パスワード符号化は以下URLで行う
https://SERVER_URL/openam/encode.jsp
※キーストア設定画面で、"Keystore Type"はJKSを指定。
※レルムは新規に作成。レルムを作成した時のMetadataURLは以下
[ServerURL]/saml2/jsp/exportmetadata.jsp?entityid=[entityID]&realm=/realmname
参考
How do I export and import SAML2 metadata in AM (All versions)? - Knowledge - BackStage
例) レルムがo365、ServerURLがhoge.comの場合
https://hoge.com/openam/saml2/jsp/exportmetadata.jsp?entityid=https%3A%2F%2Fhoge.com%3A443%2Fopenam&realm=/o365
※O365のメタデータファイルは、Extensionsタグも削除する。削除しない場合、以下エラーとなる。
Unexpected element {urn:oasis:names:tc:SAML:2.0:metadata}:Extensions
O365メタデータが規約に準拠してない為と想定される。Extensionsタグの順番がおかしい。
https://www.oasis-open.org/committees/download.php/51890/SAML%20MD%20simplified%20overview.pdf
⭐️超重要⭐️
参考URLの"エンティティプロバイダの設定変更"→"NameID の書式リスト"に以下設定をしてるが、誤りと想定される。
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent=employeeNumber
正しくは、"NameID値マップ"と想定される。(後述)
NameIDはSAML認証において、認証対象のユーザーを特定するもの。
SAMLレスポンスのNameIDタグの値になる。
O365と連携する場合、この値がO365上のユーザー属性であるImmutableIDと合致する必要がある。
NameIDのフォーマットは複数あり、どれを利用するか?は、SAMLレスポンスのNameIDタグのFormat属性で指定される。IdP・SP双方が対応してるフォーマットである必要あり。
O365の場合は、以下フォーマットを指定する必要あり。
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
"NameID値マップ"機能で、データストア(LDAP)にある任意のユーザー属性をNameIDに指定する事ができる。今回の例ではurn:oasis:names:tc:SAML:2.0:nameid-format:persistent=employeeNumber。
上記の前提を踏まえ、O365とSAML連携する時のOpenAM側の設定は2種類ある。
1) NameID 値マップ機能でデータストアの任意のユーザー属性をNameIDにする。今回の例ではemployeeNumber。
2) データストアに以下属性を登録する。
sun-fm-saml2-nameid-infokey
sun-fm-saml2-nameid-info
値の指定方法は以下URLを参照。この属性の値にNameIDの値を格納する。
https://backstage.forgerock.com/knowledge/kb/article/a83620834
1)の方がシンプルな実装。2)はデータストアに事前に値の格納が必要になる。
1)の方法を採用する場合、SP側のエンティティプロバイダ設定で、"Disable NameID Persistence"にチェックを付ける必要あり。
付けないとIdP Initiated SSOでサインイン成功した場合に、データストアに2)の2属性が書き込まれる為。
※SP Initiated SSOの場合は認証エラーになる。
この動作になる理由は、NameIDフォーマットで指定したpersistentの仕様。
詳細は以下URLを参照。
SAML ~ NameID Format をご紹介 ~ - Qiita
⭐️おまけ⭐️
OpenAMに"NameID値マップ"機能と似た機能で、"属性マッパー"という機能もあり。
これは、NameID値マップと同様に、SAMLパラメタの値を書き換える機能だが、対象がNameIDの属性でなく、SAMLレスポンスに含まれるAttiributeタグの中の属性値を書き換える機能。今回のケースだと
IDPEmail=mail
上記値を設定してるが、理由はO365がAttributeタグにIDPEmail属性を仕様として要求してる為。
属性マッパーを設定することで、SAMLレスポンスのAttributeタグにIDPEmailの属性を追加できる。値はデータストアの該当ユーザーのメールアドレス情報が設定される。
③O365設定 & ユーザー登録
以下を参考
【仕事メモ】OpenAM(Ver13) Office365との認証連携(3) - Qiita
※O365とのフェデレーション設定では以下が要求される。
AzureADのSAML連携メモ - pikesaku’s blog
※PowerShell実行環境がWinSrv2016の場合、AzureADモジュールインスト前に以下対応が必要
You are being redirected...
PowerShellで以下コマンドを実行
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
※ドメインのフェデレーション設定のPowerShellコマンドは以下を参照
Azure AD Connect:シングル サインオンに SAML 2.0 ID プロバイダーを使用する - Azure | Microsoft Docs
Set-MsolDomainAuthentication | Microsoft Docs
※ set-MsolDomainAuthenticationコマンドの一部オプションの意味は以下の通り。(上記URLより説明文を引用)
パラメタ | 意味 |
---|---|
PassiveLogOnUri | The URL that web-based clients will be directed to when signing in to Office 365. |
ActiveLogOnUri | A URL that specifies the end point used by active clients when authenticating with domains set up for single sign-on (also known as identity federation) in Microsoft Office 365. |
IssuerUri | The unique identifier of the domain in the Office 365 identity platform derived from the federation server. |
LogOffUri | The URL clients are redirected to when they sign out of Office 365. |
※O365とのフェデレーション設定ではIssuerに設定する値は、ユニーク(他O365テナントで登録済みだとNG)でないとset-MsolDomainAuthenticationコマンドがエラーになる。これでGW1日無駄にした。泣いてしまいそう。。。。
Set-MsolDomainAuthentication : Unable to complete this action. Try again later. At line:1 char:1 + Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $B ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (:) [Set-MsolDomainAuthentication], MicrosoftOnlineException + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.InternalServiceException,Microsoft.Online.Adm inistration.Automation.SetDomainAuthentication
Set-MsolDomainAuthentication fails when trying to set a domain as federated
④動作確認
IdP InitiatedとSP Initiatedの両方の動きを確認する。
詳細は以下記事を参照。
OpenAMとO365のSAML連携(動作確認) - pikesaku’s blog
AzureADのSAML連携メモ
ポイント
・AzureADのメタデータは以下
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
・NameIDフォーマットは以下
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
・SAMLレスポンスに以下を設定する必要あり。
NameID→Azure AD ユーザーのImmutableID
IDPEmail→Azure AD ユーザーのUPN
・接続アナライザーでテスト可能
Microsoft Remote Connectivity Analyzer
OpenAM管理者ガイドメモ
メモ
2.1. About Authentication in OpenAM
・認証モジュールで認証プロセスを構成する
・複数の認証モジュールを利用して認証チェーンを構成できる。
・各認証モジュールは、4つの基準(Requisite/Sufficient//Required/Optional)のいずれかで継続および失敗のセマンティクスを指定するように構成できる。
・チェーン内の認証モジュールは、承認要求に合格 または不合格のフラグを割り当てることができる。
・認証チェーンを正常に完了するには、少なくとも1つの合格フラグが達成されている必要があり、不合格フラグはあってはならない。
※上記URLより引用
2.2. About Authentication Levels
・各認証モジュールに認証レベルを設定できる。
・認証に成功した場合、セッションが生成され、認証レベルが適用される。
・認証レベルにより、リソースへのアクセス可否を制限できる。
・認証チェーンで合格した認証モジュールの内、最大の認証レベルが適用される。未実行の認証モジュールがある場合、最大の認証レベルが割り当てられないケースがあり得る。設定変更により、認証成功した場合に最大の認証レベルを割り当てるよう変更も可能。
※上記URLより引用
・ユーザーが同時利用できる最大セッション数を定義できる
SAML Tech OverView SAML Architectureメモ
SAMLを理解すべく、SAML Tech OverViewを見てみる。
自分の言葉に置き換えて、ポイントをメモ。
※自分の解釈が間違えてる可能性は大!!
SAML Tech OverView
https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
重要英単語
単語 | 和訳 |
---|---|
assert | 断言する、強く主張する |
statement | 述べること、声明書 |
subject | 対象。※SAMLで認証・認可されるユーザーを示す用法が多いかも。 |
protocol | 手続き、決まりごと・ルール |
4.1 Basic Concepts
- 複数のコンポーネントで構成され、組み合わせにより様々なユースケースに対応できる
- 信頼関係が確立された組織間でID・認証・属性・認可の情報を伝達する
- 情報の転送に使用されるアサーションとプロトコルメッセージの詳細は以下で定義
https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
- コンセプト図
SAML アサーション
IDPがSPに対し送る認証結果や他情報(認可・ユーザー属性等)
主にSPの要求に基づきIDPが発行するが、SPの要求なしでIDPが発行する事もある。※SP-initiated or IDP-initiated
メタデータ
SAML環境のデプロイで利用。
SP/IDP間の構成情報を定義。
SP/IDP間のSAMLバインディング、運用上の役割(IDP、SPなど)、識別子情報、サポートされているID属性、および暗号化と署名のキー情報を含む。
XMLで定義。
詳細は以下参照。
http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
認証コンテキスト(Authentication Context)
SAML環境のデプロイで利用。
IDPによる認証の種類・強度等の情報。
アサーションに含めることで、SPに通知が可能。
SAMLリクエストに含める事で、SPがIDPに認証要件を要求することもできる。
詳細は以下参照。
http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf
4.2. Advanced Concepts
4.2.1. Subject Confirmation
アサーションのサブジェクトとIDPの対応関係を示すことで、アサーションする条件を満たしている事を示す。
SAMLアサーションに任意の数を含める事ができ、そのうち一つを満たす必要がある。
Method属性は以下3つの定義があり、SPが条件を満たすか判断する基準を示す。
項目 | 条件 |
---|---|
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key | SubjectConfirmation要素のSubjectConfirmationData要素に特定のキー情報を含む |
urn:oasis:names:tc:SAML:2.0:cm:bearer | アサーションを保持 |
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches | 他の基準 |
4.3. SAML Components
SAML環境でコンセプトを実現するコンポートネントの説明
Assertions
- IDPがSPに対し通知する処理対象ユーザーの情報(例: 名前、メールアドレス、所属グループ、)。
- 必須、オプション情報がある。通常、以下情報を含む。
1) 対象ユーザーを特定する情報
2) アサーションを検証する条件
3) アサーションステートメント
項目 | 説明 |
---|---|
Authentication statements | 認証に成功した場合に付与される。認証の手段と時間が含まれる。 |
Attribute statements | ユーザーの属性情報。 |
Authorization decision statements | ユーザーが有する資格情報。(認可) |
Protocols
SAMLが定義する要求・応答のルール
項目 | 説明 |
---|---|
Authentication Request Protocol | SAMLリクエストのルール。 ※SAMLリクエスト=Authentication statementsを含むアサーションの要求 |
Single Logout Protocol | シングルログアウト(複数SPから同時ログアウト)のルール。 ユーザーのログアウトやSP/IDPでのタイムアウト・管理者コマンドで開始して良い。 |
Assertion Query and Request Protocol | SPが新規/既存のアサーションを要求するルール。 ※Authentication Request Protocolとの違いは認証に限定してない点? |
Artifact Resolution Protocol | 固定長の小さな値(Artifact)で、SAMLプロトコルメッセージを渡すルール。 Artifact受信者は、このプロトコルを使用し、メッセージ作成者にArtifactの逆参照を要求し、実際のプロトコルメッセージを返す。 SOAP等の同期Bindingが利用される。 ※よく分からない。。。 |
Name Identifier Management Protocol | 認証対象を参照する際に利用する名前識別子のフォーマット・値を変更するルール。 リクエストの発行者はSP/IDPのどちらか。 SPとIDPの間で、この名前識別子の関連付けを終了させる仕組みも提供する。 https://qiita.com/samiii/items/9b14967764d095cc5120 https://www.ibm.com/docs/ja/security-verify?topic=provider-configuring-saml-subject-mapping-attributes 詳細は https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf |
Name Identifier Mapping Protocol | 名前識別子を別のものにマッピングするルール。 あるSPがIDPから、別のSPが使用するユーザーの識別子を要求できるようになる。 ※よく分からない。。。 |
Bindings
SAMLプロトコルメッセージを、どのように伝達するか?を定義。
項目 | 説明 |
---|---|
HTTP Redirect Binding | HTTP redirect(302 response) |
HTTP POST Binding | POSTメソッド。HTMLリクエストボディに値をBase64エンコードして格納 |
HTTP Artifact Binding | Artifactの送受信方法を定義。POST、クエリ文字列の2つあり。 |
SAML SOAP Binding | SOAP1.1 |
Reverse SOAP (PAOS) Binding | マルチステージSOAP/HTTP。 クライアントがSOAPレスポンダーになれる。 ※よく分からない。。。 |
SAML URI Binding | URIを解決することで既存のSAMLアサーションを取得する手段を定義。 ※よく分からない。。。 |
Profiles
ユースケースを実現するSAMLアサーション、プロトコルメッセージ、およびバインディングの組み合わせ・制約を定義
項目 | 説明 |
---|---|
Web Browser SSO Profile | WebブラウザがSAMLリクエスト&レスポンス・アサーションでSSOする方式。SAMLメッセージが、HTTPリダイレクト・POST・Artifact Bindingsの組み合わせにより、どのように伝達されるか定義 |
Enhanced Client and Proxy (ECP) Profile | 特殊なクライアント・プロキシサーバがReverse SOAP or SOAP BindingsでSSOする方式。 |
dentity Provider Discovery Profile | ユーザーが以前にアクセスしたIDPをSPが知る仕組みを定義 |
Single Logout Profile | シングルログアウトを、SOAP・HTTPリダイレクト・POST・Artifact Bindingsで実現する仕組みを定義 |
Assertion Query/Request Profile | SOAPなどの同期バインディングを介し、SAMLクエリ・リクエストでSAMLアサーションを取得する方法を定義 |
Artifact Resolution Profile | SOAPなどの同期バインディングを介し、Artifact Resolution ProtocolでSAMLメッセージを取得する方法を定義 |
Name Identifier Management Profile | Name Identifier Management ProtocolをSOAP・HTTPリダイレクト・POST・Artifact Bindingsで使う方法を定義 |
Name Identifier Mapping Profile | SOAPなどの同期バインディングを介し、Name Identifier Mapping Protocolを使う方法を定義 |
SAML Architecture原文(Google翻訳結果)
4.1 Basic Concepts
SAMLはビルディングブロックコンポーネントで構成されており、これらを組み合わせると、さまざまなユースケースをサポートできます。
コンポーネントは主に、信頼関係が確立されている自律型組織間でのID、認証、属性、および承認情報の転送を許可します。
コアSAML仕様は、この情報の転送に使用されるアサーションとプロトコルメッセージの両方の構造と内容を定義します。
SAMLアサーションは、アサーションパーティが真であると主張するプリンシパルに関するステートメントを伝達します。
アサーションの有効な構造と内容は、SAMLアサーションXMLスキーマによって定義されます。
アサーションは通常、依拠当事者からのある種の要求に基づいて主張当事者によって作成されますが、特定の状況下では、アサーションは一方的な方法で依拠当事者に配信される場合があります。
SAMLプロトコルメッセージは、SAML定義の要求を作成し、適切な応答を返すために使用されます。これらのメッセージの構造と内容は、SAML定義のプロトコルXMLスキーマによって定義されます。
参加者間でSAMLプロトコルメッセージを転送するために低レベルの通信またはメッセージングプロトコル(HTTPやSOAPなど)を使用する手段は、SAMLバインディングによって定義されます。
次に、SAMLプロファイルは、特定のビジネスユースケース(たとえば、WebブラウザSSOプロファイル)を満たすように定義されます。
プロファイルは通常、相互運用可能な方法でビジネスユースケースを解決するために、SAMLアサーション、プロトコル、およびバインディングのコンテンツに対する制約を定義します。
また、プロトコルメッセージやバインディングを参照しない属性プロファイルもあり、多くの一般的な使用環境(X.500 / LDAPディレクトリ、DCEなど)に合わせてアサーションを使用して属性情報を交換する方法を定義します。
次に、SAMLプロファイルは、特定のビジネスユースケース(たとえば、WebブラウザSSOプロファイル)を満たすように定義されます。
プロファイルは通常、相互運用可能な方法でビジネスユースケースを解決するために、SAMLアサーション、プロトコル、およびバインディングのコンテンツに対する制約を定義します。
また、プロトコルメッセージやバインディングを参照しない属性プロファイルもあり、多くの一般的な使用環境(X.500 / LDAPディレクトリ、DCEなど)に合わせてアサーションを使用して属性情報を交換する方法を定義します。
メタデータは、SAMLパーティ間で構成情報を表現および共有する方法を定義します。たとえば、エンティティでサポートされているSAMLバインディング、運用上の役割(IDP、SPなど)、識別子情報、サポートされているID属性、および暗号化と署名のキー情報は、SAMLメタデータXMLドキュメントを使用して表現できます。
SAMLメタデータは、独自のXMLスキーマによって定義されます。
多くの場合、サービスプロバイダーは、ユーザーがIDプロバイダーで認証するときに使用した認証の種類と強度に関する詳細情報を持っている必要があります。 SAML認証コンテキストは、この情報を伝達するためにアサーションの認証ステートメントで使用されます(または参照されます)。
SPは、IdPへの要求に認証コンテキストを含めて、多要素認証などの特定の認証要件のセットを使用してユーザーを認証するように要求することもできます。認証コンテキスト宣言を作成するためのメカニズムを定義する一般的なXMLスキーマと、一般的に使用される認証方法を説明する独自のXMLスキーマを持つSAML定義の認証コンテキストクラスのセットがあります。
4.2. Advanced Concepts
4.2.1. Subject Confirmation
SAMLアサーションには、SubjectConfirmationという要素が含まれる場合があります。 実際には、SubjectConfirmationが言うことは、「これらは、認証エンティティ(アサーションを使用しようとしている人)がそうすることを許可される条件です」です。
アサーションを使用しようとしているエンティティ、つまり「ウィーダー」は、通常はサブジェクトとの関係を暗示することによって、その権利を証明しています。
アサーションには任意の数のSubjectConfirmation要素を含めることができますが、認証エンティティはそのうちの1つを満たす必要があります。
SubjectConfirmation要素は、依拠当事者が、アサーションのサブジェクトと、依拠当事者が通信している当事者との対応を検証するための手段を提供します。
Method属性は、証明書利用者がこの決定を行うために使用する必要がある特定の方法を示します。
SAML 2.0は、SubjectConformation要素のMethod属性に3つの値を定義することにより、3つの異なるセキュリティシナリオを考慮しています。
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
urn:oasis:names:tc:SAML:2.0:cm:bearer
キーの所有者モデルでは、証明書利用者は、SubjectConfirmation要素のSubjectConfirmationData要素に含まれる特定のキー情報の知識を示すことができるすべての当事者がアサーションを使用できるようにします(これにより、内部のサブジェクトとの何らかの関係を主張します)。
ベアラモデルでは、証明書利用者は、アサーションを保持するすべての当事者が(他の制約も満たされていると仮定して)アサーションを使用できるようにします(したがって、内部のサブジェクトとの何らかの関係を主張します)。
送信者保証モデルでは、依拠当事者は、どの当事者がアサーションの使用を許可されるべきかを決定する際に他の基準を使用します(したがって、内部のサブジェクトとの何らかの関係を主張します)。
4.3. SAML Components
このセクションでは、SAML環境でのアサーション、プロトコル、バインディング、およびプロファイルの概念を表す各コンポーネントについて詳しく説明します。
アサーション:SAMLを使用すると、一方の当事者がサブジェクトに関するステートメントの形式でセキュリティ情報をアサーションできます。 たとえば、SAMLアサーションは、サブジェクトの名前が「John Doe」であり、電子メールアドレスがjohn.doe@example.comであり、「engineering」グループのメンバーであると述べることができます。
アサーションには、そのすべてのステートメントに適用される基本的な必須およびオプションの情報が含まれ、通常、アサーションのサブジェクト(存在しない場合は、サブジェクトの確認に使用される証明書など、他の手段で決定されたID)、検証に使用される条件が含まれます。 アサーション、およびアサーションステートメント。
SAMLは、アサーション内で実行できる3種類のステートメントを定義します。
•認証ステートメント:これらは、ユーザーの認証に成功した当事者によって作成されます。
少なくとも、ユーザーの認証に使用される特定の手段と、認証が行われた特定の時刻について説明します。
•属性ステートメント:これらには、サブジェクトに関する特定の識別属性が含まれます(たとえば、ユーザー「JohnDoe」のカードステータスは「Gold」です)。
•承認決定ステートメント:これらは、サブジェクトが実行する資格があることを定義します(たとえば、「JohnDoe」が特定のアイテムの購入を許可されているかどうか)。
プロトコル:SAMLは、いくつかの一般化された要求/応答プロトコルを定義します。
•認証要求プロトコル:プリンシパル(またはプリンシパルに代わって動作するエージェント)が認証ステートメントと、オプションで属性ステートメントを含むアサーションを要求できる手段を定義します。
WebブラウザSSOプロファイルは、SPでユーザーのセキュリティコンテキストを確立するためにアサーションを取得する必要がある場合に、ユーザーをSPからIdPにリダイレクトするときにこのプロトコルを使用します。
•シングルログアウトプロトコル:プリンシパルに関連付けられたアクティブなセッションのほぼ同時のログアウトを可能にするメカニズムを定義します。
ログアウトは、ユーザーが直接開始することも、セッションのタイムアウトや管理者コマンドなどが原因でIdPまたはSPによって開始することもできます。
•アサーションクエリおよび要求プロトコル:SAMLアサーションを取得するための一連のクエリを定義します。このプロトコルの要求フォームは、アサーションIDを参照することにより、既存のアサーションをアサーティングパーティに要求できます。
このプロトコルのクエリ形式は、特定のサブジェクトと目的のステートメントタイプに基づいて、証明書利用者がアサーション(新規または既存)を要求する方法を定義します。
•アーティファクト解決プロトコル:アーティファクトと呼ばれる小さな固定長の値を使用して、参照によってSAMLプロトコルメッセージを渡すことができるメカニズムを提供します。
アーティファクト受信者は、アーティファクト解決プロトコルを使用して、メッセージ作成者にアーティファクトの逆参照を要求し、実際のプロトコルメッセージを返します。
アーティファクトは通常、1つのSAMLバインディング(HTTPリダイレクトなど)を使用してメッセージ受信者に渡されますが、解決の要求と応答は、SOAPなどの同期バインディングを介して行われます。
•名前識別子管理プロトコル:プリンシパルを参照するために使用される名前識別子の値または形式を変更するメカニズムを提供します。
リクエストの発行者は、サービスプロバイダーまたはIDプロバイダーのいずれかです。このプロトコルは、IDプロバイダーとサービスプロバイダー間の名前識別子の関連付けを終了するメカニズムも提供します。
•名前識別子マッピングプロトコル:適切なポリシー制御に従って、あるSAML名前識別子を別のSAML名前識別子にプログラムでマッピングするメカニズムを提供します。これにより、たとえば、あるSPがIdPから、アプリケーション統合シナリオでSPが別のSPで使用できるユーザーの識別子を要求できるようになります。
バインディング:SAMLバインディングは、さまざまなSAMLプロトコルメッセージが基盤となるトランスポートプロトコルを介してどのように伝送されるかを正確に示します。
SAMLV2.0で定義されているバインディングは次のとおりです。
•HTTPリダイレクトバインディング:HTTPリダイレクトメッセージ(302ステータスコード応答)を使用してSAMLプロトコルメッセージを転送する方法を定義します。
•HTTPPOSTバインディング:HTMLフォームコントロールのbase64でエンコードされたコンテンツ内でSAMLプロトコルメッセージを転送する方法を定義します。
HTTPアーティファクトバインディング:アーティファクト(上記のアーティファクト解決プロトコルで説明)が、HTTPを使用してメッセージ送信者からメッセージ受信者に転送される方法を定義します。
HTMLフォームコントロールまたはURLのクエリ文字列の2つのメカニズムが提供されます。
•SAMLSOAPバインディング:SAMLプロトコルメッセージがSOAP 1.1メッセージ内で転送される方法を定義し、SOAPoverHTTPの使用に関する詳細を示します。
•リバースSOAP(PAOS)バインディング:HTTPクライアントがSOAPレスポンダーになることを許可するマルチステージSOAP/HTTPメッセージ交換を定義します。
拡張クライアントおよびプロキシプロファイルで使用され、IDP検出を支援できるクライアントおよびプロキシを有効にします。
•SAMLURIバインディング:URI(URI(URI(Uniform Resource Identifier))を解決することにより、既存のSAMLアサーションを取得する手段を定義します。
プロファイル:SAMLプロファイルは、SAMLアサーション、プロトコル、およびバインディングを組み合わせて制約し、特定の使用シナリオでの相互運用性を高める方法を定義します。これらのプロファイルの一部については、このドキュメントの後半で詳しく説明します。 SAMLV2.0で定義されているプロファイルは次のとおりです。
•WebブラウザーSSOプロファイル:SAMLエンティティが認証要求プロトコルとSAML応答メッセージおよびアサーションを使用して、標準のWebブラウザーでシングルサインオンを実現する方法を定義します。これは、メッセージがHTTPリダイレクト、HTTP POST、およびHTTPアーティファクトバインディングと組み合わせてどのように使用されるかを定義します。
•拡張クライアントおよびプロキシ(ECP)プロファイル:特殊なクライアントまたはゲートウェイプロキシがReverse-SOAP(PAOS)およびSOAPバインディングを使用できる特殊なSSOプロファイルを定義します。
•IDプロバイダー検出プロファイル:ユーザーが以前にアクセスしたIDプロバイダーについてサービスプロバイダーが学習するための1つの可能なメカニズムを定義します。
•シングルログアウトプロファイル:SAMLシングルログアウトプロトコルをSOAP、HTTPリダイレクト、HTTP POST、およびHTTPアーティファクトバインディングで使用する方法を定義します。
•アサーションクエリ/リクエストプロファイル:SAMLエンティティがSAMLクエリおよびリクエストプロトコルを使用して、SOAPなどの同期バインディングを介してSAMLアサーションを取得する方法を定義します。
•アーティファクト解決プロファイル:SAMLエンティティがSOAPなどの同期バインディングを介してアーティファクト解決プロトコルを使用して、アーティファクトによって参照されるプロトコルメッセージを取得する方法を定義します。
•名前識別子管理プロファイル:名前識別子管理プロトコルをSOAP、HTTPリダイレクト、HTTP POST、およびHTTPアーティファクトバインディングで使用する方法を定義します。
•名前識別子マッピングプロファイル:名前識別子マッピングプロトコルがSOAPなどの同期バインディングを使用する方法を定義します。
4.4. SAMLXMLコンストラクトと例
このセクションでは、いくつかの主要なSAMLXML構成の説明と例を示します。