I have an App client created for a Cognito User Pool. The client has an ID and secret generated. It is configured to use the Client credentials flow and has a custom scope defined. With that in place, I'm able to successfully exchange the creds for an Access Token, so far so good.
I would like to use AWS SDK to manage users (list, delete etc) in the User Pool with the server-side app client. Assuming I validated the granted token, how do I use it with AWS SDK to execute Actions I need? Is there a better way to manage User Pools from a server-side app?
If you look at Admin* level actions in the Cognito SDK (e.g. AdminDeleteUser), you will see it does not accept access tokens. It rather expects valid AWS developer credentials.
So what you probably want to do is to create an IAM role with appropriate permissions to manage the user pool (resource format: arn:aws:cognito-idp:REGION:ACCOUNT_ID:userpool/USER_POOL_ID) and let your server application assume that role. With correct permissions configured, you can call the AWS SDK directly.
You can find the list of available IAM actions here.
Related
I have read about AWS cognito and I understand that User pools is an identity provider that is used to authenticate users to your mobile app, website and manage users. Then there is Identity pools that are used to authorize users to give access to your aws resources such as IAM, S3 and etc.
So my question is: Are identity pools used for the app management like by devs, dev-ops or anyone who needs to manage/update the apps? Is that the work of identity pools?
Identity pools are not (necessarily) used for app management. I can tell you about how my team used them at my last job. (There are probably other use cases, but I suspect ours was a fairly common one.)
We were building an app where users needed to upload and download files that we would store in S3. For various reasons, we wanted the client to interact directly with S3 for file transfer (as opposed to pushing files through an API layer that we would have to maintain). Identity Pools were made for exactly this sort of scenario. Basically they allow a client to exchange an identity token for a set of temporary IAM credentials (access_key_id + secret_access_key + session_token). The temporary IAM credentials are what the client needs to interact with an AWS SDK or create a signed HTTP request for one of AWS's native services.
The identity token that gets exchanged for credentials could be provided by Cognito User Pools, but it could also come from a different identity provider. We used Auth0 as an identity provider, for example. But we still wanted our client to interact directly with S3 and for that we needed Cognito Identity Pools.
One really cool feature of Identity Pools that we took advantage of was what Cognito calls Principal Tag Mapping, which is the ability to map claims (attributes) in the Auth0-provided identity token to session tags, which are kind of like environment variables that are attached to the temporary credentials' session. You can then write IAM policies that incorporate session tags to do attribute-based access control. We wrote S3 bucket policies that provided fine-grained access control where each user was only allowed to read and write to a prefix that contained their own user id.
I have to say that the distinction between User Pools and Identity Pools in Cognito confuses everyone and AWS's documentation isn't always as helpful as it could be on this point.
is there a way to disable programmatic access for users Signing in using AWS SSO?
Is it possible to control the programmatic and console access using polices or Groups?
No, you cannot prevent users to login and deny the programmatic access, because once users sign-in they have option to get required details to access programmatically.
The permissions a user has through SSO can still be managed through AWS IAM (Identity and Access Management) groups and rols. The same permissions a user has through IAM in the AWS console can be used by the user when accessing AWS programatically throught the CLI or an SDK.
No permissions are required for a user to get a session token. The purpose of the GetSessionToken operation is to authenticate the user using MFA. You cannot use policies to control authentication operations.
Source
Therefore, I don't think that you can prevent a user from using access keys to get temporary session tokes for programmatic access.
Why do you want to prevent programmatic access for users and am I right assuming that you mean CLI and SDK access to AWS by programmatic access?
Yes, you can, but exactly how will be buried in the implementation details of your organization's SSO implementation. Your SSO's custom identity broker is in charge of mapping a particular user's AD credentials to an AWS IAM role, which may or may not have permissions to login to the CLI. Exactly which role a user gets needs to be controllable in the broker. Another way is to control access to the AWS access keys needed to use the CLI or SDKs. Your SSO users shouldn't have permission to generate their own keys. They should come from IT or should be a configurable feature of your SSO implementation. For example, in my organization, there are 2 links in the AWS portal; one for console access and one to display temporary access keys that can be copied into the bash environment or used with an SDK.
We have an external application resides outside of Amazon network and it needs to access our SQS and send message there, in order for our AWS resource to recognize the request from that application it needs to sign its request with the credentials of the IAM role we created, I'm wondering what is the best way for that external application to retrieve temp credentials from us? I have tried to implement it using Amazon Cognito but it looks like Cognito fits more in scenarios like user sign-up and sign-in with an User Interface, anyone has any suggestions? Thanks in advance.
To be able to obtain temporary credentials, you need a form of permanent credentials that can access (or generate) the temporary credentials.
Given your situation, you might consider creating an IAM User in your account and giving those credentials to the third-party. Grant the appropriate permissions to those credentials and they can use them directly with Amazon SQS.
Or, if you'd rather not give IAM credentials to third-parties, you could ask them to create an AWS account and an IAM User. You could then grant their IAM user access to the Amazon SQS queue.
Another option is that the third-party could access an application or API that you provide. Once they authenticate, you can provide temporary credentials created with the Security Token Service. Cognito would be an option for performing this authentication and it can also provide credentials for an associated IAM Role, thus giving them access to the Amazon SQS queue.
For the last few years, I've built a PHP and MySQL based website where users can submit reprographics and IT requests. I'm hoping to make this cloud-based rather than running it from a local webserver. My initial idea was to have an EC2 instance running as a web server for each company which uses my system, but as the system is PHP session based I'm assuming the security would not be great so I think I need to move towards more of an AWS system using Cognito for user management and the API Gateway with Lambda to do the job of getting the data from the databases. My question is, my current system has an admin console where the admin user can access the lists of users, and assign them permissions (session variables) which allows them access to specific pages. How would I make a webpage where users can manage the users in a Cognito user pool without giving them access to the AWS console.
Implement a Cognito AdminAddUserToGroup operation in your Lambda function for admin users to manage what Cognito Groups your users belong to. Your admins will be the only ones that are able to invoke the API call to the Lambda function because they'll be included in the Cognito Admin Group with appropriate permissions to invoke the Lambda function that you specified as the developer.
Specify permissions of what each Congito Group has access to by assigning roles for each Cognito Group.
You can also decode the jwt on the backend to determine what Cognito Group the user belongs to that made the request and use Amplify on the FrontEnd to manage the FrontEnd's display of content based on the Group (links, etc). More info about that can be found in this thread: How do I access the group for a Cognito User account?
I do not have enough points to comment on the CLI update-user-pool suggestion, but wanted you to know that wouldn't work because 1.) It would impact the entire user pool and affect ALL users in the user pool and 2.) It would make no difference in regards to what your users were able to have permission to access in your application.
I have an embedded device that requires the ability to write to S3. I want to avoid giving the embedded device an actual AWS IAMUser. I am looking at using Cognito to gain write access to S3.
I have a user pool with a group and one user (for now). The group has an attached policy which permits access to write to a certain S3 bucket. The pool is setup so that only admins can create new users. I have managed to authenticate the cognito user and have got access to refresh tokens and the idTokens. I am looking to use these tokens to write to my s3 bucket.
I am trying to follow trying to follow the documentation but am getting confused. I think i need a federated identity pool but i have no requirement for a public provider. I just want my cognito user group to write to s3.
Is there a simple solution to allow a cognito user to write to S3 without federated identities or if not do i require a back end to serve a token for a federated identity?
I have been using warrant https://github.com/capless/warrant to authenticate as so:
from warrant.aws_srp import AWSSRP
import boto3
client = boto3.client('cognito-idp')
aws = AWSSRP(username='<username>', password='<password>', pool_id='<pool>',
client_id='<clientid>', client=client)
tokens = aws.authenticate_user()
Any tips would be greatly appreciated!
You do need a federated identity pool. In the identity provider section you choose Cognito and enter your pool ID and pool client ID. Then, you need to provide the identity pool with authenticated and unauthenticated roles. You can use these roles to provide that S3 write access.
This is the default behavior for the identity provider setup. If you want the Role to come from the group that your user is in, you will need to set the Choose role from token option in the identity provider section under where you provided your pool and client id.