SAML 2.0設定: MetadataとNo- Metadata

この記事では、2つのSAML 2.0フェデレーション・サーバー間で信頼を確立する際にSAML 2.0 Metadataを使用するメリットについて説明しています。URL、証明書を入力/コピー/貼り付けて、情報を手動で入力したり入力したりするのとは異なります。

信頼の構築

SAML 2.0 WebSSOのコンテキストでの信頼の確立は、フェデレーションSSO操作を実行できるように、SAML 2.0 IDプロバイダおよびSAML 2.0サービス・プロバイダを構成する行為です。

信頼を確立するには、次の手順に従います。

次の情報を使用してリモート・サービス・プロバイダを表すSAML 2.0アイデンティティ・プロバイダでのパートナ・エントリの作成
SPを参照する一意の識別子であるSPの EntityIDまたは ProviderID
IdPがSAMLアサーションを使用してユーザーをリダイレクトするアサーション・コンシューマService URL
それぞれに異なるURLと異なるバインディング(urn:oasis:names:tc:SAML:2.0:bindings:HTTPArtifact、urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST、urn:oasis:names:tc:SAML:2.0:bindings:PAOSなど)がある場合があります。
SAML 2.0ログアウト交換中にIdPがユーザーをリダイレクトするログアウト・サービスURL
各バインディングが異なる場合があります(urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect、urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POSTなど)。
サービスごとに、LogoutRequestメッセージおよびLogoutResponseメッセージを受信するURLが異なる場合があります。
送信SAML 2.0メッセージ(AuthnRequestなど)に署名するためにSPが使用する秘密キーに対応するX.509証明書。
LogoutRequest/LogoutResponseまたはArtifactResolveメッセージ
SSOレスポンス内のアサーション/NameID/Attribute要素などの証明書を使用してリモートIdPsによって暗号化された受信SAML 2.0メッセージを復号化するためにSPが使用する秘密キーに対応するX.509証明書
次の情報を使用してリモート・アイデンティティ・プロバイダを表すSAML 2.0サービス・プロバイダでのパートナ・エントリの作成
IdPを参照する一意の識別子であるIdPのEntityIDまたはProviderID
SPがSAML AuthnRequestでユーザーをリダイレクトするシングル・サインオン・サービスURL
それぞれに異なるURLと異なるバインディング(urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect、urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST、urn:oasis:names:tc:SAML:2.0:bindings:SOAPなど)がある場合があります。
SAML 2.0ログアウト交換中にSPがユーザーをリダイレクトするログアウト・サービスURL
各バインディングが異なる場合があります(urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect、urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POSTなど)。
サービスごとに、LogoutRequestメッセージおよびLogoutResponseメッセージを受信するURLが異なる場合があります。
IdPが発信SAML 2.0メッセージ(アサーション、LogoutRequest/LogoutResponse、ArtifactResponseメッセージなど)に署名するために使用する秘密キーに対応するX.509証明書
(s)を使用してリモートSPによって暗号化された受信SAML 2.0メッセージを復号化するためにIdPによって使用される秘密キーに対応するX.509証明書(ログアウト・リクエスト内のNameID要素など)

前述のものでは、フェデレーションSSOの設定のみを取り上げています。フェデレーション・パートナが他のサービス(属性権限や属性要求者など)をサポートしている場合は、より多くのサービスURLおよび証明書情報を交換する必要があります。

手動プロセス

ご覧のとおり、フェデレーション・サーバーの管理を担当する管理者間で多くの情報が交換される場合があります。マイナー・エラーにより、フェデレーション契約が正しく設定されず、ランタイム・エラーが発生する可能性があります。

手動による信頼の確立が原因で発生する可能性があるエラーは、次のとおりです。

不正な証明書が使用されています
Service URL/バインディングの組合せが正しくありません。たとえば、アーティファクト・バインディングにのみ使用されるアサーション・コンシューマService URLがHTTP- POSTバインディングに使用されます
URLのTypo
サービスURLにホスト名を不正に指定: フェデレーションSSO操作中にCookieが使用されるためです。フェデレーション・サーバーへのアクセスにユーザーが使用するパブリック・エンドポイントである、同じ完全修飾ホスト名を使用することがプライマリです。(IPアドレスまたは完全修飾されていないホスト名ではエラーが発生します)
ProviderIDsのTypo
URLがありません

これらのエラーは、次の結果になります。

不正な証明書を使用した場合の署名検証または復号化の失敗サーバーがエラーをスローする理由
- 証明書が無効です
- 実行される機能のURLがありません(ログアウトURLがないなど)
- 整合性のないホスト名が使用されました(完全修飾とIPアドレスと完全修飾なし) ProviderIDが不明です(入力が原因)。
- 一貫性のないホスト名が使用されているため、無限ループ

前述のエラーは、ユーザーが想定するよりも多く発生し、フェデレーションSSOが正しく動作しない理由(フェデレーション・トラスト確立の誤りを指す)を追いかけるのに時間がかかります。

SAML 2.0 Metadataの使用

SAML 2.0仕様では、リモート・パートナとのフェデレーション操作を実行するためにサーバーが対応するすべての情報を格納するMetadataドキュメントが定義されています。

この情報は次のとおりです。

サービスURL
サービスのSAMLバインディング
署名および暗号化操作の証明書
署名されるメッセージ(AuthnRequest、アサーション)
フェデレーション・サーバーでサポートされるロール(IdP、SP、属性権限...)

SAML 2.0 Metadataは、通常、フェデレーション・サーバー自体によって生成され、パートナのフェデレーション・サーバーによって使用されます。そのため、このドキュメントを作成して使用するための手動介入は行われず、潜在的なエラーの数が減少します。

SAML 2.0 Metadataを使用すると、次の利点があります。

すべての情報は1つのドキュメントに含まれます
ドキュメントはフェデレーション・サーバーによって生成および消費されます(署名は改ざんを防止するために使用できます)
情報が省略されていません
データに一貫性があります(すべてのURLで同じホスト名が使用されています)

さらに重要なことは、フェデレーション・トラスト確立時のミスの可能性を低減することで時間を節約できるため、後でランタイム・エラーが発生する可能性が少なくなります。

その他の学習リソース

docs.oracle.com/learnで他のラボを探すか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。

タイトルおよび著作権情報

SAML 2.0 Setup Metadata vs No Metadata

F61884-01

September 2022