Edge para nuvem privada v4.19.01
Este documento descreve como ativar a recuperação e a revogação de tokens de acesso do OAuth 2.0 ID do usuário final, ID do app ou ambos.
Os IDs de aplicativo são adicionados automaticamente a um token de acesso do OAuth. Portanto, depois de usar o método abaixo para ativar o acesso ao token em uma organização, acesse os tokens por ID do aplicativo.
Para recuperar e revogar tokens de acesso do OAuth 2.0 por ID de usuário final, um ID de usuário final precisa estar presente no token de acesso. O procedimento abaixo descreve como adicionar um ID de usuário final a um token existente ou a novos tokens.
Por padrão, quando o Edge gera um token de acesso do OAuth 2.0, o token tem o seguinte formato:
{ "issued_at" : "1421847736581", "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a", "scope" : "READ", "status" : "approved", "api_product_list" : "[PremiumWeatherAPI]", "expires_in" : "3599", "developer.email" : "tesla@weathersample.com", "organization_id" : "0", "token_type" : "BearerToken", "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP", "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL", "organization_name" : "myorg", "refresh_token_expires_in" : "0", "refresh_count" : "0" }
Observe o seguinte:
- O campo
application_name
contém o UUID do aplicativo associado ao token. Se você ativar a recuperação e a revogação de tokens de acesso do OAuth 2.0 por ID do aplicativo, esse é o ID do aplicativo que você usa. - O campo
access_token
contém o valor do token de acesso do OAuth 2.0.
Para ativar a recuperação e a revogação de tokens de acesso do OAuth 2.0 por ID do usuário final, configure a A política do OAuth 2.0 para incluir o ID do usuário no token, conforme descrito no procedimento abaixo.
O ID do usuário final é a string que o Edge usa como ID do desenvolvedor, não o e-mail do desenvolvedor. endereço IP. Você pode determinar o ID do desenvolvedor a partir do endereço de e-mail do desenvolvedor usando o método Get chamada de API do desenvolvedor.
Depois de configurar o Edge para incluir o ID do usuário final no token, ele será incluído como app_enduser, conforme mostrado abaixo:
{ "issued_at" : "1421847736581", "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a", "scope" : "READ", "app_enduser" : "6ZG094fgnjNf02EK", "status" : "approved", "api_product_list" : "[PremiumWeatherAPI]", "expires_in" : "3599", "developer.email" : "tesla@weathersample.com", "organization_id" : "0", "token_type" : "BearerToken", "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP", "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL", "organization_name" : "myorg", "refresh_token_expires_in" : "0", "refresh_count" : "0" }
APIs para recuperar e revogar Tokens de acesso do OAuth 2.0 por ID do usuário e do app
Use as seguintes APIs para acessar os tokens OAuth por ID de usuário, ID do app ou ambos:
- Instalar o OAuth 2.0 Token de acesso por ID de usuário final ou ID do app
- Revogar o OAuth 2.0 Token de acesso por ID de usuário final ou ID do app
Procedimento para ativar o acesso ao token
Use o procedimento a seguir para permitir a recuperação e a revogação de tokens de acesso do OAuth 2.0 por ID do usuário final e ID do app.
Etapa 1: Ativar o suporte ao acesso a tokens para uma organização
Você precisa ativar o acesso ao token para cada organização separadamente. Chame a API PUT abaixo para cada organização na qual você deseja ativar a recuperação e a revogação de tokens de acesso do OAuth 2.0 por ID do usuário final ou ID do app.
O usuário que faz a chamada abaixo precisa ter o papel orgadmin ou
opsadmin
para a organização. Substitua o values pelas informações específicas da sua organização.
valores:
curl -H "Content-type:text/xml" -X POST \ https://management_server_IP;:8080/v1/organizations/org_name \ -d '<Organization name="org_name"> <Properties> <Property name="features.isOAuthRevokeEnabled">true</Property> <Property name="features.isOAuth2TokenSearchEnabled">true</Property> </Properties> </Organization>' \ -u USER_EMAIL:PASSWORD
Etapa 2: definir permissões para o papel de administrador de operações na organização
Apenas os papéis orgadmin
e opsadmin
em uma organização
precisa receber permissões para recuperar (HTTP GET) e revogar (HTTP PUT) tokens OAuth 2.0 com base
no ID do usuário ou do app. Para controlar o acesso, defina as permissões get e put no recurso /oauth2 para
em uma organização. Esse recurso tem um URL no formato:
https://management_server_IP:8080/v1/organizations/org_name/oauth2
O papel orgadmin
já deve ter as permissões necessárias. Para o
opsadmin
para o recurso /oauth2, as permissões devem ser semelhantes a
isso:
<ResourcePermission path="/oauth2"> <Permissions> <Permission>get</Permission> <Permission>put</Permission> </Permissions> </ResourcePermission>
Você pode usar o Get
Permissão para chamada da API Single Resource para verificar quais papéis têm permissões para
recurso /oauth2
.
Com base na resposta, você pode usar o botão Adicionar Permissões do recurso para um papel e Exclua as chamadas da API Permission for Resource para fazer os ajustes necessários ao arquivo /oauth2 permissões de recursos.
Use o seguinte comando curl
para atribuir o papel opsadmin
Permissões get
e put
para o recurso /oauth2
. Substituir
o values pelos valores específicos da sua organização:
curl -X POST -H 'Content-type:application/xml' \ http://management_server_IP:8080/v1/organizations/org_name/userroles/opsadmin/permissions \ -d '<ResourcePermission path="/oauth2"> <Permissions> <Permission>get</Permission> <Permission>put</Permission> </Permissions> </ResourcePermission>' \ -u USEREMAIL:PASSWORD
Use o seguinte comando curl
para revogar get
e put
permissões para o recurso /oauth2
de outros papéis
orgadmin
e opsadmin
. Substitua values pela sua
valores específicos da organização:
curl -X DELETE -H 'Content-type:application/xml' \ http://management_server_IP:8080/v1/organizations/org_name/userroles/roles/permissions \ -d '<ResourcePermission path="/oauth2"> <Permissions></Permissions> </ResourcePermission>' \ -u USEREMAIL:PASSWORD
Etapa 3: definir a propriedade oauth_max_search_limit
Confira se conf_keymanagement_oauth_max_search_limit
propriedade em /opt/apigee/customer/application/management-server.properties
está definido como 100:
conf_keymanagement_oauth_max_search_limit = 100
Crie esse arquivo se ele não existir.
Essa propriedade define o tamanho da página usado ao buscar tokens. A Apigee recomenda um valor de 100, mas você pode defini-lo como quiser.
Em uma nova instalação, a propriedade já deve estar definida como 100. Se você precisar alterar valor desta propriedade, reinicie o Servidor de gerenciamento e o Processador de mensagens usando o comandos:
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Etapa 4: configurar a política do OAuth 2.0 que gera tokens para incluir o ID do usuário final
Configure a política OAuth 2.0 usada para gerar tokens de acesso para incluir o ID do usuário final na o token. Ao incluir IDs de usuário final no token de acesso, é possível recuperar e revogar tokens ID.
Para configurar a política para incluir um ID de usuário final em um token de acesso, a solicitação que cria o token de acesso deve incluir o ID do usuário final e você deve especificar a variável de entrada que contém o ID do usuário final.
A política OAuth 2.0 abaixo, chamada GenerateAccessTokenClient, gera um acesso ao OAuth 2.0
com base no token correto anterior. Observe a adição da tag <AppEndUser>
em negrito que especifica
a variável que contém o ID do usuário final:
<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient"> <DisplayName>OAuth 2.0.0 1</DisplayName> <ExternalAuthorization>false</ExternalAuthorization> <Operation>GenerateAccessToken</Operation> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <GenerateResponse enabled="true"/> <GrantType>request.queryparam.grant_type</GrantType> <AppEndUser>request.header.appuserID</AppEndUser> <ExpiresIn>960000</ExpiresIn> </OAuthV2>
Você pode usar o seguinte comando curl
para gerar o acesso ao OAuth 2.0
token, passando o ID do usuário como o cabeçalho appuserID
:
curl -H "appuserID:6ZG094fgnjNf02EK" \ https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials \ -X POST -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNXFmP&client_secret=gk5K5lIp943AY4'
Nesse exemplo, o appuserID
é transmitido como um cabeçalho de solicitação. Você pode transmitir
informações como parte de uma solicitação. Por exemplo, como alternativa, você pode:
- Use uma variável de parâmetro de formulário:
request.formparam.appuserID
- Usar uma variável de fluxo que fornece o ID do usuário final