Mapeamento de solicitação do OpenID Connect para solicitações de consentimento

Editar online

O fluxo de autorização OAuth e OpenID Connect pode apresentar aos usuários um prompt de consentimento que solicita autorização.

Os fluxos de autorização podem solicitar autorização para executar as ações a seguir.
  • Compartilhar dados do perfil do usuário, como o endereço de e-mail. Essa solicitação pode, opcionalmente, ser complementada com informações que indicam o propósito para o qual os dados estão sendo compartilhados.
  • Executar ações em nome do usuário, como iniciar o veículo do usuário e aquecer durante um dia frio ou iniciar um pagamento.
Normalmente, os aplicativos solicitam a ação por meio do scope parâmetro. No entanto, às vezes, pode ser necessário modificar a solicitação. Por exemplo,
  • Verifique sempre o status da autorização do usuário no contrato de licença do usuário.
  • Filtre valores de scope específicos com base na sessão de autenticação do usuário.
  • Inclua mais contexto que indique por que os dados estão sendo solicitados, se isso é codificado dentro do scope (exemplo,email_for_billing) ou está disponível como parte de outro parâmetro de solicitação (como authorization_details).

Esse tipo de modificação pode ser obtido com o uso da regra customizada do parâmetro de solicitação de consentimento. Consulte r_attr_functions.html. A regra pode ser gravada usando uma linguagem simples de expressão de linha única ou como um documento baseado em YAML multilinhas mais avançado. Consulte Executor de regras multilinhas.

Objetos de entrada disponíveis

Como essa regra customizada é executada após a autenticação, mas antes da autorização, as informações que estão disponíveis não incluem todos os objetos de domínio possíveis. Eles são limitados aos tipos a seguir.

Contexto de solicitação de HTTP
Quando um usuário efetua o login no Verify, o contexto de solicitação HTTP recebida pode ser acessado na regra de mapeamento de solicitação. Todos os parâmetros de solicitação de OAuth, como claims e scope, estão disponíveis neste requestContext. A estrutura geral e o uso de requestContext são descritos na seção “Contexto de solicitação do HTTP ” do documento “ r_attr_functions.html ”.
Pela simplicidade de acesso, certos valores são pré-calculados no requestContext. O parâmetro da claims solicitação é representado em JSON, conforme o exemplo a seguir.
{
    "id_token": { 
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    },
    "userinfo": {
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    }
}

Esse JSON pode ser incômodo de acessar e por isso a chave que é usada no requestContext está no formato claims_claimType_claimName. O claimType é userinfo ou idtoken. Observe o sublinhado ausente. Assim, com o exemplo anterior, o valor claim_name pode ser obtido usando requestContext.getValue('claims_idtoken_claim_name').

Da mesma forma, scope é calculado e dividido por um espaço para construção de uma matriz de sequência.

Credencial de origem de identidade

Quando um usuário efetua login no Verify, os atributos de credencial de origem de identidade são incluídos na sessão de login e podem ser acessados na regra de mapeamento de solicitação.

O objeto de domínio idsuser está disponível como um mapa com uma chave de sequência e um valor de matriz de sequência. Por exemplo,
{
  "realmName": ["cloudIdentityRealm"],
  "displayName": ["Jessica J. Hill"],
  "phone": ["+12324321234"]
}
Para mais informações, consulte r_attr_functions.html.
Outras funções e operadores

Operadores e funções padrão estão disponíveis na regra de mapeamento. O cliente HTTP também está disponível para fazer solicitações de saída. Outras funções suportadas incluem hashing e registros de data e hora. Consulte as seções pertinentes do Manual de Normas de Qualidade ( r_attr_functions.html ).

Objeto de retorno

Espera-se que a regra customizada retorne uma matriz que contenha sequências ou objetos. As sequências são escopos, enquanto os objetos são escopos com informações adicionais para associá-los a um propósito de privacidade. Veja... /tasks/t_manage_purposes.html.

O código a seguir é um exemplo de objeto de retorno. marketingQuando o usuário concorda com o primeiro objeto de solicitação, é criado um consentimento para o email atributo. Além disso, o escopo personal:email é concedido e a solicitação personal_email_allowed é incluída no token de ID.

[
	{
		"purpose": "marketing",
		"attribute": "email",
		"accessType": "read",
		"value": "jhill@ibm.com",
		"custom": {
			"type": "personal"
		},
		"claims": {
			"personal_email_allowed": true
		},
		"scope": "personal:email"
	},
    {
        "purpose": "defaultEULA"
    },
	"profile",
	"email"
] + requestContext.scope
Nota:

A lista aqui substitui completamente os escopos solicitados e é usada para construir a página de consentimento. Consulte “Modificar o logon único para páginas do OpenID ”. Se a intenção for pedir mais consentimento ao usuário, deve-se anexar requestScope.scope como mostrado na inclusão e remoção de escopos de exemplo.

No exemplo, a matriz pode levar dois tipos - escopo OAuth como uma sequência e um objeto que tem mais contexto e resultados em um registro de autorização de consentimento de mais baixa granularidade. Essas propriedades são as propriedades que são permitidas no objeto.

Propriedade Tipo Obrigatório? Descrição
purpose Sequência Sim ../tasks/t_manage_purposes.html
attribute Sequência Depende de propósito Gerenciando atributos
accessType Sequência Depende de propósito O tipo de acesso é configurado com o propósito de privacidade de dados. Ele é padronizado para default se não fornecido.
value Sequência Não Indica um pedido de consentimento mais específico. Por exemplo, consentimento para um e-mail específico.
custom Objeto JSON. O tipo de valor da propriedade JSON é sequência. Não Qualquer informação de contexto adicional a ser incluída no consentimento. Esta propriedade pode ser exibida na página de consentimento na forma de macros de modelo.
claim Objeto JSON. O tipo de valor da propriedade JSON é sequência. Não Se a solicitação for autorizada, as solicitações correspondentes serão incluídas no token de ID emitido.
scope Sequência Não Se a solicitação for autorizada, esse valor será incluído nos escopos concedidos.
required Booleano Não Se required estiver definido como verdadeiro, o usuário deverá responder afirmativamente. Esse consentimento não é necessário se a política de privacidade indicar que o consentimento nunca pode ser aceito.
autoGrant Booleano Não Se autoGrant estiver definido como verdadeiro, o usuário não será solicitado a dar seu consentimento e o item de consentimento será automaticamente autorizado.
global Booleano Não Se global estiver definido como verdadeiro, o consentimento registrado será válido para todas as aplicações. Esta propriedade é relevante para itens de consentimento, como documentos de Termos e Condições que o usuário aceita apenas uma vez.
audience Sequência Não Se a solicitação for autorizada, esse valor será adicionado aos públicos-alvo concedidos, juntamente com a lista de públicos-alvo configurada no aplicativo e o ID de cliente padrão.
Exemplo para inclusão e remoção de escopos
Neste exemplo, um novo objeto de solicitação de consentimento é incluído, e um escopo é removido.
[
   {
       "purpose": "defaultEula",
       "scope": "eula:default"
   }
] + requestContext.scope.filter(x, x != "badscope")

Esta regra concede o escopo eula:default na autorização e associa-o ao consentimento da UELA. Ela também filtra badscope dos escopos solicitados.

A página de consentimento pode ser customizada para exibir detalhes da solicitação de consentimento que foram incluídos por meio dessa regra de mapeamento. Um exemplo está disponível em OpenID Mapeamento de solicitação de conexão com o ID de intenção do Open Banking.