Geração de tokens de acesso para APIs do lado do servidor generating-access-tokens-for-server-side-apis

Algumas arquiteturas dependem de fazer chamadas para o AEM as a Cloud Service a partir de um aplicativo hospedado em um servidor fora da infraestrutura AEM. Por exemplo, um aplicativo móvel que chama um servidor, que faz solicitações de API para o AEM as a Cloud Service.

O fluxo de servidor para servidor é descrito abaixo, juntamente com um fluxo simplificado para desenvolvimento. O AEM as a Cloud Service Developer Console é usado para gerar tokens necessários para o processo de autenticação.

O fluxo de servidor para servidor the-server-to-server-flow

Usuários com uma função de administrador da organização IMS e que são membros do Perfil de produto Usuários do AEM ou Administradores do AEM no AEM Author podem gerar um conjunto de credenciais do AEM as a Cloud Service. Cada credencial é uma carga JSON que inclui um certificado (a chave pública), uma chave privada e uma conta técnica que consiste em um clientId e clientSecret. Essas credenciais podem ser recuperadas posteriormente por um usuário com a função de administrador de ambiente do AEM as a Cloud Service e devem ser instaladas em um servidor não AEM e tratadas cuidadosamente como uma chave secreta. Esse arquivo de formato JSON contém todos os dados necessários para integrar a uma API do AEM as a Cloud Service. Os dados são usados para criar um token JWT assinado, que é substituído pelo Adobe Identity Management Services (IMS) por um token de acesso IMS. Esse token de acesso pode ser usado como um token de autenticação de portador para fazer solicitações à AEM as a Cloud Service. Por padrão, o certificado nas credenciais expira após um ano, mas elas podem ser atualizadas quando necessário, conforme descrito aqui.

O fluxo de servidor para servidor envolve as seguintes etapas:

Buscar as credenciais do AEM as a Cloud Service fetch-the-aem-as-a-cloud-service-credentials

Os usuários com acesso ao console do desenvolvedor do AEM as a Cloud Service veem a guia Integrações no Developer Console para um determinado ambiente. Um usuário com a função de administrador do Ambiente AEM as a Cloud Service pode criar, exibir ou gerenciar credenciais.

Ao clicar em Criar nova conta técnica, é criado um conjunto de credenciais que inclui a ID do cliente, o segredo do cliente, a chave privada, o certificado e a configuração para os níveis de criação e publicação do ambiente, independentemente da seleção do pod.

Uma nova guia do navegador é aberta, exibindo as credenciais. Você pode usar essa visualização para baixar as credenciais pressionando o ícone de download ao lado do título do status:

Após as credenciais serem criadas, elas aparecerão na guia Contas técnicas na seção Integrações:

Os usuários podem exibir as credenciais posteriormente usando a ação Exibir. Além disso, conforme descrito posteriormente neste artigo, os usuários podem editar as credenciais para a mesma conta técnica. Eles fazem essa edição criando uma chave privada ou certificado, para casos em que o certificado deve ser renovado ou revogado.

Usuários com a função de Administrador de ambiente do AEM as a Cloud Service podem criar credenciais posteriormente para contas técnicas adicionais. Essa capacidade é útil quando APIs diferentes têm requisitos de acesso diferentes. Por exemplo, leitura versus leitura-gravação.

Instalar as credenciais do serviço AEM em um servidor não AEM install-the-aem-service-credentials-on-a-non-aem-server

O aplicativo que faz chamadas para AEM deve poder acessar as credenciais do AEM as a Cloud Service, tratando-o como um segredo.

Gerar um token JWT e trocá-lo por um token de acesso generate-a-jwt-token-and-exchange-it-for-an-access-token

Use as credenciais para criar um token JWT em uma chamada para o serviço IMS Adobe para recuperar um token de acesso, que é válido por 24 horas.

As Credenciais de Serviço AEM CS podem ser trocadas por um token de acesso usando bibliotecas de clientes criadas para essa finalidade. Adobe As bibliotecas de clientes estão disponíveis no repositório GitHub público, que contém orientações mais detalhadas e informações mais recentes.

/*jshint node:true */
"use strict";

const fs = require('fs');
const exchange = require("@adobe/aemcs-api-client-lib");

const jsonfile = "aemcs-service-credentials.json";

var config = JSON.parse(fs.readFileSync(jsonfile, 'utf8'));
exchange(config).then(accessToken => {
    // output the access token in json form including when it will expire.
    console.log(JSON.stringify(accessToken,null,2));
}).catch(e => {
    console.log("Failed to exchange for access token ",e);
});

A mesma troca pode ser executada em qualquer linguagem capaz de gerar um token JWT assinado com o formato correto e chamar as APIs IMS Token Exchange.

O token de acesso define quando expira, o que geralmente é de 24 horas. Há um código de amostra no repositório Git para gerenciar um token de acesso e atualizá-lo antes que ele expire.

Chamar a API do AEM calling-the-aem-api

Fazer as chamadas de API de servidor para servidor apropriadas para um ambiente do AEM as a Cloud Service, incluindo o token de acesso no cabeçalho. Portanto, para o cabeçalho "Autorização", use o valor "Bearer <access_token>". Por exemplo, usando curl:

curl -H "Authorization: Bearer <your_ims_access_token>" https://author-p123123-e23423423.adobeaemcloud.com/content/dam.json

Definir as permissões apropriadas para o usuário da conta técnica no AEM set-the-appropriate-permissions-for-the-technical-account-user-in-aem

Primeiro, um novo perfil de produto deve ser criado no Adobe Admin Console.

Depois de fazer a chamada de API, o perfil de produto aparece como um grupo de usuários na instância de autor do AEM as a Cloud Service, com a conta técnica apropriada como membro desse grupo.

Para verificar essas informações, faça o seguinte:

Como alternativa, você também pode verificar se a conta técnica aparece na lista do usuário executando as etapas abaixo na instância do autor:

Definir as Permissões de Grupo Apropriadas

Por fim, configure o grupo com as permissões apropriadas necessárias para que você possa chamar ou bloquear suas APIs adequadamente.

Fluxo do desenvolvedor developer-flow

Os desenvolvedores provavelmente desejam testar usando uma instância de desenvolvimento de seu aplicativo não AEM (em execução no laptop ou hospedado) que faz solicitações a um ambiente de desenvolvimento do AEM as a Cloud Service. No entanto, como os desenvolvedores não têm necessariamente permissões de função de administrador do IMS, o Adobe não pode supor que podem gerar o portador JWT descrito no fluxo regular de servidor para servidor. Portanto, o Adobe fornece um mecanismo para que um desenvolvedor gere um token de acesso diretamente que possa ser usado em solicitações para ambientes no AEM as a Cloud Service aos quais ele tem acesso.

Consulte a documentação das Diretrizes do desenvolvedor para obter informações sobre as permissões necessárias para usar o console do desenvolvedor do AEM as a Cloud Service.

Os desenvolvedores podem usar esse token para fazer chamadas de seu aplicativo de teste não-AEM para um ambiente AEM as a Cloud Service. Normalmente, o desenvolvedor usa esse token com o aplicativo não-AEM em seu próprio notebook. Além disso, o AEM as a Cloud normalmente é um ambiente de não produção.

O fluxo do desenvolvedor envolve as seguintes etapas:

Os desenvolvedores também podem fazer chamadas de API para um projeto AEM em execução em sua máquina local, caso em que um token de acesso não é necessário.

Gerar o token de acesso generating-the-access-token

Chamar o aplicativo AEM com um token de acesso call-the-aem-application-with-an-access-token

Fazer as chamadas de API de servidor para servidor apropriadas do aplicativo não-AEM para um ambiente AEM as a Cloud Service, incluindo o token de acesso no cabeçalho. Portanto, para o cabeçalho "Autorização", use o valor "Bearer <access_token>".

Atualizar credenciais refresh-credentials

Por padrão, as credenciais no AEM as a Cloud Service expiram após um ano. Para garantir a continuidade do serviço, os desenvolvedores têm a opção de atualizar as credenciais, estendendo sua disponibilidade por mais um ano.

Para obter essa extensão de atualização, faça o seguinte:

Revogação de credenciais credentials-revocation

Se a chave privada estiver comprometida, você deverá criar credenciais com um novo certificado e uma nova chave privada. Depois que sua aplicação usar as novas credenciais para gerar tokens de acesso, você poderá revogar e deletar os certificados antigos fazendo o seguinte: