Para que é utilizado o formato NameID diferente?
no ficheiro de meta-dados SAML existem vários formatos Nomeid definidos, por exemplo:
<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>
4 answers
Ver a secção 8.3 deste SAML core pdf da especificação Oasis SAML.
O SP e o IdP comunicam-se normalmente sobre um assunto. Esse assunto deve ser identificado através de um identificador de nome , que deve estar em algum formato, de modo que seja fácil para a outra parte identificá-lo com base no formato.
Todos estes
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
São o formato dos identificadores de nomes.
Transitório é para[Secção 8.3.8 do núcleo de SAML]
Indica que o conteúdo do elemento é um identificador com semântica transitória e deve ser tratada como uma opaca e temporária valor pelo grupo de confiança.
Não especificado pode ser utilizado e depende puramente da implementação das entidades por vontade própria.
- identificadores persistentes -
O IdP fornece os identificadores persistentes, são usados para ligar às contas locais no SPs, mas identificam-se como o perfil de utilizador para o específico servir cada um sozinho. Por exemplo, os identificadores persistentes são como : johnForAir, jonhForCar, johnForHotel, todos eles por um serviço especificado, uma vez que é necessário ligar para a sua identidade local no serviço.
- identificadores transitórios -
Identificadores transitórios são o que o IdP diz ao SP que os usuários na sessão foram concedidos para acessar o recurso em SP, mas as identidades dos usuários não oferecem ao SP realmente. Por exemplo, a afirmação como "Anonymity (Idp não diz a SP quem ele é) tem a permissão para acessar /resource on SP". O SP conseguiu-o e deixou o browser aceder-lhe, mas ainda não sabe o nome verdadeiro do anonimato.
- identificadores não especificados -
A explicação para isso na especificação é "a interpretação do conteúdo do elemento é deixada para implementações individuais". O que significa que o IdP define o formato real para ele, e assume que o SP sabe como processar os dados do formato responder do IdP. Por exemplo, IdP dá um formato de dados "UserName=XXXXX Country = US", SP obter a afirmação, e pode analisá-la e extrair o nome de usuário é"XXXXX".
É apenas uma dica para o prestador de Serviços sobre o que esperar do NameID devolvido pelo Fornecedor de identidade. Pode ser:
unspecified-
emailAddress– por exemplo[email protected] -
X509SubjectName- por exemploCN=john,O=Company Ltd.,C=US -
WindowsDomainQualifiedName- por exemploCompanyDomain\John -
kerberos- por exemplojohn@realm - Este é usado para identificar entidades que fornecem serviços baseados no SAML e parece um URI.
-
persistent-trata-se de um identificador específico de serviço opaco que deve incluir um valor pseudo-Aleatório e não deve ser rastreável para o usuário real, de modo que este é um recurso de Privacidade. -
transient- identificador opaco que deve ser tratado como temporário.
1 e 2 são SAML 1.1 porque esses URIs faziam parte do padrão Oasis SAML 1.1. A secção 8.3 do PDF linked para a norma Oasis SAML 2.0 explica o seguinte:
Sempre que possível, é utilizada uma urna existente para especificar um protocolo. No caso dos protocolos IETF, a urna do RFC mais atual que especifica o protocolo é usada. As referências URI criadas especificamente para o SAML têm uma das seguintes hastes, de acordo com a versão do conjunto de especificações em que eles foram introduzidos pela primeira vez:
urn:oasis:names:tc:SAML:1.0: urn:oasis:names:tc:SAML:1.1: urn:oasis:names:tc:SAML:2.0: