Claims

Os claims são processados primeiro no método de autenticação e depois no registo de aplicação, onde é possível decidir quais os claims que passam para o passo seguinte e executar transformações e tarefas de claims.

Todas as comparações de claims são sensíveis a maiúsculas e minúsculas.

O processo de claims começa no método de autenticação quando um utilizador se autentica. Aí é possível executar transformações e tarefas de claims e configurar quais os claims que têm de ser encaminhados para o passo seguinte. Depois, o processo de claims continua no registo de aplicação, onde também é possível fazer transformações de claims e configurar quais os claims que têm de ser emitidos para a aplicação / API.

Num cenário de Client Credentials Grant, o processo de claims é executado apenas no registo de aplicação. O mesmo acontece com as transformações de claims e com a configuração de quais os claims que têm de ser emitidos para a aplicação / API.

Para valores usados no FoxIDs, escolha _local: para um conjunto de transformações, _internal: para o fluxo de autenticação atual, incluindo as transformações da aplicação, ou _session: para inícios de sessão posteriores no navegador através do mesmo método. Estes claims reservados não são emitidos para as aplicações. Consulte Claims locais, internos e de sessão, incluindo como copiar um valor de sessão para um claim interno utilizável pelas transformações da aplicação.

Método de autenticação

Tanto num método de autenticação OpenID Connect como SAML 2.0, os claims são encaminhados ao adicioná-los à lista Forward claims. Todos os claims são encaminhados se um wildcard * for adicionado à lista Forward claims.

Os claims seguintes identificam o último método de autenticação utilizado. São encaminhados por predefinição e podem ser lidos no registo de aplicação e usados em transformações e tarefas de claims:

  • auth_method contém o nome do método de autenticação, que é único no ambiente.
  • auth_method_type contém o tipo de método de autenticação: login, oidc, oauth2, saml2, wsfed, env_link ou ext_login.
  • auth_profile_method contém o nome do perfil selecionado do método de autenticação. Este claim é incluído quando é utilizado um perfil.

Um claim sub e os tokens recebidos de um Identity Provider externo ficam aninhados com um símbolo pipe (|) após o nome do método de autenticação. Exemplos:

  • Um sub externo com o valor afeda2a3-c08b-4bbb-ab77-35138dd2ef2d passa a ter o valor aninhado the-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d
  • Um access token externo com o valor eyJhG.cRwczov...nNjb3B.lIjoi é adicionado no claim access_token com o valor aninhado the-auth-method|eyJhG.cRwczov...nNjb3B.lIjoi
  • Se o OpenID Provider externo devolver um refresh token, este pode ser encaminhado no claim refresh_token com o valor aninhado the-auth-method|refresh-token-value

Registo de aplicação

Tanto num registo de aplicação OpenID Connect, OAuth 2.0 como SAML 2.0, os claims são emitidos para a aplicação / API ao adicioná-los à lista Issue claims. Todos os claims são emitidos para a aplicação / API se um wildcard * for adicionado à lista Issue claims.

Um registo de aplicação OpenID Connect pode diferenciar se um claim é emitido apenas no access token ou também no ID token.

Um registo de aplicação OpenID Connect e OAuth 2.0 também pode encaminhar claims através de um scope. Isto é feito adicionando o claim ou claims à lista Voluntary claims de um scope. Os claims são depois emitidos se a aplicação cliente pedir esse scope. Um registo de aplicação OpenID Connect também pode diferenciar, nos voluntary scope claims, se um claim é emitido apenas no access token ou também no ID token.

Tipos de valores dos claims

Os tipos dos valores de claims JWT, incluindo objetos JSON, arrays, booleanos e números, são preservados quando os claims são copiados por uma transformação Map ou transmitidos através de sessões, Extended UI e grants OAuth. O OpenID Connect UserInfo devolve estes valores com os tipos JSON correspondentes.

As transformações que produzem texto novo, como o mapeamento regex e a concatenação, produzem valores de cadeia de caracteres.

O mapeamento de claims JWT/SAML preserva tipos de valores como booleanos e números. No mapeamento de JWT para SAML, os valores JSON são transmitidos como texto em atributos de cadeia de caracteres. No mapeamento de SAML para JWT, cadeias que contêm objetos ou arrays JSON válidos tornam-se claims JSON.

Identidades personificadas

Um método de autenticação pode selecionar outro utilizador com uma transformação Impersonation. As transformações da aplicação recebem então os claims do target e um claim act que identifica o utilizador autenticado original. Os claims _impersonate: preparam a seleção nas transformações do método de autenticação; os claims auxiliares locais mantêm os seus nomes reservados sob este prefixo.

Nos JWT, act é um objeto JSON, por exemplo {"sub":"original-user"}. O seu mapeamento SAML predefinido é http://schemas.foxids.com/ws/identity/claims/act, que pode ser substituído nos mapeamentos de claims do ambiente. Selecione o claim mapeado em Issue claims da aplicação SAML, ou use *, para emitir o respetivo texto JSON. Quando um atributo SAML com este texto JSON é mapeado novamente para act, o FoxIDs emite-o como objeto JSON no JWT.

Claims protegidos

O FoxIDs gere claims que controlam as sessões, a validade dos tokens e o encaminhamento entre métodos de autenticação. Estes claims protegidos não podem ser configurados como saídas de transformações de claims, utilizados em mapeamentos personalizados de claims JWT/SAML ou associados a valores estáticos.

Os nomes dos claims JWT protegidos são:

  • sid, iss, aud, exp, nbf, iat e auth_time.
  • client_id, azp, scope, nonce, at_hash e c_hash.
  • auth_method, auth_method_type, auth_profile_method e auth_method_issuer.

Os tipos de claims SAML correspondentes ao índice de sessão, ao instante de autenticação, ao ID do cliente e ao método de autenticação também estão protegidos. Os mapeamentos de protocolos integrados no FoxIDs continuam disponíveis.

As transformações podem ler claims protegidos e copiar os respetivos valores para claims personalizados. Um claim protegido também pode ser selecionado numa lista de claims a encaminhar ou emitir sem fornecer valores estáticos.

As mesmas restrições aplicam-se aos claims personalizados de utilizadores internos e externos, aos claims iniciais do utilizador do tenant, aos claims dos nós da estrutura de acesso, aos claims de saída da interface de utilizador dinâmica e aos claims estáticos de aplicações e scopes.

Os claims protegidos devolvidos por uma Claims API, uma API de validação de Extended UI, uma External Login API ou uma Directory Connector API são descartados. Os claims protegidos existentes no fluxo são mantidos. Os claims protegidos selecionados podem ser enviados a estas API como entrada.