Tipos de autorização Autorização API_KEY Autorização do AWS_LAMBDA Autorização do AWS_IAM Autorização do OPENID_CONNECT Autorização do AMAZON_COGNITO_USER_POOLS Usar modos de autorização adicionais Controle de acesso refinado Filtrar informações Acesso à fonte de dados

Autorização e autenticação

Esta seção descreve as opções para configurar a segurança e a proteção de dados para os aplicativos.

Tipos de autorização

Há cinco maneiras de autorizar aplicativos a interagir com sua API AWS AppSync GraphQL. Você especifica qual tipo de autorização você usa especificando um dos seguintes valores de tipo de autorização em sua chamada de AWS AppSync API ou CLI:

API_KEY

Para usar chaves da API.
AWS_LAMBDA

Para usar uma AWS Lambda função.
AWS_IAM

Para usar permissões AWS Identity and Access Management (IAM).
OPENID_CONNECT

Para usar o provedor OpenID Connect.
AMAZON_COGNITO_USER_POOLS

Para usar um grupo de usuários do Amazon Cognito.

Esses tipos de autorização básicos funcionam para a maioria dos desenvolvedores. Para casos de uso mais avançados, é possível adicionar modos de autorização adicionais por meio do console, da CLI e do AWS CloudFormation. Para modos de autorização adicionais, AWS AppSync fornece um tipo de autorização que usa os valores listados acima (ou sejaAPI_KEY,AWS_LAMBDA,AWS_IAM,OPENID_CONNECT, eAMAZON_COGNITO_USER_POOLS).

Ao especificar API_KEY, AWS_LAMBDA ou AWS_IAM como o tipo de autorização principal ou padrão, não é possível especificá-los novamente como um dos modos de autorização adicionais. Da mesma forma, você não pode duplicar API_KEY, AWS_LAMBDA ou AWS_IAM nos modos de autorização adicionais. É possível usar vários grupos de usuários do Amazon Cognito e provedores do OpenID Connect. No entanto, você não pode usar grupos de usuários do Amazon Cognito nem provedores do OpenID Connect duplicados entre o modo de autorização padrão e qualquer um dos outros modos de autorização. É possível especificar clientes diferentes para o grupo de usuários do Amazon Cognito ou o provedor do OpenID Connect usando a expressão regular de configuração correspondente.

Autorização API_KEY

APIs não autenticadas exigem controle de utilização mais estrita que APIs autenticadas. Uma maneira de verificar o controle de utilização para endpoints GraphQL não autenticados é por meio do uso de chaves da API. Uma chave de API é um valor codificado em seu aplicativo que é gerado pelo AWS AppSync serviço quando você cria um endpoint GraphQL não autenticado. Você pode rotacionar as chaves de API no console, da CLI ou da Referência da API do AWS AppSync.

Console

Faça login no AWS Management Console e abra o AppSyncconsole.
1. No painel de APIs, escolha sua API GraphQL.
2. Na barra lateral, escolha Configurações.
Em Modo de autorização padrão, escolha Chave de API.
Na tabela chaves de API, escolha Adicionar chave de API.

Uma nova chave de API será gerada na tabela.
1. Para excluir uma chave de API antiga, selecione a chave de API na tabela e escolha Excluir.
Escolha Salvar na parte inferior da página.

CLI

Se você ainda não tiver feito isso, configure seu acesso à AWS CLI. Para obter mais informações, consulte Noções básicas de configuração.

Crie um objeto da API GraphQL executando o comando update-graphql-api.

Você precisará digitar dois parâmetros para esse comando específico:

O api-id da sua API GraphQL.
O novo name da sua API. Você pode usar o mesmo name.
O authentication-type, que será API_KEY.

nota

Existem outros parâmetros, como Region, que devem ser configurados, mas geralmente usam como padrão os valores de configuração da CLI.

Veja um exemplo de comando:


aws appsync update-graphql-api --api-id abcdefghijklmnopqrstuvwxyz --name TestAPI --authentication-type API_KEY

Uma saída será retornada na CLI. Aqui está um exemplo em JSON:


{
    "graphqlApi": {
        "xrayEnabled": false,
        "name": "TestAPI",
        "authenticationType": "API_KEY",
        "tags": {},
        "apiId": "abcdefghijklmnopqrstuvwxyz",
        "uris": {
            "GRAPHQL": "https://s8i3kk3ufhe9034ujnv73r513e.appsync-api.us-west-2.amazonaws.com/graphql",
            "REALTIME": "wss://s8i3kk3ufhe9034ujnv73r513e.appsync-realtime-api.us-west-2.amazonaws.com/graphql"
        },
        "arn": "arn:aws:appsync:us-west-2:348581070237:apis/abcdefghijklmnopqrstuvwxyz"
    }
}

As chaves da API são configuráveis para até 365 dias e é possível estender uma data de expiração existente para mais 365 dias a partir dessa data. As chaves da API são recomendadas para fins de desenvolvimento ou casos de uso em que é seguro expor uma API pública.

No cliente, a chave da API é especificada pelo cabeçalho x-api-key.

Por exemplo, se o API_KEY for 'ABC123', envie uma consulta do GraphQL via curl da seguinte forma:


$ curl -XPOST -H "Content-Type:application/graphql" -H "x-api-key:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql

Autorização do AWS_LAMBDA

Você pode implementar sua própria lógica de autorização de API usando uma AWS Lambda função. Você pode usar uma função do Lambda para seu autorizador primário ou secundário, mas pode haver somente uma função de autorização do Lambda por API. Ao usar funções do Lambda para autorização, o seguinte se aplica:

Se a API tiver os modos de autorização AWS_IAM e AWS_LAMBDA habilitados, a assinatura do SigV4 não poderá ser usada como token de autorização do AWS_LAMBDA.
Se a API tiver os modos de autorização AWS_LAMBDA, OPENID_CONNECT ou AMAZON_COGNITO_USER_POOLS habilitados, o token do OIDC não poderá ser usado como token de autorização do AWS_LAMBDA. Observe que o token OIDC pode ser um esquema do Bearer.
Uma função do Lambda não deve retornar mais de 5 MB de dados contextuais para os resolvedores.

Por exemplo, se o token de autorização for 'ABC123', envie uma consulta do GraphQL via curl da seguinte forma:


$ curl -XPOST -H "Content-Type:application/graphql" -H "Authorization:ABC123" -d '{ "query":
         "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql

As funções do Lambda são chamadas antes de cada consulta ou mutação. O valor de retorno pode ser armazenado em cache com base no ID da API e no token de autenticação. Por padrão, o armazenamento em cache não está habilitado, mas isso pode ser habilitado no nível da API ou definindo o valor ttlOverride no valor de retorno de uma função.

Uma expressão regular que valida os tokens de autorização antes que a função seja chamada pode ser especificada, se desejado. Essas expressões regulares são usadas para validar se um token de autorização está no formato correto antes de sua função ser chamada. Qualquer solicitação que use um token que não corresponda a essa expressão regular será negada automaticamente.

As funções Lambda usadas para autorização exigem que uma política principal seja aplicada appsync.amazonaws.com a elas AWS AppSync para permitir sua chamada. Essa ação é feita automaticamente no AWS AppSync console; o AWS AppSync console não remove a política. Para obter mais informações sobre como anexar políticas às funções do Lambda, consulte Políticas baseadas em recursos no Guia do desenvolvedor. AWS Lambda

A função do Lambda que você especificar receberá um evento com a seguinte forma:


{
    "authorizationToken": "ExampleAUTHtoken123123123",
    "requestContext": {
        "apiId": "aaaaaa123123123example123",
        "accountId": "111122223333",
        "requestId": "f4081827-1111-4444-5555-5cf4695f339f",
        "queryString": "mutation CreateEvent {...}\n\nquery MyQuery {...}\n",
        "operationName": "MyQuery",
        "variables": {}
    }
    "requestHeaders": {
        application request headers
    }
}

O event objeto contém os cabeçalhos que foram enviados na solicitação do cliente do aplicativo para AWS AppSync.

A função de autorização deve retornar pelo menos isAuthorized um booleano indicando se a solicitação foi autorizada. AWS AppSync reconhece as seguintes chaves retornadas das funções de autorização do Lambda:

isAuthorized (booleano, obrigatório)

Um valor booleano indicando se o valor no authorizationToken está autorizado a fazer chamadas para a API GraphQL.

Se esse valor for verdadeiro, a execução da API GraphQL continuará. Se esse valor for falso, um UnauthorizedException será gerado.

deniedFields (lista de strings, opcional)

Uma lista que é alterada à força para null, mesmo que um valor tenha sido retornado de um resolvedor.

Cada item é um ARN de campo totalmente qualificado na forma de arn:aws:appsync:us-east-1:111122223333:apis/GraphQLApiId/types/TypeName/fields/FieldName ou uma forma abreviada de TypeName.FieldName. O formulário ARN completo deve ser usado quando duas APIs compartilham um autorizador de função Lambda e pode haver ambigüidade entre tipos e campos comuns entre as duas APIs.

resolverContext (objeto JSON, opcional)

Um objeto JSON visível como $ctx.identity.resolverContext nos modelos de resolvedor. Por exemplo, se a estrutura a seguir for retornada por um resolvedor:


{
  "isAuthorized":true
  "resolverContext": {
    "banana":"very yellow",
    "apple":"very green" 
  }
}

O valor de ctx.identity.resolverContext.apple nos modelos do resolvedor será "very green”. O objeto resolverContext é compatível apenas com pares de chave-valor. Não há suporte para chaves aninhadas.

Atenção

O tamanho total desse objeto JSON não deve exceder 5 MB.

ttlOverride (inteiro, opcional): O número de segundos que deve levar para a resposta ser armazenada em cache. Se nenhum valor for retornado, o valor da API será usado. Se for 0, a resposta não será armazenada em cache.

Os autorizadores Lambda têm um tempo limite de 10 segundos. Recomendamos criar funções para serem executadas no menor tempo possível para escalar o desempenho da sua API.

Várias AWS AppSync APIs podem compartilhar uma única função Lambda de autenticação. O uso de autorizadores entre contas não é permitido.

Ao compartilhar uma função de autorização entre várias APIs, esteja ciente de que nomes de campo abreviados (typename.fieldname) podem ocultar campos inadvertidamente. Para eliminar a ambiguidade de um campo em deniedFields, você pode especificar um ARN de campo não ambíguo na forma de arn:aws:appsync:region:accountId:apis/GraphQLApiId/types/typeName/fields/fieldName.

Para adicionar uma função do Lambda como o modo de autorização padrão em AWS AppSync:

O exemplo a seguir descreve uma função do Lambda que demonstra os vários estados de autenticação e falha que uma função do Lambda pode ter quando usada como mecanismo de autorização do AWS AppSync :



def handler(event, context):
  # This is the authorization token passed by the client
  token = event.get('authorizationToken')
  # If a lambda authorizer throws an exception, it will be treated as unauthorized. 
  if 'Fail' in token:
    raise Exception('Purposefully thrown exception in Lambda Authorizer.')

  if 'Authorized' in token and 'ReturnContext' in token:
    return {
      'isAuthorized': True,
      'resolverContext': {
        'key': 'value'
      }
    }

  # Authorized with no f
  if 'Authorized' in token:
    return {
      'isAuthorized': True
    }
  # Partial authorization
  if 'Partial' in token:
    return {
      'isAuthorized': True,
      'deniedFields':['user.favoriteColor']
    }
  if 'NeverCache' in token:
    return {
      'isAuthorized': True,
      'ttlOverride': 0
    }
  if 'Unauthorized' in token:
    return {
      'isAuthorized': False
    }
  # if nothing is returned, then the authorization fails. 
  return {}

Como contornar as limitações de autorização de tokens do SigV4 e OIDC

Os métodos a seguir podem ser usados para contornar o problema de não ser possível usar sua assinatura do SigV4 ou token do OIDC como seu token de autorização do Lambda quando determinados modos de autorização estão habilitados.

Se você quiser usar a assinatura do SigV4 como token de autorização do Lambda quando os modos de autorização do AWS_IAM e AWS_LAMBDA estiverem habilitados para a API, faça AWS AppSync o seguinte:

Para criar um novo token de autorização do Lambda, adicione sufixos e/ou prefixos aleatórios à assinatura do SigV4.
Para recuperar a assinatura original do SigV4, atualize sua função do Lambda removendo os prefixos e/ou sufixos aleatórios do token de autorização do Lambda. Em seguida, use a assinatura original do SigV4 para autenticação.

Se você quiser usar o token OIDC como o token de autorização Lambda quando o modo de autorização ou os modos de OPENID_CONNECT autorização AMAZON_COGNITO_USER_POOLS e de AWS_LAMBDA autorização estiverem habilitados para a API, AWS AppSync faça o seguinte:

Para criar um novo token de autorização do Lambda, adicione sufixos e/ou prefixos aleatórios à assinatura do OIDC. O token de autorização do Lambda não deve conter um prefixo do esquema do Bearer.
Para recuperar a assinatura original do OIDC, atualize sua função do Lambda removendo os prefixos e/ou sufixos aleatórios do token de autorização do Lambda. Em seguida, use o token original do OIDC para autenticação.

Autorização do AWS_IAM

Esse tipo de autorização impõe o processo de assinatura versão 4 da assinatura AWS na API GraphQL. Associe políticas de acesso do Identity and Access Management (IAM) com esse tipo de autorização. A aplicação pode aproveitar essa associação ao usar uma chave de acesso (que consiste em um ID de chave de acesso e chave de acesso secreta) ou usando credenciais temporárias de curta duração fornecidas por identidades federadas do Amazon Cognito.

Se quiser um perfil com acesso para realizar todas as operações de dados:


{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "appsync:GraphQL"
         ],
         "Resource": [
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/*"
         ]
      }
   ]
}

Você pode encontrar na página principal YourGraphQLApiId de listagem de APIs no AppSync console, diretamente abaixo do nome da sua API. Como alternativa, você pode recuperá-lo com a CLI: aws appsync list-graphql-apis

Se desejar restringir o acesso somente a determinadas operações do GraphQL, faça isso para os campos Query, Mutation e Subscription raiz.


{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "appsync:GraphQL"
         ],
         "Resource": [
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/<Field-2>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Mutation/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Subscription/fields/<Field-1>"
         ]
     }
   ]
}

Por exemplo, suponha que tenha o seguinte esquema e deseje restringir o acesso à obtenção de todas as postagens:


schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

type Mutation {
   addPost(id:ID!, title:String!):Post!
}

A política do IAM correspondente para uma função (que pode ser anexada a um banco de identidades do Amazon Cognito, por exemplo) seria semelhante ao seguinte:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
            "appsync:GraphQL"
            ],
            "Resource": [
                "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/posts"
            ]
        }
    ]
}

Autorização do OPENID_CONNECT

Esse tipo de autorização impõe tokens do OpenID Connect (OIDC) fornecidos por um serviço compatível com o OIDC. O aplicativo pode aproveitar os usuários e os privilégios definidos pelo provedor de OIDC para controlar o acesso.

Um URL do emissor é o único valor de configuração necessário que você fornece para AWS AppSync (por exemplo,https://auth.example.com). Esse URL deve ser endereçável por HTTPS. AWS AppSync /.well-known/openid-configurationanexa ao URL do emissor e localiza a configuração do OpenID de acordo com a especificação do https://auth.example.com/.well-known/openid-configuration OpenID Connect Discovery. Ele espera recuperar um documento JSON compatível com RFC5785 nesse URL. Esse documento JSON deve conter uma jwks_uri chave, que aponta para o documento JSON Web Key Set (JWKS) com as chaves de assinatura. AWS AppSync exige que o JWKS contenha campos JSON de e. kty kid

AWS AppSync suporta uma ampla variedade de algoritmos de assinatura.

Algoritmos de assinatura
RS256
RS384
RS512
PS256
PS384
PS512
HS256
HS384
HS512
ES256
ES384
ES512

Recomendamos que você use os algoritmos do RSA. Os tokens emitidos pelo provedor devem incluir a hora em que o token foi emitido (iat) e pode incluir a hora em que foi autenticado (auth_time). Você pode fornecer valores de TTL para a hora de emissão (iatTTL) e a hora de autenticação (authTTL) na configuração do OpenID Connect para validação adicional. Se o provedor autoriza vários aplicativos, você também pode fornecer uma expressão regular (clientId) usada para autorizar por ID de cliente. Quando o clientId está presente em sua configuração do OpenID Connect, AWS AppSync valida a declaração exigindo que a corresponda clientId à azp reivindicação aud ou à reivindicação no token.

Para validar vários IDs de cliente, use o operador de pipeline ("|") que é um "ou" na expressão regular. Por exemplo, se seu aplicativo OIDC tiver quatro clientes com IDs de cliente, como 0A1S2D, 1F4G9H, 1J6L4B, 6GS5MG, para validar somente os três primeiros IDs de cliente, você colocaria 1F4G9H|1J6L4B|6GS5MG no campo ID do cliente.

Autorização do AMAZON_COGNITO_USER_POOLS

Esse tipo de autorização impõe tokens do OIDC fornecidos por grupos de usuários do Amazon Cognito. Seu aplicativo pode aproveitar os usuários e grupos em seus grupos de usuários e grupos de usuários de outra AWS conta e associá-los aos campos do GraphQL para controlar o acesso.

Ao usar grupos de usuários do Amazon Cognito, crie grupos aos quais os usuários pertencem. Essas informações são codificadas em um token JWT para o qual seu aplicativo envia AWS AppSync em um cabeçalho de autorização ao enviar operações do GraphQL. Use diretivas do GraphQL no esquema para controlar quais grupos podem invocar quais resolvedores em um campo, oferecendo acesso mais controlado aos clientes.

Por exemplo, digamos que tenha o seguinte esquema do GraphQL:


schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

type Mutation {
   addPost(id:ID!, title:String!):Post!
}
...

Se tiver dois grupos em grupos de usuários do Amazon Cognito (blogueiros e leitores) e quiser restringir os leitores para que não possam adicionar novas entradas, o seu esquema deve ser semelhante ao seguinte:


schema {
   query: Query
   mutation: Mutation
}


type Query {
   posts:[Post!]!
   @aws_auth(cognito_groups: ["Bloggers", "Readers"])
}

type Mutation {
   addPost(id:ID!, title:String!):Post!
   @aws_auth(cognito_groups: ["Bloggers"])
}
...

Observe que você pode omitir a @aws_auth diretiva se quiser usar como padrão uma grant-or-deny estratégia específica de acesso. Você pode especificar a grant-or-deny estratégia na configuração do grupo de usuários ao criar sua API GraphQL por meio do console ou do seguinte comando da CLI:


$ aws appsync --region us-west-2 create-graphql-api --authentication-type AMAZON_COGNITO_USER_POOLS  --name userpoolstest --user-pool-config '{ "userPoolId":"test", "defaultEffect":"ALLOW", "awsRegion":"us-west-2"}'

Usar modos de autorização adicionais

Ao adicionar outros modos de autorização, você pode definir diretamente a configuração de autorização no nível da API AWS AppSync GraphQL (ou seja, o authenticationType campo que você pode configurar diretamente no GraphqlApi objeto) e ela atua como padrão no esquema. Isso significa que qualquer tipo que não tenha uma diretiva específica deve passar na configuração de autorização no nível da API.

No nível do esquema, é possível especificar modos de autorização adicionais usando diretivas no esquema. Você pode especificar modos de autorização em campos individuais no esquema. Por exemplo, para autorização API_KEY, você usaria @aws_api_key em definições/campos de tipo de objeto de esquema. As seguintes diretivas são compatíveis com campos de esquema e definições de tipo de objeto:

@aws_api_key – para especificar que o campo é API_KEY autorizado.
@aws_iam – para especificar que o campo é AWS_IAM autorizado.
@aws_oidc – para especificar que o campo é OPENID_CONNECT autorizado.
@aws_cognito_user_pools – para especificar que o campo é AMAZON_COGNITO_USER_POOLS autorizado.
@aws_lambda – para especificar que o campo é AWS_LAMBDA autorizado.

Não é possível usar a diretiva @aws_auth junto com modos de autorização adicionais. O @aws_auth funciona apenas no contexto de autorização AMAZON_COGNITO_USER_POOLS sem modos de autorização adicionais. No entanto, é possível usar a diretiva @aws_cognito_user_pools no lugar da diretiva @aws_auth, usando os mesmos argumentos. A principal diferença entre as duas é que você pode especificar @aws_cognito_user_pools em qualquer definição de campo e tipo de objeto.

Para entender como os modos de autorização adicionais funcionam e como eles podem ser especificados em um esquema, vamos dar uma olhada no seguinte esquema:


schema {
   query: Query
   mutation: Mutation
}

type Query {
   getPost(id: ID): Post
   getAllPosts(): [Post]
   @aws_api_key
}

type Mutation {
   addPost(
      id: ID!
      author: String!
      title: String!
      content: String!
      url: String!
   ): Post!
}

type Post @aws_api_key @aws_iam {
   id: ID!
   author: String
   title: String
   content: String
   url: String
   ups: Int!
   downs: Int!
   version: Int!
}
...

Para esse esquema, suponha que esse AWS_IAM seja o tipo de autorização padrão na API AWS AppSync GraphQL. Isso significa que os campos que não têm uma diretiva são protegidos usando o AWS_IAM. Por exemplo, esse é o caso do campo getPost no tipo Query. As diretivas de esquema permitem que você use mais de um modo de autorização. Por exemplo, você pode ter API_KEY configurado como um modo de autorização adicional na API AWS AppSync GraphQL e pode marcar um campo usando a @aws_api_key diretiva (por exemplo, getAllPosts neste exemplo). As diretivas funcionam no nível do campo, portanto, também é necessário conceder a API_KEY acesso ao tipo Post. Você pode fazer isso marcando cada campo no tipo Post com uma diretiva ou marcando o tipo Post com a diretiva @aws_api_key.

Para restringir ainda mais o acesso aos campos no tipo Post, é possível usar diretivas em relação a campos individuais no tipo Post, conforme mostrado a seguir.

Por exemplo, é possível adicionar um campo restrictedContent ao tipo Post e restringir o acesso a ele usando a diretiva @aws_iam. As solicitações AWS_IAM autenticadas podem acessar restrictedContent, no entanto, as solicitações API_KEY não podem acessá-lo.


type Post @aws_api_key @aws_iam{
   id: ID!
   author: String
   title: String
   content: String
   url: String
   ups: Int!
   downs: Int!
   version: Int!
   restrictedContent: String!
   @aws_iam
}
...

Controle de acesso refinado

As informações anteriores demonstram como restringir ou conceder acesso a determinados campos do GraphQL. Se deseja definir controles de acesso nos dados com base em determinadas condições (por exemplo, com base no usuário que está fazendo uma chamada e se o usuário é proprietário dos dados), você pode usar modelos de mapeamento nos resolvedores. Também é possível executar lógica de negócios mais complexa, descrita em Filtrar informações.

Essa seção mostra como definir controles de acesso nos dados usando um modelo de mapeamento de resolvedor do DynamoDB.

Antes de prosseguir, se você não estiver familiarizado com os modelos de mapeamento em AWS AppSync, talvez queira revisar a referência do modelo de mapeamento do Resolver e a referência do modelo de mapeamento do Resolver para o DynamoDB.

No exemplo a seguir que usa o DynamoDB, suponha que você esteja usando o esquema de publicação de blog anterior e somente usuários que criaram uma publicação possam editá-lo. O processo de avaliação seria o usuário obter credenciais no seu aplicativo, usando Grupos de usuários do Amazon Cognito por exemplo e, em seguida, enviar essas credenciais como parte de uma operação do GraphQL. Em seguida, o modelo de mapeamento substituirá um valor das credenciais (como o nome do usuário) em uma instrução condicional que então será comparado a um valor do banco de dados.

Para adicionar essa funcionalidade, adicione um campo do GraphQL editPost da seguinte forma:


schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

type Mutation {
   editPost(id:ID!, title:String, content:String):Post
   addPost(id:ID!, title:String!):Post!
}
...

O modelo de mapeamento do resolvedor editPost (mostrado em um exemplo no final dessa seção) precisa executar uma verificação lógica no armazenamento de dados para permitir que apenas o usuário que criou uma publicação possa editá-la. Como essa é uma operação de edição, ela corresponde a um UpdateItem no DynamoDB. Execute uma verificação condicional antes de executar essa ação, usando o contexto enviado para a validação de identidade do usuário. Isso é armazenado em um objeto Identity com os seguintes valores:


{
   "accountId" : "12321434323",
   "cognitoIdentityPoolId" : "",
   "cognitoIdentityId" : "",
   "sourceIP" : "",
   "caller" : "ThisistheprincipalARN",
   "username" : "username",
   "userArn" : "Sameasabove"
}

Para usar esse objeto em uma chamada do UpdateItem do DynamoDB, é necessário armazenar as informações sobre a identidade do usuário na tabela para comparação. Primeiro, a mutação addPost precisa armazenar o criador. Em segundo lugar, a mutação editPost precisa executar a verificação condicional antes de atualizar.

Veja aqui um exemplo de código de resolvedor para addPost que armazena a identidade do usuário como uma coluna Author:


import { util, Context } from '@aws-appsync/utils';
import { put } from '@aws-appsync/utils/dynamodb';

export function request(ctx) {
	const { id: postId, ...item } = ctx.args;
	return put({
		key: { postId },
		item: { ...item, Author: ctx.identity.username },
		condition: { postId: { attributeExists: false } },
	});
}

export const response = (ctx) => ctx.result;

Observe que o atributo Author é preenchido a partir do objeto Identity, que veio do aplicativo.

Por fim, veja um exemplo do código de resolvedor para editPost, que atualizará apenas o conteúdo da publicação de blog se a solicitação vier do usuário que criou a publicação:


import { util, Context } from '@aws-appsync/utils';
import { put } from '@aws-appsync/utils/dynamodb';

export function request(ctx) {
	const { id, ...item } = ctx.args;
	return put({
		key: { id },
		item,
		condition: { author: { contains: ctx.identity.username } },
	});
}

export const response = (ctx) => ctx.result;

Este exemplo usa um PutItem que substitui todos os valores em vez de um UpdateItem, mas o mesmo conceito se aplica ao bloco de declarações condition.

Filtrar informações

Pode haver casos onde não é possível controlar a resposta da fonte de dados, mas você não deseja enviar informações desnecessárias aos clientes sobre uma gravação ou leitura bem-sucedida da fonte de dados. Nesses casos, você pode filtrar as informações usando um modelo de mapeamento de resposta.

Por exemplo, suponha que você não tenha um índice apropriado na tabela do DynamoDB da publicação de blog (como um índice em Author). É possível usar o seguinte resolvedor:


import { util, Context } from '@aws-appsync/utils';
import { get } from '@aws-appsync/utils/dynamodb';

export function request(ctx) {
	return get({ key: { ctx.args.id } });
}

export function response(ctx) {
	if (ctx.result.author === ctx.identity.username) {
		return ctx.result;
	}
	return null;
}

O manipulador de solicitações busca o item mesmo que o chamador não seja o autor que criou a publicação. Para evitar que isso exiba todos os dados, o manipulador de respostas verifica se o chamador corresponde ao autor do item. Se o chamador não corresponder a essa verificação, apenas uma resposta nula é retornada.

Acesso à fonte de dados

AWS AppSync se comunica com fontes de dados usando funções e políticas de acesso do Identity and Access Management (IAM). Se você estiver usando uma função existente, uma Política de Confiança precisará ser adicionada AWS AppSync para que você possa assumir a função. A relação de confiança terá a seguinte aparência:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "appsync.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

É importante restringir a política de acesso no perfil para ter permissões apenas para atuar sobre o conjunto mínimo de recursos necessários. Ao usar o AppSync console para criar uma fonte de dados e criar uma função, isso é feito automaticamente para você. No entanto, ao usar um modelo de amostra incorporado do console do IAM para criar uma função fora do AWS AppSync console, as permissões não serão automaticamente reduzidas ao escopo de um recurso, e você deve realizar essa ação antes de mover seu aplicativo para produção.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Usando variáveis de ambiente em AWS AppSync

Casos de uso de autorização

Autorização e autenticação

Tipos de autorização

Autorização API_KEY

nota

Autorização do AWS_LAMBDA

Atenção

nota

Importante

nota

Como contornar as limitações de autorização de tokens do SigV4 e OIDC

Autorização do AWS_IAM

Autorização do OPENID_CONNECT

Autorização do AMAZON_COGNITO_USER_POOLS

Usar modos de autorização adicionais

Controle de acesso refinado

Filtrar informações

Acesso à fonte de dados