SAMLメタデータファイルには、次のようないくつかのNameID形式が定義されています。
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
誰がこれらの用途を説明できますか?違いは何ですか?
このセクション8.3を参照してください SAML core pdf oasis SAML specification.
SPとIdPは通常、主題について互いに通信します。そのサブジェクトはNAME-IDentifierを介して識別される必要があります。これは、フォーマットに基づいて相手が識別しやすいように、何らかのフォーマットにする必要があります。
これらすべて
1.urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified [default]
2.urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
3.urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
4.urn:oasis:names:tc:SAML:2.0:nameid-format:transient
名前識別子の形式です。
過渡は[ SAML Core ]のセクション8.3.8の場合
要素のコンテンツが一時的なセマンティクスを持つ識別子であり、依存パーティによって不透明で一時的な値として扱われるべきであることを示します。
未指定も使用できますが、純粋にエンティティの実装に依存します。
これについては http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html を参照できると思います。
Identity Federationユースケースを使用して、これらの概念の詳細を説明します。
IdPは永続的な識別子を提供し、SPのローカルアカウントへのリンクに使用されますが、特定のサービスのユーザープロファイルとしてそれぞれ単独で識別します。たとえば、永続識別子はjohnForAir、jonhForCar、johnForHotelのようなものです。これらはすべて、サービス内のローカルIDにリンクする必要があるため、指定された1つのサービスに対してのみ使用されます。
一時識別子は、セッション内のユーザーがSP上のリソースへのアクセスを許可されていることをIdPがSPに伝えるものですが、実際にはユーザーのIDはSPに提供しません。たとえば、「匿名(IdpはSPが誰であるかを知らない)はSPの/ resourceにアクセスする許可を持っている」というようなアサーション。 SPはそれを取得し、ブラウザにアクセスさせましたが、それでも匿名の本名はわかりません。
仕様での説明は、「要素の内容の解釈は個々の実装に任されています」です。つまり、IdPは実際の形式を定義し、SPがIdPから応答する形式データを解析する方法を知っていることを前提としています。たとえば、IdPは「UserName = XXXXX Country = US」というフォーマットデータを提供し、SPアサーションを取得し、それを解析してUserNameが「XXXXX」であると抽出できます。
これは、IDプロバイダーによって返されるNameIDから何を期待するかについてのサービスプロバイダーの単なるヒントです。かもね:
unspecified
emailAddress
–例[email protected]
X509SubjectName
– e.g. CN=john,O=Company Ltd.,C=US
WindowsDomainQualifiedName
–例CompanyDomain\John
kerberos
–例: john@realm
entity
–これは、SAMLベースのサービスを提供するエンティティを識別するために使用され、URIのように見えますpersistent
–これは不透明なサービス固有の識別子であり、擬似乱数値を含める必要があり、実際のユーザーに追跡可能ではないため、これはプライバシー機能です。transient
–一時的なものとして扱われるべき不透明な識別子。1および2はSAML 1.1です。これらのURIはOASIS SAML 1.1標準の一部であったためです。リンクされたPDF OASIS SAML 2.0標準の場合 のセクション8.3では、これについて説明しています。
可能であれば、既存のURNを使用してプロトコルを指定します。 IETFプロトコルの場合、プロトコルを指定する最新のRFCのURNが使用されます。 SAML専用に作成されたURI参照には、最初に導入された仕様セットのバージョンに応じて、次のいずれかのステムがあります。
urn:oasis:names:tc:SAML:1.0: urn:oasis:names:tc:SAML:1.1: urn:oasis:names:tc:SAML:2.0: