RFC: Auth Enhancements - Admin Tasks

[undefobj]

Overview: Currently the Amplify CLI supports provisioning Cognito User Pools and Cognito Identity Pools with a handful of options such as:

• Creation of User Pools and Federation with Identity Pools o Default “best practice” settings for connecting to common services, as well as the ability to overwrite defaults
• Social Provider Federation with Cognito Identity
• IAM role scoping for unauthenticated Read/Write access

Customer feedback and interviews, as well as triaging common issues for building apps we have found that there are many common "administrative tasks" that we can automate and setup with enhancements to the CLI auth category, reducing the need to manually connect things within the AWS console. This RFC is a proposal for feedback on workflow and requirements as part of this effort.

Common asks/current feature plans: Below are the common asks we have heard from the community, please reply with a +1 or detailed comment on a feature if you have specific thoughts around how it should work:

• Cognito User Pools Hosted UI support

• Federation with the Cognito User Pools Hosted UI (this will be the default Federation path for Social Providers, and the returned OIDC token from User Pools will be used to get AWS credentials from Cognito Identity Pools).

• Triggers

  • Ability to select from common “Templates” and add them as User Pool Triggers. These are Lambda functions and will be written in NodeJS. The functions will be saved in your project directory so that you can edit them and push to the cloud.
  • Current proposed templates:
  • MFA w/ Captcha or QR code similar to this: https://aws.amazon.com/blogs/mobile/customizing-your-user-pool-authentication-flow/
  • Device tracking registration similar to this: https://aws.amazon.com/blogs/mobile/tracking-and-remembering-devices-using-amazon-cognito-your-user-pools/
  • Sign-Up email filtering (e.g. whitelist/blacklist email domains)
  • Email confirmation link instead of code: https://github.com/aws-amplify/amplify-js/issues/612
  • Auto-add to Group upon post registration (potentially using SAML claims)

• Fine-grained access control by dynamically assigning roles based on Group membership or rules/token claims. How would you like this to work in your developer workflow? If you’re unfamiliar with this capability you can read more here: https://aws.amazon.com/blogs/aws/new-amazon-cognito-groups-and-fine-grained-role-based-access-control-2/

  • Essentially this would allow you to dynamically control what groups/users could access specific GraphQL/REST APIs, S3 resources, chatbots, etc.

• Expand the CLI capabilities to automatically configure IAM “Read/Write” access for authenticated vs unauthenticated users:

  • Work on more categories besides Storage and REST. GraphQL is the highest asked at this point as it would help more customers create public/private applications.
  • Support finer-grained “Create/Read/Update/Delete” control rather than just “Read/Write”

• “Admin Queries” – While the JavaScript and native iOS/Android client libraries address common actions with Cognito from mobile or web apps sign-up, sign-in, etc.) there are certain actions that sometimes are useful to query against Cognito and, depending on your use case expose to an application. For instance “ListUsers” or “CreateGroup” might be necessary in your application (see https://github.com/aws-amplify/amplify-js/issues/2120). For this feature we would give you the ability to call a Lambda function either via a GraphQL or REST endpoint, and that Lambda would have capabilities to run these actions. The Lambda would be in your project so that you could augment it with your custom logic as your needs require, including having the client applications authenticate appropriately and only run certain actions if conditions are met.

  • As part of this we would investigate the feasibility of common workflow actions:
  • Lambda that moves a user from one group to another, for instance after a payment/milestone
  • Moving content from a "public" folder in an S3 bucket into a "private" folder if a user goes from unauthenticated into an authenticated state

Please comment with any additional thoughts not covered in the above list. Thank you.

[VividWombat]

One request I'd like to add to list. Not all apps want to have open signup. So I'd like ways to either invite a user to signup or create a new user (but not needing console/cli admin access)

Currently cognito allows for disabling user signup, but there's very little support for adding users outside of console/cli. as amplify is providing some very nice HOC for authentication, extending that would be nice. I'm thinking about signUpWithCode, where an invite can be sent via email, which contains an invite code that can be used.

Perhaps all we need right now is to enable user signups, but hide the signup form. Then create a new route to a form that has signups enabled. Not very secure perhaps, but could be done right now.

If you added signup invite codes, then having some analytics on those codes would be nice. Could be useful for tracking performance.

anyway, +1 on the recent progress with amplify. thanks for the great code

[selipso]

This issue may already be on your radar, but I've noticed that when using the browser in Incognito mode, AWS_IAM doesn't respect user-specific resources. It'll list all of that particular resource (effectively admin access) if you run the ListTodos query. However, when in a regular browser outside of incognito mode, the resources specific to the identity are listed properly. If it's not, please let me know and I can create one for you to link above.

[ceich]

This issue may already be on your radar, but I've noticed that when using the browser in Incognito mode, AWS_IAM doesn't respect user-specific resources. It'll list all of that particular resource (effectively admin access) if you run the ListTodos query. However, when in a regular browser outside of incognito mode, the resources specific to the identity are listed properly. If it's not, please let me know and I can create one for you to link above.

That sounds like a bug; please raise a new issue apart from this RFC thread.

[pechisworks]

For unauth/authenticated access i just want to mention that firebase did a great job with "Firebase Anonymous Authentication" https://firebase.google.com/docs/auth/web/anonymous-auth https://www.youtube.com/watch?v=ApG8L2RKrSI

Would be awesome to see anything (developer friendly) like this on amplify.

[selipso]

Would like to expand on the following:

Expand the CLI capabilities to automatically configure IAM “Read/Write” access for authenticated vs unauthenticated users:

I've noticed that when setting up Auth with IAM, by default there is no mapping template to limit Appsync queries to the users who created the item in the DynamoDB table. Without this, each user has the ability to access resources created by other users. It would be nice to have sane default filtering of items from DynamoDB (restricted to the Identity ID that created that item) with AWS_IAM authorization

[undefobj]

Would like to expand on the following:

Expand the CLI capabilities to automatically configure IAM “Read/Write” access for authenticated vs unauthenticated users:

I've noticed that when setting up Auth with IAM, by default there is no mapping template to limit Appsync queries to the users who created the item in the DynamoDB table. Without this, each user has the ability to access resources created by other users. It would be nice to have sane default filtering of items from DynamoDB (restricted to the Identity ID that created that item) with AWS_IAM authorization

@selipso this is accurate for the GraphQL Transformer. We are going to be adding IAM capabilities to it very soon, please see our latest RFC for that design here: https://github.com/aws-amplify/amplify-cli/issues/1043

[undefobj]

https://firebase.google.com/docs/auth/web/anonymous-auth

@pechisworks Anonymous features are available with Amplify libraries across JS, Android, and iOS today when using the Auth category in the clients. However the backend pieces are more complex when it comes to tying together different services. With respect to your links, is it specifically the explicit use of a method for anonymous credentials (signInAnonymously()) that you like or is it something else? The reason I ask is because this is enabled implicitly in the Amplify Framework libraries (for example in Android: https://aws-amplify.github.io/docs/android/authentication#guest-access) however this RFC is for making the configuration of auth vs unauth easier with different combinations of backend features.

[ByDesignGit]

+1 for “Admin Queries”, my application is invite only so having an abstraction for adminCreateUser and all the other user/identity/group management functionality would be incredibly help full, being able to do these things in the app instead of the aws console makes for a better admin user experience in my use case

[jkeys-ecg-nmsu]

@ByDesignGit mentions something that is a problem in our application. We create Dynamo records from a Lambda with an admin user for the purposes of client-based AppSync subscriptions; however, since default create mutation resolvers force the admin username to be the owner field, we have to override that by storing a separate "localOwner" field.

It would be nice to specify for a given @model type that an admin user might create it (which would mean generating an additional mutation I suppose), and so it should be expected to be passed an owner attribute and fail if not given.

[kmbro]

TL;DR It would be amazing to limit users' dynamodb access to rows they created (fine-grained dynamodb access)

Adding fine-grained DynamoDB support would be a huge help and make applications much more secure "out of the box". Right now when you create an amplify app and give authenticated users read/write access to Dynamo via API GW and a CRUD Lambda, all users have access to all entries in the table. It would be amazing to be able to limit the users to be only able to get the entries they created. Especially because this is a common use case for many applications as explained in many AWS Docs on how to do fine-grained access. (links below)

Fine-grained access control by dynamically assigning roles based on Group membership or rules/token claims. How would you like this to work in your developer workflow? If you’re unfamiliar with this capability you can read more here: https://aws.amazon.com/blogs/aws/new-amazon-cognito-groups-and-fine-grained-role-based-access-control-2/

Links to aws docs for fine-grained access https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html https://aws.amazon.com/blogs/mobile/building-fine-grained-authorization-using-amazon-cognito-user-pools-groups/ https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_rows.html https://aws.amazon.com/blogs/mobile/understanding-amazon-cognito-authentication-part-3-roles-and-policies/

• 10s more

[undefobj]

Hello everyone, I wanted to provide an update. We have just released a couple of pieces that are part of this RFC:

• Hosted UI & OAuth configuration
• Federation through User Pools
• CRUD permissions for Storage & REST APIs using IAM permissions from Cognito Identity

You can read more about this here:https://aws.amazon.com/blogs/mobile/amplify-framework-simplifies-configuration-for-oauth-flows-the-hosted-ui-and-ar-vr-scenes-for-mobile-and-web-developers/

Please install the latest CLI to have a play. We'll be working on the next phases of this RFC in the coming weeks.

[kmbro]

According to the blog post you linked above @undefobj Amplify now supports fine-grained access on DynamoDb with a Rest API.

In addition, the Amplify Framework now supports setting up fine-grained CRUD-style permissions for the storage and API (REST) categories. This works for both authenticated and unauthenticated workflows.

Is there documentation on how to set this up somewhere? Right now, I have installed the new CLI and tried to create a new Rest API and there were not options for fine grained dynamodb access. I know that in the GraphQL api there is an option to do fine-grained access control, but I really want to do it with Rest APIs. Please advise if I am just missing something or reading something incorrectly.

[mlecoq]

Hi,

as described in 1182, It would be great if we could have an indication when authentication is rejected because temporary password is expired. Users tend to ask for a new password and their requests fail in this case. If we could display an error message to ask for contacting us, our users would be less frustrated. Thanks !

[mwarger]

• CRUD permissions for Storage & REST APIs using IAM permissions from Cognito Identity

@undefobj In the link, it mentions

"In addition, the Amplify Framework now supports setting up fine-grained CRUD-style permissions for the storage and API (REST) categories. This works for both authenticated and unauthenticated workflows."

Where is this discussed? I don't see anything at the link you posted that details these permissions updates.

Thank you!

[Jun711]

@undefobj

Regarding my previous comment: https://github.com/aws-amplify/amplify-cli/issues/766#issuecomment-467242561 about disabling/delete users, with amplify, we cannot disable / delete immediately.

However, amplify can have DurationSeconds parameter of STS assumeRole functions configurable. It is available in aws-sdk's STS.assumeRoleWithWebidentity. Then, one hour could be set to 15 minutes which doesn't solve the problem entirely but at least minimize the problem. More info about token lifetime [on this AWS doc].(https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html#id_roles_use_view-role-max-session)

There is another use case here in this feature request.

[undefobj]

@Jun711 sessions longer than 1 hour are not possible with Cognito which Amplify uses for Auth and not direct STS calls. We would not be able to provide this in Amplify, please raise a feature request on the Cognito team's forum: https://forums.aws.amazon.com/forum.jspa?forumID=173

[undefobj]

• CRUD permissions for Storage & REST APIs using IAM permissions from Cognito Identity

@undefobj In the link, it mentions

"In addition, the Amplify Framework now supports setting up fine-grained CRUD-style permissions for the storage and API (REST) categories. This works for both authenticated and unauthenticated workflows."

Where is this discussed? I don't see anything at the link you posted that details these permissions updates.

Thank you!

@mwarger it's built into the Storage category and REST piece of the API category when you go through that flow. We've actually always had functionality for permissions in those categories where it setup the auth/unauth roles however it used to be simple read & read-write. Now it gives you CRUD options and we'll setup the appropriate IAM permissions.

[sebsto]

I have what seems to be a common requirement : to securely integrate with existing API.

Use case : another team is publishing an API (using SAM and API Gateway), protected by IAM. I need to create an front end app, incl. Cognito User Pool & Federation. Apps users must be authorized to call that API.

Both the API and the front end app are on the same AWS Account.

To make this happen, I would like to be able to add a custom IAM Policy to the role attached to Cognito Identity authenticated users, allowing users to make API Gateway calls. This can not be done today using just amplify. I can write a script that will add required policy to the Cognito Authenticated Users role, but I am afraid this can be overwritten by subsequent amplify update auth && amplify push

Maybe this item from the list of suggestions in the initial post might address this use case :

Fine-grained access control by dynamically assigning roles based on Group membership or rules/token claims. How would you like this to work in your developer workflow?

[janhesters]

Referencing this issue, custom user types (admin, supervisor, regular, guest) would be awesome.

[undefobj]

All - We're continuing to chip away at the pieces of this RFC and have now released support for Triggers in the Amplify CLI including common Auth templates. Please read more here:

https://aws.amazon.com/blogs/mobile/amplify-framework-adds-supports-for-aws-lambda-triggers-in-auth-and-storage-categories/ https://aws-amplify.github.io/docs/cli-toolchain/quickstart?sdk=js https://aws-amplify.github.io/docs/cli-toolchain/quickstart#adding-a-lambda-trigger

[rawadrifai]

Solid work with the triggers. Love it.

[janhesters]

This looks great!

@undefobj Can you also build these Lambda triggers after the fact?

E.g. I'm using Stripe for a subscription service. Can I create a function that adds the user to a certain group, so I know, he paid the subscription?

[undefobj]

@janhesters I'm not sure what you mean by after the fact, but you can modify or add custom Lambda triggers for auth as well as the storage categories to be invoked on DDB writes or S3 puts. Also you can use @function with the GraphQL Transformer to invoke functions too, so depending on your architecture you could do something like that.

https://aws-amplify.github.io/docs/cli-toolchain/quickstart#functions-examples https://aws-amplify.github.io/docs/cli-toolchain/quickstart#storage-examples https://aws-amplify.github.io/docs/cli-toolchain/graphql#function

[janhesters]

@undefobj Got it thank you. I think I need to understand @function better.

[kldeb]

@undefobj if i want to add an "add users to group trigger" to an existing project with auth already setup do I run amplify auth update and follow the steps?

[hisham]

@undefobj is there lambda trigger support for dynamodb tables created by the graphql transformer? When the gql transformer creates a ddb table I don't think that is added to the amplify storage category...

[nikhil-dabhade]

@aireater You should be able to use "amplify auth update" and then use manual configuration flow to add this trigger to your existing project with auth.

[undefobj]

Hello everyone - I'm happy to comment and close this RFC as we have completed the final pieces which contained Group support as well as the "Admin Queries" API. You can read more about this here:

https://aws-amplify.github.io/docs/cli-toolchain/quickstart#group-management https://aws-amplify.github.io/docs/cli-toolchain/quickstart#group-access-controls https://aws-amplify.github.io/docs/cli-toolchain/quickstart#administrative-actions

For any further Auth enhancements in the future we'll open additional RFCs or look for feature requests in the repo. We appreciate all that participated and gave us feedback.