Tipos de autorización Autorización API_KEY Autorización de AWS_LAMBDA Autorización AWS_IAM Autorización OPENID_CONNECT Autorización AMAZON_COGNITO_USER_POOLS Uso de modos de autorización adicionales Control de acceso detallado Filtrado de información Acceso al origen de datos

Configuración de la autorización y la autenticación para proteger las API de GraphQL

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

Autorización de claves de API: controla la limitación de las API no autenticadas, lo que proporciona una opción de seguridad sencilla.
Autorización de Lambda: habilita una lógica de autorización personalizada, que explica las entradas y salidas de las funciones en detalle.
Autorización de IAM: utiliza el proceso de firma exclusivo de la versión 4 de la firma de AWS, que permite un control de acceso detallado a través de políticas de IAM.
Autorización de OpenID Connect: se integra con los servicios compatibles con OIDC para la autenticación de usuarios.
Grupos de usuarios de Cognito: implementa el control de acceso basado en grupos mediante las características de administración de usuarios de Cognito.

Tipos de autorización

Existen cuatro maneras de autorizar la interacción de las aplicaciones con la API de GraphQL de AWS AppSync. Para especificar el tipo de autorización que se debe utilizar, especifique uno de los siguientes valores de tipo de autorización en la API de AWS AppSync o en la llamada a la CLI:

API_KEY

Para utilizar claves de API.
AWS_LAMBDA

Para usar una función de AWS Lambda.
AWS_IAM

Para usar permisos de AWS Identity and Access Management (IAM).
OPENID_CONNECT

Para utilizar su proveedor de OpenID Connect.
AMAZON_COGNITO_USER_POOLS

Para utilizar con un grupo de usuarios de Amazon Cognito.

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 mediante la consola, la CLI y AWS CloudFormation. Con modos de autorización adicionales, AWS AppSync proporciona un tipo de autorización que adopta los valores indicados anteriormente (es decir, API_KEY, AWS_LAMBDA, AWS_IAM, OPENID_CONNECT y AMAZON_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.

Al guardar los cambios en la configuración de API, AWS AppSync comienza a propagar los cambios. Hasta que el cambio de configuración se propague, AWS AppSync continúa ofreciendo el contenido de la configuración anterior. Una vez propagado el cambio de configuración, AWS AppSync comienza a ofrecer el contenido inmediatamente en función de la configuración nueva. Aunque AWS AppSync propague los cambios de una API, no podemos determinar si una API está ofreciendo su contenido en función de la configuración anterior o de la nueva.

Autorización API_KEY

Las API sin autenticar requieren un control de los límites más estricto que las API autenticadas. Una forma de supervisar la limitación controlada de puntos de enlace de GraphQL sin autenticar es mediante el uso de claves de API. Una clave de API es un valor de código literal en la aplicación generado por el servicio de AWS AppSync cuando se crea un punto de conexión de GraphQL sin autenticar. Puede rotar las claves de API desde la consola, desde la CLI o con la referencia de la API de AWS AppSync.

Console

Inicie sesión en la Consola de administración de AWS y abra la consola de AppSync.
1. En el panel de API, seleccione su API de GraphQL.
2. En la barra lateral, seleccione Configuración.
En Modo de autorización predeterminado, seleccione Clave de API.
En la pestaña Claves de API, elija Agregar clave de API.

Se generará una nueva clave de API en la tabla.
1. Para eliminar una clave de API antigua, selecciónela en la tabla y, a continuación, elija Eliminar.
Elija Guardar en la parte inferior de la página.

CLI

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

Cree un objeto de API de GraphQL ejecutando el comando update-graphql-api.

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

El api-id de su API de GraphQL.
El nuevo name de su API. Puede utilizar el mismo name.
El authentication-type, que será API_KEY.

nota

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

Un comando de ejemplo puede tener este aspecto:


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

Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo en 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"
    }
}

Las claves de API se pueden configurar con una duración de hasta 365 días que pueden ampliarse hasta otros 365 días a partir de la fecha de vencimiento. Las claves de API se recomiendan con fines de desarrollo o para casos de uso en los que es seguro exponer una API pública.

En el cliente, la clave de API se especifica mediante el encabezado x-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

Autorización de AWS_LAMBDA

Puede implementar su propia lógica de autorización de API mediante una función AWS Lambda. 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 API. Cuando se utilizan funciones de Lambda para la autorización, es aplicable lo siguiente:

Si la API tiene habilitados los modos de autorización AWS_LAMBDA y AWS_IAM , la firma SigV4 no se puede utilizar como token de autorización de AWS_LAMBDA.
Si la API tiene habilitados los modos de autorización AWS_LAMBDA y OPENID_CONNECT, o el modo de autorización AMAZON_COGNITO_USER_POOLS activado, el token OIDC no se puede utilizar como token de autorización de AWS_LAMBDA. Tenga en cuenta que el token OIDC puede ser un esquema Bearer.
Una función de Lambda no debe devolver más de 5 MB de datos contextuales para los solucionadores.

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 ID de la API y el token de autenticación. Cuando la respuesta de un autorizador Lambda es inferior a 1 048 576 bytes, AWS AppSync almacena en caché la respuesta para las solicitudes posteriores. Si la respuesta del autorizador Lambda es igual o superior a 1 048 576 bytes, AWS AppSync no almacena en caché la respuesta e invoca al autorizador Lambda para cada solicitud entrante. Para optimizar el rendimiento y minimizar los costos de invocación de Lambda, le recomendamos que limite las respuestas del autorizador de Lambda a 1 048 576 bytes. De forma predeterminada, el almacenamiento en caché no está activado, pero se puede habilitar en la API o configurando el valor ttlOverride en un valor de retorno de 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 de Lambda utilizadas para la autorización requieren que se les aplique una política principal para appsync.amazonaws.com que permita que AWS AppSync las llame. Esta acción se realiza automáticamente en la consola AWS AppSync; la consola AWS AppSync no elimina la política. Para obtener más información sobre cómo asociar políticas a funciones de Lambda, consulte Políticas basadas en recursos en la Guía para desarrolladores de 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 objeto event 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 valor booleano que indica si la solicitud está autorizada. AWS AppSync reconoce las siguientes claves devueltas por las funciones de autorización de Lambda:

nota

AWS AppSync establece el valor del operationName en el requestContext para una operación de conexión de WebSocket en “DeepDish:Connect”.

isAuthorized (valor booleano, obligatorio)

Un valor booleano que indica si el valor de authorizationToken está autorizado a realizar llamadas a la API de GraphQL.

Si este valor es true, la ejecución de la API de GraphQL continúa. Si este valor es false, se genera UnauthorizedException

deniedFields (lista de cadenas, opcional)

Una lista que se cambia forzosamente a null, incluso si un solucionador ha devuelto un valor.

Cada elemento es un ARN de campo totalmente cualificado en forma de arn:aws:appsync:us-east-1:111122223333:apis/GraphQLApiId/types/TypeName/fields/FieldName o una forma abreviada de TypeName.FieldName. La forma completa de ARN debe usarse cuando dos API comparten un autorizador de funciones de Lambda y puede haber ambigüedad entre los tipos y campos comunes entre las dos API.

resolverContext (objeto JSON, opcional)

Un objeto JSON visible como $ctx.identity.resolverContext en las plantillas de solucionadores. Por ejemplo, si un solucionador devuelve la estructura siguiente:


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

El valor de ctx.identity.resolverContext.apple en las plantillas de solucionador será "very green". El objeto resolverContext solo admite pares clave-valor. No se admiten las claves anidadas.

aviso

El tamaño total de este objeto JSON no debe superar los 5 MB.

ttlOverride (entero, opcional): El número de segundos durante los que se debe almacenar una respuesta en caché. Si no se devuelve ningún valor, se utiliza el valor de la API. Si es 0, la respuesta no se almacena en caché.

Los autorizadores de Lambda tienen un tiempo de espera de 10 segundos. Recomendamos diseñar funciones para que se ejecuten en el menor tiempo posible a fin de escalar el rendimiento de su API.

Varias API de AWS AppSync pueden compartir una sola función de Lambda de autenticación. No se permite el uso de autorizadores entre cuentas.

Al compartir una función de autorización entre varias API, tenga en cuenta que los nombres de campo abreviados (typename.fieldname) pueden ocultar campos de forma inadvertida. Para eliminar la ambigüedad de un campo en deniedFields, puede especificar un ARN de campo inequívoco en forma de arn:aws:appsync:region:accountId:apis/GraphQLApiId/types/typeName/fields/fieldName.

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

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

Elusión de las limitaciones de autorización de los tokens SiGv4 y OIDC

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

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

Para crear un nuevo token de autorización de Lambda, añada sufijos o prefijos aleatorios a la firma SigV4.
Para recuperar la firma SiGv4 original, actualice la función de Lambda eliminando los prefijos o sufijos aleatorios del token de autorización de Lambda. A continuación, utilice la firma SigV4 original para la autenticación.

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

Para crear un nuevo token de autorización de Lambda, añada sufijos o prefijos aleatorios al token OIDC. El token de autorización de Lambda no debe contener un prefijo de esquema Bearer.
Para recuperar el token OIDC original, actualice la función de Lambda eliminando los prefijos o sufijos aleatorios del token de autorización de Lambda. A continuación, utilice el token OIDC original para la autenticación.

Autorización AWS_IAM

Este tipo de autorización aplica el proceso de firma Signature Version 4 de AWS a la API de GraphQL. Con este tipo de autorización puede asociar políticas de acceso de Identity and Access Management (IAM). 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:

Encontrará YourGraphQLApiId en la página principal de lista de API de la consola de AppSync, justo bajo el nombre de la API. También puede obtenerla desde la CLI: 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.

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 política de IAM correspondiente a un rol (que podría asociar, por ejemplo, a un grupo de identidades de Amazon Cognito) tendría un aspecto similar al siguiente:

Autorización OPENID_CONNECT

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

Una URL de emisor es el único valor de configuración necesario que debe proporcionar a AWS AppSync (por ejemplo, https://auth.example.com). Debe ser posible direccionar esta URL a través de HTTPS. AWS AppSync añade /.well-known/openid-configuration a la URL del emisor y ubica la configuración de OpenID en https://auth.example.com/.well-known/openid-configuration conforme a la especificación OpenID Connect Discovery. Al hacerlo, espera obtener un documento JSON conforme a RFC5785 en la URL. Este documento JSON debe incluir una clave jwks_uri que apunte al documento JSON Web Key (JWKS) con las claves de firma. AWS AppSync requiere que el JWKS contenga los campos JSON de kty y kid.

AWS AppSync admite una amplia gama de algoritmos de firma.

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

Le recomendamos utilizar los algoritmos de RSA. 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 valores de TTL para el tiempo de emisión (iatTTL) y para el tiempo 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 el clientId está presente en la configuración de OpenID Connect, AWS AppSync valida la reclamación exigiendo que el clientId coincida con la reclamación aud o azp en el token.

Para validar varios ID de cliente, utilice el operador de canalización (“|”) que equivale a "o" en una expresión regular. Por ejemplo, si una aplicación OIDC tiene cuatro clientes con los ID 0A1S2D, 1F4G9H, 1J6L4B y 6GS5MG, para que solo se validen los tres últimos habrá que especificar 1F4G9H|1J6L4B|6GS5MG en el campo de ID de cliente.

Si una API está configurada con varios tipos de autorización, AWS AppSync valida el emisor (afirmación iss) presente en el token JWT a partir de los encabezados de las solicitudes comparándolo con la URL del emisor especificada en la configuración de la API. Sin embargo, cuando una API se configura solo con la autorización de OPENID_CONNECT, AWS AppSync omite este paso de validación de la URL del emisor.

Autorización AMAZON_COGNITO_USER_POOLS

Este tipo de autorización aplica tokens de OIDC proporcionados por grupos de usuarios de Amazon Cognito. Su aplicación puede aprovechar los usuarios y grupos tanto de sus propios grupos de usuarios como de los grupos de usuarios de otra cuenta de AWS y asociarlos con 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 se codifica en un token JWT que la aplicación transmite 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"])
}
...

Tenga en cuenta que puede omitir la directiva @aws_auth si desea aplicar una estrategia de concesión o de denegación de acceso específica de manera predeterminada. Puede especificar dicha estrategia en la configuración del grupo de usuarios al crear la API de GraphQL a través de la consola o mediante el siguiente comando de la 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 establecer directamente la configuración de autorización en el nivel de la API de AWS AppSync GraphQL (es decir, el campo authenticationType que puede configurar directamente en el objeto GraphqlApi), que actúa como valor predeterminado en el esquema. Esto supone que cualquier tipo que no tenga una directiva específica tiene que transmitir la configuración de autorización de nivel de API.

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:

@aws_api_key: para especificar que el campo está autorizado por API_KEY.
@aws_iam: para especificar que el campo está autorizado por AWS_IAM.
@aws_oidc: para especificar que el campo está autorizado por OPENID_CONNECT.
@aws_cognito_user_pools: para especificar que el campo está autorizado por AMAZON_COGNITO_USER_POOLS.
@aws_lambda: para especificar que el campo está autorizado por AWS_LAMBDA.

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

En este esquema, asumimos que AWS_IAM es el tipo de autorización predeterminado de la API de AWS AppSync GraphQL. 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, puede tener API_KEY configurado como un modo de autorización adicional en la API de AWS AppSync GraphQL y marcar un campo mediante la directiva @aws_api_key (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 asignación de AWS AppSync es recomendable repasar las secciones Referencia de plantillas de asignación de solucionadores y Referencia de plantillas de asignación de solucionadores 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.

Diagram showing authentication flow from user login to database operation using Servicios de AWS.

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 los orígenes de datos mediante roles y políticas de acceso de Identity and Access Management (IAM). Si utiliza un rol existente, deberá agregar una política de confianza para que AWS AppSync lo adopte. La relación de confianza tendrá este aspecto:

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. Cuando se utiliza la consola de AppSync para crear un origen de datos y un rol, esta operación se realiza automáticamente. Sin embargo, cuando se utiliza una plantilla de ejemplo integrada desde la consola de IAM para crear un rol fuera de la consola de AWS AppSync, los permisos no se reducen automáticamente al recurso, por lo que deberá hacerlo manualmente antes de instalar la aplicación en el entorno de producción.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Uso de variables de entorno

Casos de uso del control de acceso para proteger solicitudes y respuestas