説明するADFSクレームルール

Question

SAML 2を使用するためにSSOを使用するクライアントが多数あります。クライアントの多くはOkta、PingIdentityなどのプロバイダを使用しています。 =

UPNを

は、入力方向の要求

• 着信主張を変換：常に先頭にADFSとの統合を行うと上昇し、エラー、その後、彼らは彼らの側に以下の設定でこの問題を修正します

  発信クレーム=名前ID

• 発信名前IDフォーマット=メール

たちは、SAML REPONSEで見たのエラーではなく、私たちがこれを見、彼らは名前IDを送信しないということです。

<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester"><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></samlp:StatusCode></samlp:Status> 

これはただADFSの統合で起こっている、と私は何をすべきかを知りたいです私はこのエラーを過小評価し、ADFSを使用する私の次のクライアントに説明するために、ADFSに関するクレームルールについて知っています。

Answer 1

これはTransformクレームルールです。

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat> 
     <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> 
     <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat> 

これらは許さ名前ID形式：クライアントのメタデータで

、あなたのようなものが表示されるはずです。

発信NameID形式は、これらのいずれかである必要があります。

Incoming claim = Email 

Outgoing Claim = NameID 

Outgoing name ID format = Email 

上記のように、通常の電子メールLDAPルールと変換ルールが最初にあります。