IDプロバイダーとしてOktaを使用するSAML 2.0サービスプロバイダーを実装しています。アサーションコンシューマサービス(ACS)URLを構成して、サービスプロバイダーアプリのSAML 2.0がアサーションに反映されるようにします。
ただし、OktaアイデンティティプロバイダーがOkta構成で構成されたSSOエンドポイントを代わりに送信し、実際に送信されたACSを無視することに気付きました。また、ACSがSPからメタデータと一致しません。
ACS URLが短いIDをIDPに送信してアサーションに反映する正しい方法ではない場合、この目的に使用できる他のメカニズムはどれですか。
例:
SPアプリによって送信されるSAML 2.0 SAMLRequestは次のとおりです。
assertion_consumer_service_url:https://Host.com:port/saml/consume? entityId = N&myName = username
IDプロバイダーの構成にはメタデータがあります。
シングルサインオンURL:https://Host.com:port/saml/consume?entityId=N
MyNameはリクエストごとに変更されることに注意してください。これは、送信されている元のユーザー名と一致するname_idがレスポンスに含まれていることを確認するための方法です。
また、サービスプロバイダーがSPが管理する名前(ユーザー名など)をIDプロバイダーにアサートさせる方法がある場合、それは私たちのニーズに適しています。これをどのように指定しますか?
ありがとう
SAMLでは、ACSはSPに対して静的であると想定されています。応答を発信元のAuthnRequestと関連付けるには、発信AuthnRequestのIDを保存してから、受信した応答のInResponseTo
を使用する必要があります。
SPは、AuthnRequestにサブジェクトを追加して、認証するユーザー名をIdPに伝えることができます。これは SAML2コア仕様 のセクション3.4.1で定義されています。
Anders Abelが指摘したように、ACSは静的であると想定されています。ただし、開発環境では、異なるテストシステムに対してより動的な応答が必要になる場合があります。
これは、リクエストの属性AssertionConsumerService
を利用して、SSO認証を要求するすべてのSPに応答するために使用するsaml20-sp-remote.phpです。生産には安全ではありません。
simplesamlphp/metadata/saml20-sp-remote.php:
<?php
/**
* SAML 2.0 remote SP metadata for SimpleSAMLphp.
*
* See: https://simplesamlphp.org/docs/stable/simplesamlphp-reference-sp-remote
*/
$acs = \SAML2\Binding::getCurrentBinding()->receive()->getAssertionConsumerServiceURL();
if (!$acs) $acs = 'some_fallback_url';
$metadata['idp_identifier'] = array(
'AssertionConsumerService' => $acs,
'simplesaml.nameidattribute' => 'uid'
);