Ir para o conteúdo

Provedor de segurança SAML no Jitterbit App Builder

A autenticação SAML Single Sign-On (SSO) é definida nos seguintes documentos:

Em um cenário de SSO, existem três funções:

  • Principal - O usuário que acessa um serviço restrito.
  • Service Provider (SP) - Fornece acesso a serviços restritos.
  • Identity Provider (IdP) - Autentica usuários.

O App Builder pode ser configurado como SP ou IdP usando o provedor de segurança apropriado. Este documento aborda o provedor de segurança SAML, utilizado para a função de SP. Nessa função, o App Builder delega a autenticação a um IdP de terceiros. Os IdPs suportados incluem:

Para a função de IdP, consulte o provedor de identidade SAML.

Fluxos

A especificação SAML Single Sign-On (SSO) define vários fluxos. O provedor de segurança SAML suporta os seguintes fluxos SAML SSO:

  • Iniciado pelo Service Provider (SP)
  • Iniciado pelo Identity Provider (IdP)

Service provider (SP) iniciado

No fluxo iniciado pelo Service Provider (SP), um usuário navega até o App Builder e tenta acessar uma página restrita. O App Builder redireciona o usuário para o Identity Provider (IdP) por meio da vinculação SAML Redirect (HTTP GET). Após autenticação, o IdP redireciona o usuário de volta para o App Builder usando a vinculação SAML Post (HTTP POST). O App Builder valida a SAML Response, mapeia o identificador de nome para uma conta de usuário local do App Builder e concede os direitos associados à conta do usuário.

Observe que, antes de redirecionar o usuário para o IdP, o App Builder registra a URL da página que o usuário tentou acessar. Após autenticação, o App Builder redireciona o usuário de volta para a página originalmente solicitada. Isso permite deep linking.

Identity provider (IdP) iniciado

No fluxo Identity Provider (IdP), um usuário navega diretamente para o IdP. Após autenticação, o usuário é redirecionado para o App Builder por meio da vinculação SAML Post (HTTP POST). Assim como no fluxo iniciado por SP, o App Builder valida a SAML Response, mapeia o identificador de nome para uma conta de usuário local do App Builder e concede os direitos associados à conta do usuário.

Normalmente, o App Builder redireciona o usuário para sua página inicial após o login bem-sucedido. No entanto, o IdP pode realizar um deep link passando a URI no parâmetro SAML Response RelayState. Consulte o parâmetro AllowRelayStateRedirects abaixo.

Configuração

Tokens

  • Issuer: O emissor da asserção SAML. Assume como padrão a audiência.
  • Audience: Restrição de audiência da asserção SAML. O valor deve ser uma URI sintaticamente válida.
  • Recipient: O destinatário da asserção SAML. Este valor deve ser uma URI sintaticamente válida. Assume como padrão a URI do Assertion Consumer Service (por exemplo, https://example.com/Vinyl/signin-SAML).

Cuidado

Por razões de compatibilidade, Audience assume como padrão a URL raiz da aplicação (por exemplo, https://example.com/Vinyl/). É altamente recomendável que você defina explicitamente Audience em vez de depender do padrão.

Endpoints

Tipo Descrição
Metadata Endpoint Endpoint de metadados do serviço SAML Single Sign-On (SSO). Este parâmetro é obrigatório se os parâmetros Request Redirect Endpoint ou SigningCertificate forem indefinidos.
RelayState URI URI de redirecionamento RelayState permitida para uma solicitação iniciada pelo Identity Provider (IdP) SAML. Consulte o parâmetro AllowRelayStateRedirects para obter informações adicionais.
Request Redirect Endpoint Endpoint de solicitação de autenticação SAML Single Sign-On (SSO) para a vinculação Redirect. Este parâmetro é obrigatório se o Metadata Endpoint for indefinido.

Certificados

Finalidade Tipo Formato Descrição
Validação de Assinatura Certificado X.509
  • PEM (CERTIFICATE)
  • PKCS#12 (PFX), codificado em base64
Certificado X.509 usado para validar assinaturas de resposta SAML Single Sign-On (SSO).

O certificado de validação de assinatura é obrigatório se o Endpoint de Metadados não estiver definido.

Propriedades

O provedor de segurança SAML define os seguintes parâmetros adicionais:

Parâmetro Padrão Descrição
AllowRelayStateRedirects False Indica se um logon iniciado por um Provedor de Identidade (IdP) SAML pode incluir um URI de redirecionamento no parâmetro RelayState. O URI de redirecionamento é o local para o qual o usuário será redirecionado após fazer logon.

Por padrão, o parâmetro RelayState não pode conter um URI de redirecionamento. Defina como True para permitir URIs de redirecionamento no parâmetro RelayState.

Para proteger contra ataques de retransmissão aberta, o URI deve corresponder ao endpoint RelayState URI.
IgnoreTlsErrors False Indica se o App Builder deve ignorar erros de certificado HTTPS ao fazer solicitações de back-channel para recuperar os metadados do serviço.

Esta configuração é apenas para fins de configuração e teste. Não ative esta configuração em um sistema em execução.
SignatureRequirement AssertionOrResponse Indica se a resposta SAML, asserção ou ambas devem ser assinadas. As opções incluem: - AssertionOrResponse - A asserção ou resposta deve ser assinada. - Assertion - A asserção deve ser assinada. - Response - Apenas a resposta deve ser assinada. A asserção herda a assinatura da resposta. - AssertionAndResponse - Tanto a asserção quanto a resposta devem ser assinadas.
LogPII False Indica que informações de identificação pessoal (PII) devem ser registradas. Esta configuração entra em vigor na inicialização.

Declarações

As asserções SAML contêm atributos. Os atributos são pares chave/valor multivalorados. O App Builder trata os atributos de asserção SAML como declarações. O nome do atributo é mapeado para um identificador de declaração.

Por exemplo, dada uma asserção SAML com o seguinte atributo:

<Attribute AttributeName="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
  <AttributeValue>Arthur.Dent</AttributeValue>
</Attribute>

Mapear o identificador http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name para a propriedade Name definirá o nome de usuário como "Arthur.Dent" quando a conta de usuário for provisionada.

A tabela a seguir descreve os mapeamentos de declaração padrão:

Identificador Finalidade Descrição
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier Identificador de Nome Identificador único e imutável usado para mapear a identidade de terceiros para um usuário do App Builder.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name Nome Nome de usuário.
http://schemas.xmlsoap.org/claims/Group Grupo Associação de grupo de segurança.
http://schemas.zudy.com/identity/claims/fullname Nome Completo Nome completo.
http://schemas.zudy.com/identity/claims/displayname Nome de Exibição Nome amigável.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress Endereço de Email Endereço de email.
http://schemas.zudy.com/identity/claims/phonenumber Número de Telefone Número de telefone.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/thumbprint Impressão digital do certificado X.509.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/x500distinguishedname Nome distinto do certificado X.509.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dns Nome DNS do certificado X.509.

Integração

Serviço de consumidor de asserção

O provedor de segurança SAML expõe um único endpoint. O endpoint recebe Respostas SAML. Isso é conhecido como Serviço de Consumidor de Asserção. Uma URL do Serviço de Consumidor de Asserção do App Builder pode parecer algo assim:

https://example.com/Vinyl/signin-SAML

A URL é composta pelas seguintes partes:

Componente Descrição
https://example.com/Vinyl/ URL absoluta do diretório raiz da aplicação App Builder.
SAML Esquema do provedor de segurança SAML. O valor diferencia maiúsculas de minúsculas. Caracteres especiais precisam ser codificados em URL.

Provisionar usuários

Após configurar o provedor de segurança SAML, você deve garantir que os usuários tenham identidades correspondentes no App Builder para fazer login com sucesso.

Provisionamento manual

Um administrador pode associar manualmente usuários ao provedor de segurança SAML:

  1. Navegue até IDE > Gerenciamento de Usuários.

  2. No painel Identidades, clique em + Identidade para criar uma nova identidade.

  3. Ao configurar a nova identidade, certifique-se de selecionar SAML como o Provedor de segurança e insira o Identificador que corresponde ao nome de usuário do IdP do usuário (normalmente o email ou NameID).

Provisionamento automático

Para lidar com integração em massa de usuários sem entrada manual, você pode ativar o recurso Corresponder Usuário Existente. Isso é útil quando você já tem uma lista de usuários no App Builder e deseja vinculá-los às suas identidades SAML automaticamente no primeiro login.

  1. Navegue até IDE > Provedores de Segurança.

  2. Se seu provedor de segurança SAML já existe, localize-o no painel Autenticação de Usuário e clique duas vezes no ícone de expansão no final de sua linha. Se ainda não existe, clique em + Autenticação de Usuário.

  3. Na tela de configuração que se abre, localize o grupo de campos Provisionamento e ative a caixa de seleção Provisionamento de Usuário. Ao fazer isso, a caixa de seleção Corresponder Usuário Existente aparece. Ative-a.

Após ativar esse recurso, quando um usuário tenta fazer login via SAML, o App Builder verifica se já existe uma conta de usuário local com um nome de usuário que corresponde ao identificador de nome SAML. Se uma correspondência for encontrada, o sistema cria automaticamente o vínculo de identidade para esse usuário durante o processo de login, concedendo acesso imediatamente.

Solução de problemas

Erro "The AudienceRestrictionCondition was not valid because the specified Audience is not present in AudienceUris."

Esse erro indica que o URI de audiência não corresponde. Certifique-se de que a propriedade Audience foi definida explicitamente. Se não for definida, usará como padrão a URL atual, que pode variar por usuário. O valor diferencia maiúsculas de minúsculas.

Problemas conhecidos e limitações

O provedor de segurança de Logon Único (SSO) SAML do App Builder tem as seguintes limitações:

  • Apenas uma única restrição de audiência pode ser validada.
  • O protocolo de resolução de artefato não é suportado.
  • O protocolo de logout não é suportado.