Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Configuración de la autorización y la autenticación para proteger su GraphQL APIs

AWS AppSync ofrece los siguientes tipos de autorización para proteger GraphQLAPIs: API claves, Lambda, IAM OpenID Connect y Cognito User Pools. Cada opción proporciona un método de seguridad diferente:

Tipos de autorización

Existen cinco formas de autorizar que las aplicaciones interactúen con tu AWS AppSync GraphQLAPI. Para especificar el tipo de autorización que va a utilizar, especifique uno de los siguientes valores de tipo de autorización en su CLI llamada AWS AppSync API o llamada:

Estos tipos de autorización básicos funcionan para la mayoría de desarrolladores. Para casos de uso más avanzados, puede añadir modos de autorización adicionales a través de la consolaCLI, el y AWS CloudFormation. Para modos de autorización adicionales, AWS AppSync proporciona un tipo de autorización que toma los valores enumerados anteriormente (es decir API_KEYAWS_LAMBDA,AWS_IAM,OPENID_CONNECT, yAMAZON_COGNITO_USER_POOLS).

Al especificar API_KEY, AWS_LAMBDA o AWS_IAM como tipo de autorización principal o predeterminado, no puede especificarlos de nuevo como uno de los modos de autorización adicionales. Del mismo modo, no puede duplicar API_KEY, AWS_LAMBDA ni AWS_IAM dentro de modos de autorización adicionales. Puede utilizar diferentes proveedores de OpenID Connect y grupos de usuarios de Amazon Cognito. Sin embargo, no puede utilizar proveedores de OpenID Connect o grupos de usuarios de Amazon Cognito duplicados entre el modo de autorización predeterminado y cualquiera de los modos de autorización adicionales. Puede especificar diferentes clientes para el proveedor de OpenID Connect o el grupo de usuarios de Amazon Cognito mediante la expresión regular de configuración correspondiente.

API_KEYautorización

Los no autenticados APIs requieren una regulación más estricta que los autenticados. APIs Una forma de controlar la limitación de los puntos finales de GraphQL no autenticados es mediante el uso de claves. API Una API clave es un valor codificado en la aplicación que el AWS AppSync servicio genera al crear un punto final de GraphQL no autenticado. Puedes girar API las claves desde la consola, desde o desde la CLI referencia.AWS AppSync API

Console

1. Inicie sesión en la AppSyncconsola AWS Management Console y ábrala.

   1. En el APIspanel de control, elige tu GraphQLAPI.

   2. En la barra lateral, seleccione Configuración.

2. En el modo de autorización predeterminado, selecciona la APIclave.

3. En la tabla de APIclaves, seleccione Añadir API clave.

   Se generará una nueva API clave en la tabla.

   1. Para eliminar una API clave antigua, selecciónela API en la tabla y, a continuación, elija Eliminar.

4. Elija Guardar en la parte inferior de la página.

CLI

1. Si aún no lo ha hecho, configure su acceso a AWS CLI. Para obtener más información, consulte Fundamentos de configuración.

2. Cree un API objeto GraphQL ejecutando el update-graphql-apicomando.

   Deberá escribir dos parámetros para este comando concreto:

   1. El api-id de tu GraphQLAPI.

   2. Lo nuevo name de tu. API Puede utilizar el mismo name.

   3. El authentication-type, que será API_KEY.

   nota

   Hay otros parámetros, como los Region que deben configurarse, pero normalmente se ajustarán de forma predeterminada a sus valores CLI de configuración.

   Un comando de ejemplo puede tener este aspecto:

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

   Se devolverá un resultado enCLI. A continuación, se muestra un ejemplo enJSON:

   {
       "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"
       }
   }

APIlas claves se pueden configurar hasta 365 días y puedes extender una fecha de caducidad existente hasta otros 365 días a partir de ese día. APILas claves se recomiendan para fines de desarrollo o para casos de uso en los que sea seguro exponer a un públicoAPI.

En el cliente, la API clave se especifica en el encabezadox-api-key.

Por ejemplo, si API_KEY es 'ABC123', puede enviar una consulta de GraphQL mediante curl, como se indica a continuación:

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

AWS_LAMBDAautorización

Puede implementar su propia lógica de API autorización mediante una AWS Lambda función. Puede usar una función de Lambda para su autorizador principal o secundario, pero solo puede haber una función de autorización de Lambda por cada uno. API Cuando se utilizan funciones de Lambda para la autorización, es aplicable lo siguiente:

Por ejemplo, si su token de autorización es 'ABC123', puede enviar una consulta de GraphQL mediante curl, como se indica a continuación:

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

Las funciones de Lambda se invocan antes de cada consulta o mutación. El valor devuelto se puede almacenar en caché en función del API ID y el token de autenticación. De forma predeterminada, el almacenamiento en caché no está activado, pero se puede activar a API nivel o configurando el ttlOverride valor en el valor devuelto por una función.

Si lo desea, puede especificar una expresión regular que valide los tokens de autorización antes de que se llame a la función. Estas expresiones regulares se utilizan para validar que un token de autorización tiene el formato correcto antes de llamar a la función. Cualquier solicitud que utilice un token que no coincida con esta expresión regular se rechazará automáticamente.

Las funciones Lambda utilizadas para la autorización requieren que se appsync.amazonaws.com les aplique una política principal que permita AWS AppSync llamarlas. Esta acción se realiza automáticamente en la AWS AppSync consola; la AWS AppSync consola no elimina la política. Para obtener más información sobre cómo adjuntar políticas a las funciones de Lambda, consulte Políticas basadas en recursos en la Guía para desarrolladores. AWS Lambda

La función de Lambda que especifique recibirá un evento con la siguiente 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
    }
}

El event objeto contiene los encabezados que se enviaron en la solicitud desde el cliente de la aplicación a. AWS AppSync

La función de autorización debe devolver al menos isAuthorized un booleano que indique si la solicitud está autorizada. AWS AppSync reconoce las siguientes claves devueltas por las funciones de autorización de Lambda:

Para añadir una función de Lambda como modo de autorización predeterminado en AWS AppSync:

Console

1. Inicie sesión en la AWS AppSync consola y navegue hasta la API que desee actualizar.

2. Navegue hasta la página de configuración de suAPI.

   Cambie la autorización API de nivel A AWS Lambda.

3. Elija Lambda Región de AWS y Lambda contra la ARN que desee autorizar las API llamadas.

   nota

   Se añadirá automáticamente la política principal correspondiente, lo que permitirá a AWS AppSync llamar a la función de Lambda.

4. Si lo desea, configure la expresión regular de validación de la respuesta TTL y el token.

AWS CLI

1. Adjunte la política siguiente a la función de Lambda que se esté utilizando:

   aws lambda add-permission --function-name "my-function" --statement-id "appsync" --principal appsync.amazonaws.com --action lambda:InvokeFunction --output text 

   importante

   Si quieres que la política de la función se bloquee en un único GraphQLAPI, puedes ejecutar este comando:

   aws lambda add-permission --function-name “my-function” --statement-id “appsync” --principal appsync.amazonaws.com --action lambda:InvokeFunction --source-arn “<my AppSync API ARN>” --output text

2. Actualice su AWS AppSync API para usar la función Lambda dada ARN como autorizador:

   aws appsync update-graphql-api --api-id example2f0ur2oid7acexample --name exampleAPI --authentication-type AWS_LAMBDA --lambda-authorizer-config authorizerUri="arn:aws:lambda:us-east-2:111122223333:function:my-function"

   nota

   También puede incluir otras opciones de configuración, como la expresión regular del token.

En el siguiente ejemplo se describe una función de Lambda que demuestra los distintos estados de autenticación y error que puede tener una función de Lambda cuando se utiliza como mecanismo de autorización de 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 {}

Eludir las limitaciones de autorización de SigV4 y de token OIDC

Se pueden usar los siguientes métodos para evitar el problema de no poder usar su firma o OIDC token de SigV4 como token de autorización de Lambda cuando ciertos modos de autorización están habilitados.

Si desea utilizar la firma SigV4 como token de autorización de Lambda cuando AWS_IAM los modos de autorización AWS_LAMBDA y estén habilitados AWS AppSync para, haga API lo siguiente:

Si desea utilizar el OIDC token como token de autorización de Lambda cuando el modo de OPENID_CONNECT autorización o los modos de AWS_LAMBDA autorización AMAZON_COGNITO_USER_POOLS y estén habilitados para AWS AppSync API, haga lo siguiente:

AWS_IAMautorización

Este tipo de autorización aplica el proceso de AWS firma de la versión 4 en API GraphQL. Puede asociar las políticas de acceso de Identity and Access Management (IAM) a este tipo de autorización. Su aplicación puede beneficiarse de esta asociación mediante el uso de una clave de acceso (que se compone de un ID de clave de acceso y una clave de acceso secreta) o mediante el uso de credenciales temporales con una vida útil corta proporcionadas por las identidades federadas de Amazon Cognito.

Si desea un rol que pueda realizar todas las operaciones de datos:

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

Puede encontrarlo en la página API principal YourGraphQLApiId de la AppSync consola, justo debajo del nombre de suAPI. También puedes recuperarlo conCLI: aws appsync list-graphql-apis

Si desea restringir el acceso a determinadas operaciones de GraphQL, puede hacerlo para los campos raíz Query, Mutation y Subscription.

{
   "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 ejemplo, supongamos que tiene el siguiente esquema y desea restringir el acceso a todas las publicaciones:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

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

La IAM política correspondiente a un rol (que podría adjuntar a un grupo de identidades de Amazon Cognito, por ejemplo) tendría el siguiente aspecto:

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

OPENID_CONNECT autorización

Este tipo de autorización aplica los tokens OpenID connect OIDC () proporcionados por OIDC un servicio compatible. Su aplicación puede aprovechar los usuarios y los privilegios definidos por su OIDC proveedor para controlar el acceso.

Un emisor URL es el único valor de configuración obligatorio que se le proporciona AWS AppSync (por ejemplo,https://auth.example.com). URLDebe poder direccionarse a través de. HTTPS AWS AppSync se /.well-known/openid-configuration anexa al emisor URL y localiza la configuración de OpenID según la especificación OpenID Connect https://auth.example.com/.well-known/openid-configuration Discovery. En este momento, espera recuperar un documento que cumpla con los requisitos RFC5785. JSON URL Este JSON documento debe contener una jwks_uri clave que apunte al documento del conjunto de claves JSON web (JWKS) con las claves de firma. AWS AppSync requiere JWKS que contenga JSON los campos de kty ykid.

AWS AppSync admite una amplia gama de algoritmos de firma.

Le recomendamos que utilice los RSA algoritmos. Los tokens emitidos por el proveedor deben incluir la hora a la que se emitió el token (iat) y también pueden incluir la hora en que se autenticó (auth_time). Puede proporcionar TTL valores para la hora de emisión (iatTTL) y la hora de autenticación (authTTL) en la configuración de OpenID Connect para una validación adicional. Si su proveedor autoriza varias aplicaciones, también puede proporcionar una expresión regular (clientId) que se utiliza para autorizar por ID de cliente. Cuando clientId está presente en la configuración de OpenID Connect, AWS AppSync valida la afirmación exigiendo que coincida con la clientId afirmación aud o con la azp afirmación del token.

Para validar varios clientes, IDs utilice el operador de canalización («|»), que es una «o» en una expresión regular. Por ejemplo, si su OIDC aplicación tiene cuatro clientes con un cliente, IDs como 0A1S2D, 1F4G9H, 1J6L4B y 6, para validar solo los tres primeros clientes, debe colocar 1F4G9H|1J6L4B|6 GS5MG en el campo de ID de cliente. IDs GS5MG

AMAZON_COGNITO_USER_POOLS autorización

Este tipo de autorización aplica los OIDC tokens proporcionados por los grupos de usuarios de Amazon Cognito. Su aplicación puede aprovechar los usuarios y grupos de sus grupos de usuarios y de otros grupos de usuarios de otra AWS cuenta y asociarlos a campos de GraphQL para controlar el acceso.

Si utiliza agrupaciones de usuarios de Amazon Cognito, puede crear grupos a los que pertenecen los usuarios. Esta información está codificada en un JWT token al que la aplicación envía AWS AppSync en un encabezado de autorización al enviar operaciones de GraphQL. Puede utilizar directivas de GraphQL en el esquema para controlar qué grupos pueden invocar cuáles solucionadores para un campo. De este modo otorgará un acceso más controlado a los usuarios.

Por ejemplo, suponga que tiene el siguiente esquema de GraphQL:

schema {
   query: Query
   mutation: Mutation
}

type Query {
   posts:[Post!]!
}

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

Si tiene dos grupos en las agrupaciones de usuarios de Amazon Cognito (blogueros y lectores) y desea restringir el acceso de los lectores para que no puedan añadir nuevas entradas, entonces su esquema debería tener el siguiente aspecto:

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"])
}
...

Ten en cuenta que puedes omitir la @aws_auth directiva si quieres usar de forma predeterminada una grant-or-deny estrategia de acceso específica. Puedes especificar la grant-or-deny estrategia en la configuración del grupo de usuarios al crear tu GraphQL API mediante la consola o mediante el siguiente comando: 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"}'

Uso de modos de autorización adicionales

Al añadir modos de autorización adicionales, puede configurar directamente la configuración de autorización en el API nivel de AWS AppSync GraphQL (es decir, el authenticationType campo que puede configurar directamente en el GraphqlApi objeto) y actúa como predeterminado en el esquema. Esto significa que cualquier tipo que no tenga una directiva específica debe superar la configuración de autorización de API nivel.

En el nivel de esquema, puede especificar modos de autorización adicionales mediante las directivas del esquema. Puede especificar modos de autorización en los campos individuales del esquema. Por ejemplo, para la autorización API_KEY, debería utilizar @aws_api_key en los campos o las definiciones de tipo de objeto del esquema. Las siguientes directivas se admiten en los campos y las definiciones de tipo de objeto del esquema:

No puede utilizar la directiva @aws_auth junto con modos de autorización adicionales. @aws_auth funciona únicamente en el contexto de la autorización AMAZON_COGNITO_USER_POOLS sin modos de autorización adicionales. No obstante, puede utilizar la directiva @aws_cognito_user_pools en lugar de la directiva @aws_auth con los mismos argumentos. La principal diferencia entre las dos es que puede especificar @aws_cognito_user_pools en cualquier campo y definición de tipo de objeto.

Para comprender cómo funcionan los modos de autorización adicionales y cómo se pueden especificar en un esquema, observemos el siguiente 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 este esquema, suponga que AWS_IAM es el tipo de autorización predeterminado en AWS AppSync GraphQLAPI. Esto significa que los campos que no tienen una directiva se protegen mediante AWS_IAM. Por ejemplo, es el caso del campo getPost del tipo Query. Las directivas del esquema le permiten utilizar más de un modo de autorización. Por ejemplo, puedes API_KEY configurarlo como un modo de autorización adicional en AWS AppSync GraphQL API y puedes marcar un campo mediante la @aws_api_key directiva (por ejemplo, getAllPosts en este ejemplo). Las directivas funcionan a nivel de campo, por lo que tiene que permitir que API_KEY también acceda al tipo Post. Puede hacerlo marcando cada campo del tipo Post con una directiva o marcando el tipo Post con la directiva @aws_api_key.

Para restringir más el acceso a los campos del tipo Post, puede utilizar directivas contra los campos individuales del tipo Post como se muestra a continuación.

Por ejemplo, puede añadir un campo restrictedContent al tipo Post y restringir el acceso a él mediante la directiva @aws_iam. Las solicitudes autenticadas por AWS_IAM podrían acceder a restrictedContent, pero las solicitudes de API_KEY no.

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
}
...

Control de acceso detallado

La información anterior muestra cómo restringir o conceder acceso a determinados campos de GraphQL. Si desea establecer controles de acceso a los datos en función de determinadas condiciones (por ejemplo, en función del usuario que realiza una llamada y de si es propietario de los datos), puede utilizar plantillas de mapeo en los solucionadores. También puede aplicar una lógica de negocio más compleja, como describimos más adelante en Filtrado de información.

En esta sección se muestra cómo establecer controles de acceso a los datos mediante una plantilla de asignación de solucionadores de DynamoDB.

Antes de continuar, si no está familiarizado con las plantillas de mapeo de Resolver AWS AppSync, puede revisar la referencia de plantillas de mapeo de Resolver y la referencia de plantillas de mapeo de Resolver para DynamoDB.

En el siguiente ejemplo con DynamoDB, imagine que utiliza el esquema de publicación del blog anterior y que solo los usuarios que han creado publicaciones tienen permiso para editarlas. El proceso de evaluación del usuario consistiría en obtener las credenciales de su aplicación, por ejemplo mediante las agrupaciones de usuarios de Amazon Cognito, y transferir entonces dichas credenciales como parte de una operación de GraphQL. A continuación, la plantilla de mapeo sustituirá un valor de las credenciales (como el nombre de usuario) en una instrucción condicional que entonces se comparará con un valor de la base de datos.

Para agregar esta funcionalidad, añada el campo de GraphQL editPost como se indica a continuación:

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!
}
...

La plantilla de mapeo del solucionador para editPost (que se muestra en un ejemplo al final de esta sección) debe realizar una comprobación lógica con el almacén de datos para permitir editar una publicación únicamente al usuario que la creó. Dado que se trata de una operación de edición, se corresponde con un UpdateItem de DynamoDB. Puede realizar una comprobación condicional antes de realizar esta acción utilizando el contexto transferido para validar la identidad del usuario. Esto se almacena en un objeto Identity que tiene los siguientes valores:

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

Para utilizar este objeto en una llamada de UpdateItem de DynamoDB, debe almacenar la información de identidad del usuario en la tabla para poder compararla. En primer lugar, la mutación addPost debe almacenar el creador. En segundo lugar, la mutación editPost debe realizar la comprobación condicional antes de actualizar.

El siguiente es un ejemplo del código de solucionador para addPost que almacena la identidad del usuario como una columna 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 el atributo Author se rellena a partir del objeto Identity, que procede de la aplicación.

Por último, el siguiente es un ejemplo del código de solucionador para editPost, que solo actualiza el contenido de la publicación del blog si la solicitud proviene del usuario que la creó:

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;

En este ejemplo se utiliza PutItem, lo que sobrescribe todos los valores, en lugar de UpdateItem, pero en ambos casos se aplica el mismo principio en el bloque de instrucciones condition.

Filtrado de información

Puede haber casos en los que, aunque no se pueda controlar la respuesta del origen de datos, no se desee enviar información innecesaria a los clientes tras una solicitud de escritura o lectura correctas al origen de datos. En estos casos puede filtrar la información utilizando una plantilla de mapeo de respuesta.

Por ejemplo, imagine que no dispone de un índice adecuado en una tabla DynamoDB de publicaciones de blog (por ejemplo, un índice por Author). Puede utilizar el siguiente solucionador:

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;
}

El controlador de solicitudes obtiene el elemento incluso si la intermediario no es el autor que creó la publicación. Para evitar que se devuelvan todos los datos, el controlador de respuestas comprueba que el intermediario coincide con el autor del elemento. Si el intermediario no coincide con esta comprobación, solo se devuelve una respuesta nula.

Acceso al origen de datos

AWS AppSync se comunica con las fuentes de datos mediante las funciones y políticas de acceso de Identity and Access Management (IAM). Si utiliza un rol existente, es necesario añadir una política de confianza AWS AppSync para poder asumir el rol. La relación de confianza tendrá este aspecto:

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

Es importante reducir el ámbito de la política de acceso para que el rol solo tenga permisos para actuar sobre el conjunto mínimo de recursos necesario. Al utilizar la AppSync consola para crear una fuente de datos y crear un rol, esto se hace automáticamente. Sin embargo, si utilizas una plantilla de ejemplo integrada en la IAM consola para crear un rol fuera de la AWS AppSync consola, los permisos no se limitarán automáticamente a un recurso, por lo que debes realizar esta acción antes de pasar la aplicación a producción.