Um provedor de identidade empresarial do SAML

Editar online

Este tópico fornece informações sobre os metadados do ` SAML ` e o mapeamento de atributos de usuário necessários para configurar um provedor de identidade do ` SAML Enterprise`.

SAML é um padrão XML para a troca de informações de autenticação única entre um provedor de identidade, que verifica a identidade do usuário, e um provedor de serviços, que utiliza essas informações de identidade. Em comparação com um provedor de identidade do Cloud Directory, um provedor de identidade do SAML Enterprise é mais complicado de configurar.

Como provedor de serviços, o provedor de identidade do SAML Enterprise:
  1. Delega IBM® Verify a autenticação a um provedor de identidade externo que autentica os usuários. Por exemplo, Microsoft ADFS ou Microsoft Azure AD.
  2. Preenche um Verify token de credenciais do usuário com as informações de identidade do usuário retornadas.
A comunicação entre o provedor de serviços e o provedor de identidade conta com valores que estão contidos em arquivos de metadados. Para habilitar o login único ( SAML ) entre o provedor de identidade do SAML Enterprise e o provedor de identidade externo, o provedor de identidade deve:
  1. Forneça o arquivo de metadados do provedor de identidade SAML 2.0 ao provedor de identidade SAML Enterprise.
  2. Obtenha o arquivo de metadados do provedor de serviços SAML 2.0 do provedor de identidade SAML Enterprise.

Requisitos de metadados SAML

  • O conteúdo dos arquivos de metadados do provedor de serviços e do provedor de identidade deve estar em conformidade com a especificação SAML 2.0.
  • O arquivo de metadados do provedor de identidade deve conter a chave pública do provedor de identidade para permitir que o provedor de identidade do SAML Enterprise valide sua assinatura digital. Os metadados do ` SAML ` devem conter um <KeyDescriptor> elemento `. Exemplo de um elemento <KeyDescriptor> para chaves de assinatura:
    <md:KeyDescriptor use="signing">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>idp.example.com SSO key</X509Certificate>
        </X509Data>
      </KeyInfo>
</md:KeyDescriptor>
  • O arquivo de metadados do provedor de serviços deve conter pelo menos um elemento <md:KeyDescriptor use="signing">. Por Exemplo:
    <md:KeyDescriptor use="signing">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>(...signing certificate...)</X509Certificate>
        </X509Data>
      </KeyInfo>
</md:KeyDescriptor>
  • Se o provedor de identidade do SAML Enterprise estiver utilizando um certificado de CA raiz ou intermediário interno, cada certificado da cadeia precisa conter uma <X509Certificate> stanza. Por Exemplo:
    <KeyDescriptor use="signing">    
     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>...root CA base64 encoded public certificate...</X509Certificate>
          <X509Certificate>...intermediate CA base64 encoded public certificate...</X509Certificate>
          <X509Certificate>...signer base64 encoded public certificate ...</X509Certificate>
        </X509Data> 
     </KeyInfo> 
</KeyDescriptor>
    Atualize os <md:KeyDescriptor use="signing"> elementos e <md:KeyDescriptor use="encryption"> nos metadados do SAML.
    Nota: O certificado no <md:KeyDescriptor use="encryption"> elemento do arquivo de metadados do provedor de serviços pode ser utilizado pelo provedor de identidade externo SAML 2.0 para criptografar e enviar os elementos de asserção SAML2 para Verify.

SAML mapeamento entre asserções e Verify tokens de credenciais

O provedor de identidade do Enterprise do SAML utiliza as informações de identidade do usuário contidas na asserção SAML para preencher:
  • O Verify token de credencial, que representa um usuário autenticado do Verify Connect.

    Ele armazena a identidade do usuário e suas informações sobre o atributo.

  • Uma solicitação de saída do SAML para o aplicativo SaaS.
Tabela 1. SAML mapeamento de asserções e tokens de credenciais
O valor deste elemento de afirmação ` SAML ` É incluído no Verify token de credencial como
<saml:Subject><saml:NameID> preferred_username
<saml:Issuer> realmName, se realmName a reivindicação não estiver explicitamente incluída na asserção SAML.
Nota: Se <saml:Issuer> estiver no formato http(s) URL, o <hostname> no URL é extraído e usado para definir o realmName atributo.

<saml:AttributeStatement>Outras informações de identidade do usuário podem ser incluídas na asserção ` SAML `. O elemento <saml:AttributeValue> suporta somente o tipo de dados de sequência.

Se o <saml:Attribute Name> corresponder a um dos seguintes atributos padrão do diretório Verify na nuvem, o atributo é adicionado ao token Verify de credenciais como um atributo padrão com o mesmo nome:
  • preferred_username
  • given_name
  • family_name
  • name ou displayName
  • email ou emailAddress
  • groups ou groupIds
  • userID
  • realmName
  • mobile_number

Se os <saml:Attribute Name> atributos não corresponderem a nenhum dos atributos padrão do diretório Verify na nuvem, o atributo é adicionado ao Verify token de credenciais como um atributo estendido. Os atributos estendidos têm um prefixo ext:: nos nomes de atributos originais.

A seguir, apresentamos um exemplo de resposta do tipo " SAML ", cuja asserção <saml:AttributeStatement> de atributos contém os atributos emailAddresse mobile_number a serem propagados para o Verify token de credenciais.
<?xml version="1.0"?>
<samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
      xmlns:xs="http://www.w3.org/2001/XMLSchema" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      ID="FIMRSP_549f7c46-014a-195f-b377-f24678dbf88a" 
      IssueInstant="2014-12-16T19:42:25Z" Version="2.0">
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion ID="Assertion-uuid549f74ad-014a-120d-a67b-f24678dbf88a" 
      IssueInstant="2014-12-16T19:42:23Z" Version="2.0">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
         https://idp.example.com/SAML</saml:Issuer>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">testuser
          </saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2014-12-16T19:43:23Z" 
             Recipient="https://sp.iam.ibmcloud.com/SAML"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2014-12-16T19:41:23Z" NotOnOrAfter="2014-12-16T19:43:23Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://sp.iam.ibmcloud.com/SAML</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2014-12-16T19:42:23Z" 
           SessionIndex="uuid549ad19a-014a-1451-8e4d-998e0731058a" 
           SessionNotOnOrAfter="2014-12-16T20:42:21Z">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password
            </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="emailAddress" 
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">testuser@idp.example.com</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="mobile_number" 
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">01234556789</saml:AttributeValue>
      </saml:Attribute>    
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>
O objeto JSON a seguir é um exemplo não normativo do conjunto de atributos de um Verify token de credencial convertido a partir da resposta de autenticação de exemplo SAML. Isso ilustra como a identidade e os atributos do usuário na asserção ` SAML ` são mapeados no token de credenciais.
{
"preferred_username":"testuser",
"realmName": "idp.example.com",
"email":"testuser@idp.example.com",
"ext:mobileNumber": "01234556789"
}