Why when creating a new AWS account via the AWS Control Tower Account Factory does an SSO user also need to be created? There is already an email for the root user can through AWS SSO you can assign users/groups anyway, so what purpose does it serve to make an SSO user as well? You may not want a new user, or should I simply put the email of an existing SSO user?
This is something that is not that intuitive, indeed. Feels like a wrong UX.
However, there is a reason behind that. Let's check the docs first:
The SSOUserEmail can be a new email address, or the email address
associated with an existing IAM Identity Center user. Whichever you
choose, this user will have administrative access to the account
you're provisioning.
The AccountEmail must be an email address that isn't already
associated with an AWS account. If you used a new email address in
SSOUserEmail, you can use that email address here.
As we see, the general approach is something like that we could not create a state, where we cannot access the new account by default.
So either it will create a new user, or will understand that it is an existing user, and using that.
So you can type your SSO email, and will sort out the PermissionSets later, or you could use a default controltower admin user for just this reason.
You could create a new SSO user for every account too, but to be honest it just sounds wrong. (maybe with email aliases could work, but still unnecessary, redundant)
You could use the same address for root and the correspondent SSO, but it feels counterproductive too.
TL;DR:
For me the less painful approach is using my own SSO account, and later tuning the permissionsets.
The general approach is perhaps to have a ControlTower shared user, for kind of an account owner and backup user.
The doc: https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html
Related
I read some questions and answers about my issue, but I still don't know the answer.
Can I use the userSub in AWS Cognito as primary key?
AWS Cognito: Difference between Cognito ID and sub, what should I use as primary key?
First, I will try to describe my case.
I want to create an application with spring boot as a resource server that uses oauth2. Then to save me some time with user management, I was hoping to use AWS Cognito since it allows me to create users as admin. I can set it up that it won't let other people sign up for themselves, which is crucial for me since my app will have restricted access; the admin will manage that.
Now to my question, which field of AWS Cognito can I use as the primary key for keeping user-specific data in my DB? I read that neither usernamenor sub is correct.
username can be changed, for example, and sub is globally unique, so it can't be restored. Is there any way to create a custom field where AWS Cognito will autogenerate UUID that I can use, and if I had to restore the user pool, I would have an option to set this field?
You can still go with username. If it is ever changed, just update your database to reflect this change.
You can also create a custom attributes in user pool. You can use that to store a self generated id. As for automatically generating this, you can have a post confirmation lambda trigger that will use adminUpdateUserAttributes to assign a unique id.
I am planning on a web page that creates an instance for an user using a specific AMI. Is there any AWS method to let the user approve my web application to do this using their credentials? (i. e. getting a secret token with certain privileges)
Similar to when you let a Facebook application have access to certain information of your profile. I am looking for a way to get a token from the user signed in so that I can create an instance for them.
I want to avoid the user the pain of doing all the manual steps of going to IAM, create a new user, get the token and then upload them to my site.
I looked into AWS Cognito but this doesn't seem to be what I am looking for.
Similar to when you let a Facebook application have access to certain information of your profile.
AWS and Facebook are not similar in any sense. Facebook is a web application. AWS something entirely different.
Facebook has users, but AWS has accounts, which in turn have users... but in AWS, don't need a user's permission to do things to resources -- what you actually need is an account's permission to do things to its resources, because resources are associated with the account, not the user.
I am looking for a way to get a token from the user signed in so that I can create an instance for them.
Users sign in to the AWS console. After this, there is no such concept as a user allowing an external application doing things under the "signed in" user's auspices.
The user has to have sufficient permissions to either create sufficiently-privileged temporary IAM credentials (such as with GetSessionToken or AssumeRole from the IAM API) and hand them over to you, or create an IAM user with sufficient privilege and hand the keys to that user over to you... or you provide them with the ARN of one of your IAM users, and your customer gives your user permission to perform the actions or assume a role in your customer's account, created for the purpose.
I want to avoid the user the pain of doing all the manual steps of going to IAM, create a new user, get the token and then upload them to my site.
That can't be avoided, by design... and, in any event, whatever exactly you are planning, your model seems flawed: it would only be a naïve user who would allow you to do this. I have accounts that are allowed to launch hundreds of instances concurrently. Does it make sense that I would allow a third party to have access to credentials that could run up a huge bill for me? (If AWS trusts a set of credentials to launch instances, then it trusts them to launch instances -- all the way up to the account's instance limits).
If you want a user to be able to launch an instance from your AMI, you can simply list it on the AWS Marketplace, or you can share the AMI with the user's account, or even just make the AMI public.
I am using AWS Cognito. I have a pretty common scenario: users can register in different roles. Depending on the role different user attributes are required, so I need to use different user pools.
Now a user wants to upgrade from role A to role B - thus I would have to move his account from one pool to another. Is this possible with AWS? The response in Can you export/migrate users out of AWS cognito, does it cause vendor lock-in? seems to indicate the opposite.
If not possible this way, what would be a viable solution to achieve requiring different user attributes depending on different user roles with AWS Cognito. (NOTE: requiring / verifying them only on the front end is not a viable solution)
I know this question is a bit dated, but it is possible that this scenario is best solved by using Groups instead of a separate user pool for each role. See here
If you reach this link to find out how to transfer users to a new pool (for instance, you needed to create a new user pool in order to change how your users log in), then there isn't a built in way to do this. However, there are solutions that you could build in order to migrate users, which is referenced here:
Create your new user pool.
Modify your client to do the following:
On failed sign in with new user pool, attempt sign in with old user pool.
If existing user pool sign in is successful, use the username and password that was submitted to the existing sign in to create a user on the new user pool.
Possibly do something to remove the user from the old user pool or mark as migrated.
You can export users and import them to a new user pool with a CSV file, but your users will have to change their password.
I am new to AWS so not fully aware of its features.
I want to create an application running on EC2 instance which allows a user to login and upload a picture to a S3 bucket.
The user is created in through IAM in AWS, and assigned a policy to allow that specific user to only access that specific bucket.
However, in my code, I do not want to store the Access ID and the Secret key - which is assigned by AWS when I create my user due to Security issues i.e. in case someone gets access to them.
In order to solve this, my thoughts were to create my own login system, where I create a user (e.g. user = abc1, password = password1), and in the background the user and password will be equal to the access key and the secret ID without the user ever knowing them.
Is this a good way forward with this and how would I go ahead with it? Or is there a better way of doing this?
This is my recommendation:
Build your own login system (typical login/password(hashed) system), and assign an IAM user to the application itself (or the machine with a machine role), not the user, so the application (or machine) is the entity allowed to run the S3 operations. This way is easier to manage privileges.
I'm attempting to develop an application architecture almost exclusively on top of AWS services.
This application has both User and Organization "entities". As one might except, a User may be an admin, role-x or role-y of one or more organizations. (role-x and role-y are just placeholders for some role with some set of specific permissions. A User may also be standalone (that is, not have a role on any Organization).
Our current thinking is to use DynamoDB to store organization and user specific data. For users this may include some basic information (address, phone number, whatever), and for organizations it may include fields like "mission statement", "business address" and so on.
An admin of an organization would be able to edit all organization fields, whereas a role-x might only be able to update "mission statement" while reading all other fields.
Since I mentioned that a single user may have roles on many different organizations, that might look something like:
user1:
organizations:
123: 'admin'
456: 'role-x'
789: 'admin'
It's also worth noting that these role assignments are modifiable. New or existing users may be invited to take on a specific role for an organization, and an organization may remove a user from a role.
This is a fairly straightforward type of layout, but I wanted to be very clear about the many-to-many nature of the user, org and roles.
I've been reading IAM and Cognito documentation, as well as how it relates to fine-grained control over DynamoDB items or S3 buckets - but many of the examples focus on a single user accessing their own data rather than a many-to-many role style layout.
How might one go about implementing this type of permission system on AWS?
(If policy definitions need to be updated with specific Identities (say, for an Organization), can that reliably be done in a programatic way - or is it ill-advised to modify policies on the fly like that?)
The above answer is outdated.
AWS has added Cognito-Groups recently. That provides more flexibility
You can use technique described in the article to achieve that:
https://aws.amazon.com/blogs/aws/new-amazon-cognito-groups-and-fine-grained-role-based-access-control-2/
Unfortunately the kind of permission system you are trying to implement is not possible with Cognito at the moment. With Cognito you can currently create unique identities for your users in an identity pool. Users can authenticate using any external provider such as Facebook, Amazon, Google, Twitter/Digits or any OpenId Connect Provider. Users can also authenticate through your own backend authentication process. After the user authenticates, Cognito creates a unique identity for that user. There’s a concept of an identity, but there’s no concept of groups. All users/identities within a one identity pool can get credentials from roles associated with that identity pool. Currently you can specify two roles: One role for authenticated identity and one role for unauthenticated identity. There’s no such feature at the moment where you can specify multiple groups for each identity and specify role on that group.
For more information on Cognito, you can refer to
https://aws.amazon.com/cognito/faqs/
http://docs.aws.amazon.com/cognito/devguide/getting-started/