I'm very new to AWS cognito. I want to send a mail on deleting a user from AWS cognito user pool. I learnt that there is a list of predefined event trigger sources for various user actions such as sign up, sign in, password change etc., but, there is no such event trigger sources for deleting a user. I found few similar questions posted and saw that using cognito sync trigger was recommended and when I tried to follow that, it asked me to select a cognito identity pool to proceed further but there is no identity pool used in my project.
Kindly let me know how can I trigger a lambda function on deleting a cognito user.
Identity pools are used for giving temporary access to you AWS Resources/Services, you can refer the docs
Amazon Cognito identity pools (federated identities) enable you to create unique identities for your users and federate them with identity providers. With an identity pool, you can obtain temporary, limited-privilege AWS credentials to access other AWS services.
Since your backend is not using any AWS resource, you can use AWS API Gateway for creating an endpoint which can be hit to trigger the lambda function, as Auth provider of the api you can use cognito. Here is the reference
Related
I am creating a web app using AWS amplify, and one of its features will be integration with AWS IoT for live MQTT data. I successfully setup Cognito to work with IoT, but there is one step that I currently have to do manually: attach the iot policy to a cognito identity. In all the AWS tutorials on this, they have you manually attach the policy for the user via the command line, but obviously in a production app this needs to be automated with something like a Lambda as part of the user signup flow. I know that lambda triggers are available with the user pools side of Cognito, but I don't see any documentation on them being available for identity pools. If I'm correct the user signup happens first in the user pool and then the identity pool, and since I need the identity ID to link to IoT, using user pool lambda triggers won't work for this. Of course I could always add this to my own API which is called after sign up, the only issue with that is that it relies on the client to call the API, which adds complexity, i.e. the client could disconnect after signup but before the API call is made, in which case the user would never get the policy attached. Is there any better server-side way to trigger this?
I am currently investigating the use of Federated Identities and from the many examples I have read, it seems to be a way to grant users temporary credentials to various AWS services. For my case, the API Gateway is all that the user will interact with, since the API server is the one making calls to other services like S3 and DynamoDB. I like how permissions are controlled using IAM, but I'm failing to see any other appeals of Federated Identities. User Pools itself already supports password/fb/google/etc sign in, the only downside I see with user pools is that I'll need to do the authorization manually in the API layer. Is there something else I am missing with Federated Identities? Is it worth it given my use of only API Gateways (externally).
It all depends on the way that you will secure your API Gateway endpoint.
If you secure your API using AWS IAM, you'll need a way to convert your authentication tokens in AWS IAM Roles. For that scenario you can use AWS Cognito Idp (not the User Pool) or AWS Federated Identities. The difference is: using AWS IAM Federated Identities you will need to call AWS STS AssumeRoleWithWebIdentity in your frontend code. If you use AWS Cognito Idp this is done for you. . (AWS strongly suggest that you use the Cognito Idp in that scenario)
If you secure your API using AWS Cognito User Pools you don't need to use AWS Federated Identities. You can connect API Gateway directly to AWS Cognito and the service will enforce the controls for you. In that case you'll need to have a Cognito User Pool.
You also have a choice to use Custom Authorizers. In that scenario you will implement a lambda function that will evaluate your request and decide if it is authorized or not. In the same way, you won't need federated identities.
And finally you have the API Key authorization, that you already mentioned that is not applicable to your use case.
I am an AWS newb, so please go easy on me :)
I have setup a proof of concept to proove out an authenticated API backed by lambda with the following components.
API Gateway -> backed by Lambda
Federated Identities backed by AWS Cognito UserPool
I have the authorizer setup in the API gateway to use the IAM role which is being provided by the Federated Identity pool.
I can see the identity (ap-southeast-2:<GUID>) coming through into the gateway ( using this in my integration request mapping template "$context.identity.cognitoIdentityId" ) from https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#context-variable-reference
From either the gateway or lambda how can I resolve the 'ap-southeast-2:<GUID>' back to the source identity which resides in the user pool. (E.g. Pull one of the custom attributes from it)
Other information if relevant, i'm using Amplify-AWS for the client calling into the API Gateway.
TIA.
As you're noticing, Cognito as an identity provider is not the same as Cognito as a user pool.
Federated Identities provide a way of giving someone identified access to your AWS resources. The identity_id the identity provider gives you can almost be thought of as a tracking code. CIP (Congito [Federated] Identity Provider) allows you to get an identity id by signing in through any number of providers (not just the user pool), and even by not signing in at all.
User Pools give you a way of managing users for your application (i.e. a set of usernames, emails, passwords, etc).
This is the reason getting from identity_id back to the user pool user is hard (because, there's no guarantee it is a user pool user, it could well be someone from Facebook).
From what you've said, however, the assumption that said identity_id came from a UserPool authentication is safe. This means you have two options:
The official way will be to use identity:GetOpenIdToken to convert identity_id (you can ignore the logins part of the request) into an OpenId token. You can then use this token against the userpools:GetUser end point. There's a few pitfalls here, like ensuring you authenticate with a scope that allows you to see all the attributes you care about.
Curiously, however, the value of cognitoAuthenticationProvider is not opaque, and can (unoffically) be decoded:
// Cognito authentication provider looks like:
// cognito-idp.us-east-1.amazonaws.com/us-east-1_xxxxxxxxx,cognito-idp.us-east-1.amazonaws.com/us-east-1_aaaaaaaaa:CognitoSignIn:qqqqqqqq-1111-2222-3333-rrrrrrrrrrrr
// Where us-east-1_aaaaaaaaa is the User Pool id
// And qqqqqqqq-1111-2222-3333-rrrrrrrrrrrr is the User Pool User Id
The above example, with more details about how you can then use this with userpools:AdminGetUser can be found here: https://serverless-stack.com/chapters/mapping-cognito-identity-id-and-user-pool-id.html
I can't see a good design for claims- or role-based authorization over an AWS PaaS (gateway/lambda) API. Right now, there seems to be a functionality blindspot regardless of how you combine the following:
gateway cognito user pool or custom authorizers
cognito identity pools used for web and user pool identity federation
IAM roles for gateway execution authorization
Specifically, the blindspot seems to be associating cognito identities with roles (more varied than keys and suffixes in dynamo and s3) based on user attributes in a way that:
doesn't require a custom endpoint in your API to vend IAM temp creds (and consequently using something other than the supplied and/or generated SDKs)
doesn't require authorization logic in every lambda function
doesn't require persisting the above mapping in dynamo, cognito sync, etc
doesn't layer or sequence a separate flow for authorization (e.g. separate token)
lets your users sign in using external idps
I assume the following is impossible or excessively hacky:
cognito user pools that overlap or moving users between pools to represent the configuration of their roles
directly getting cognito user pool attributes from congito identity pool identity tokens (GetOpenIdToken)
having a readily-modifiable client pick its own privileges (e.g. choose an IAM role)
running every request as dry-run in a custom authorizer or otherwise shadow-implementing IAM
securing actually role-specific IAM roles with some kind of shared secret, etc.
Here are some examples and their shortcomings:
A user logs in with user pool credentials and attempts to execute a gateway api method.
A cognito authorizer over gateway api methods would let me say autheticated-therefore-authorized and map attributes/claims into the integration request, still leaving it to the lambda function to implement actual authorization logic.
A custom authorizer won't automatically validate and parse a user pool token, but I could still do so and conditionally construct a role.
A user logs in with google+ credentials, having a user pool identity as well, and attempts to execute a gateway api method.
A cognito authorizer is useless.
A custom authorizer won't automatically validate and parse the google+ token, but I could still do so and conditionally construct a role. Only now I'd need to map this to a user pool identity manually. Cognito adds no value at all here -- just an awkward document database as a service.
A user logs in with google+ credentials, having a user pool identity as well, then gets an identity pool token (GetOpenIdToken) and attempts to execute a gateway api method.
A cognito authorizer is useless.
A custom authorizer won't automatically validate and parse the cognito identity token, but I could still do so and conditionally construct a role. I still need to do manual mapping because I won't get the user pool attributes with this intermediate token.
A user logs in with google+ credentials, having a user pool identity as well, then gets temp creds (GetCredentialsForIdentity) and attempts to execute a gateway api method.
The default authorizer is useless. You just get authenticated-therefore-authorized.
A cognito authorizer is useless.
A custom authorizer is useless.
The easiest solutions to most of these problems are in User Pools (i.e. using Lambda hooks in the auth flow to check privileges, attributes can be retrieved from the token an authentication generates...etc.), however your requirement that users can sign in with external providers is not currently supported.
From that, you can potentially use Cognito federated identities with user pools and external providers, but that brings up some awkwardness. Building in the privilege authentication into the user pools lambda hooks when multiple providers are available is awkward and forces the usage of user pools with other providers.
From that, I would say mapping privileges to identity id in some external storage is the way to go, using some external hook (Lambda?) with that id to assume a role and get credentials, but you mentioned you wouldn't want to do that.
I would agree that what you're aiming for is not absolutely possible as is. My recommendation might be to get in touch with an SA and see if they can help you design a complex solution that fulfills your requirements.
I am currently using AWS cognito for user authentication. Now i want to store partial information of the users in the user pool to DynamoDb table. Is there a way to relate Userpool data with DynamoDb ?
You can federate user pool with Cognito identity and get the scoped temporary credentials, you can use these credentials to connect to DynamoDB. This part of developer guide talks about this integration. integrating user pools with identity pools