In the old days before IAM Identity Center (AWS SSO), we used custom IAM Identity Providers with IAM Roles that had trust policies that allows users with certain claims (IdP groups) to assume them. This system was nice in that AWS/IAM didn't care about provisioning, syncing, or otherwise tracking the users themselves; it only cared that a user was able to get a valid SAML assertion or OIDC token.
Having the Identity Center internal user/group database just seems like an unnecessary security risk when you're using an IdP. For example, consider this scenario:
I have a user in the aws-admins group in Active Directory, and this is synced to Identity Center via SCIM.
My provisioning (SCIM) tokens expire and the sync stops.
I remove this user from the aws-admins group because they've been moved to a different job/department.
Because the sync has stopped, Identity Center isn't aware of this change.
The user can still authenticate to Identity Center with Active Directory because they still have a valid user, but Identity Center thinks they're still in the aws-admins group and lets them assume an administrator permission set.
Is there any way to use Identity Center without having it internally store the users/groups? i.e. to have Identity Center use claims/assertions from the IdP to determine which permission sets can be assumed, instead of it using the IdP response to just identify the user, and then using its internal user/group database to determine which permission sets can be assumed?
What you described (AWS console access using SAML assertions alone) is still possible using AWS IAM.
AWS SSO seems to be for a different use case of centrally managing access to AWS and other applications, as seen in their product page. In this case, it makes sense that provisioning is required.
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.
I have recently made a program that listens to a PUB/SUB topic that is connected to a Gmail account. I have it all working fine. When a push notification arrives it will do different tasks based on the message content.
The problem is that I use a Service Account to connect to all the API's on Google Cloud Platform that I need. The Service Account allows access to ALL of our Gmail accounts in our organization. I need to somehow limit the access to a specific Gmail account.
The closest I could find to this issue was this question Impersonating list of users with Google Service Account. However, the only solution presented there was to turn my project into a marketplace app which I do not want to do.
I have tried setting up an Organizational Unit and trying to limit the scope to that somehow, but there seems to be know way (that I can find) to do it. I did try speak with Google Cloud Platform help but they didn't know the answer as it didn't quite fall under their area of expertise and referred me on to another help group, but I'm not eligible for them because I don't pay for support.
Edit: It doesn't actually appear that what I want to do is possible. I'll be going back to an OAuth2 method of authentication.
Understanding service accounts explains the possibilities:
Service accounts can be thought of as both a resource and as an identity.
When thinking of the service account as an identity, you can grant a role to a service account, allowing it to access a resource (such as a project).
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
Now try to fit that impracticable intent into there ...
If you need to limit the access of the service account to user-specific resources, this can only be done on the application level, not the system level - since a service account can impersonate just any user identity; eg. in order not to mess up the ownership, when uploading files on behalf of a user. If you want 1 user identity to access 1 user-specific resource, why even use a service account? And when using a service account, why not just impersonate as the correct identity? This could even be hard-coded, if it's only 1 user identity. But nevertheless, it can only be done on the application level - but cannot be configured for the service account itself.
Help is required in the following problem we're facing 😔
Any tip would be much appreciated!
Details and environment:
A multi-tenant application that aims to provide a dedicated tenant per customer (organization), in order to achieve full separation.
AWS Cognito user pool as my users' datastore and authentication provider.
an "AWS Cognito user pool" per customer (org).
Role management - based on the built-in user pool groups. Group per role and the server-side verifies that a user's access token includes a group name in it's embedded group's list.
So far so good and everything is working as expected, using AWS Amplify's SDK, for the client side's implementation. Amplify performs well and allows me to do whatever I want. The server verifies group belonging etc.
The problem:
I want to restrict non-admin users (that doesn't belong to the "admin" group) from performing certain Cognito actions via Amplify.
2 Examples:
I want to disable non-admin users' ability to modify a specific attribute's value, via Amplify.
I want to disable non-admin users' ability to modify MFA settings for themselves, via Amplify.
The actual problem started when I wanted administrators to be able to set MFA (enable/disable) for other users, but in Cognito (as I understand it) only a user can set his own MFA settings.
What I saw and already tried:
Set read/write permissions for user attributes. So the specific attribute I want to protect is modifiable only via API calls with developer credentials. That way, admins can call my server to ask for attribute modification. The server verifies the role by a group belonging according to the access token and calls Cognito API. The problem with that solution is that it covers only the attribute modification scenario.
Create an AWS Cognito identity pool for each of the user pools. For every group in every user pool, create an AWS IAM role with a policy that would restrict or allow the wanted behavior. The could actually work. The problem with that solution is that it feels like a super-duper overkill, plus it requires me to create an extra identity pool and an IAM role for each user pool. It means that every new customer that joins the service, would require (1) user pool, (2) Cognito client application, (3) identity pool and (4) IAM Role (instead of just a user pool and Cognito client app). Essentially, implementing this solution.
The real question:
Can I restrict users in a certain group from performing actions on themselves, such as disabling the MFA (even that the user-pool's MFA is set to "Optional")?
Thank you all so much! any help would be appreciated!
Well... After long research, we have come to the understanding that there is no proper right way. Every possible solution has its own pros and cons. A consultant meeting with AWS's experts taught us that:
Options Overview:
[Server Side Only] - Solution #1 that I proposed is exactly as described. Drawbacks are the same. It could work, and access to user-attributes will be restricted. Any other action that another client would make will not be blocked.
[Identity Pools] - Solution #2 that I proposed is the most accurate one. Yet I described it with one big mistake: one identity-pool can serve multiple user-pools! So essentially, we could create only one IAM role and one identity-pool per app's role. Then we match every user-pool we want to that same identity-pool and when introducing a new role to the app - just create a new group in the user-pool and match it to the IAM role. This solution is not as complicated as thought, and it would definitely do the trick. As a bonus, you'll get the ability to control and allow access to different AWS services. That being said, it still requires management and effort.
[Post-Auth Lambda] - Solution #3 that was not mentioned here, and I started to work on a day after posting this post. I blocked the write permissions of a new boolean custom attribute called "MFA". It indicates the desired MFA configuration for the user. Only a server could edit its value (and users with the admin role will have access to the server's API endpoint that can modify it). We've deployed a lambda function that would be triggered after successful authentication (post auth trigger in Cognito user-pool). It would verify a match between the desired and current MFA configurations for the authenticated user. If there is a mismatch, throw the user out because he did something that is not allowed.
*To be exact, we created one more custom attribute called "mfa_status" and it is set to true after the user has set it's MFA configurations. The lambda checks if both MFA and mfa_status are true and the real current MFA Configurations are false. if this is the case - the user is thrown out.
The Chosen One:
The solution we picked eventually is #3 (Post-Auth lambda) as it is the most detached solution. It does not require any mix with our server or client's code, any special configurations that are specific to a user pool and it still allows us to keep working with the Cognito's Amplify SDK as a client.
Thank you all for your time, I hope this post would help someone in the future.
My production environment uses AWS cognito federated identities (AKA: identity pool) for allowing users to sign in with their Google/FB accounts. This is working fine.
However, for my staging environment I want to offer a similar sign in functionality (that is: users sign in in via Google) but I want to restrict the ability to sign in only to a specific whitelist (of, say, #gmail.com accounts). This is because the staging environment should only be accessed by team members and a bunch of trusted users.
My question is this: is it possible to define a Cognito identity pool that allows only the whitelisted users to sign in? if the answer is "yes", then how?
I know that I can do the whitelist checking at my backend (that is: at the backend of my staging env. I will reject every request not coming from these whitelisted users) but this is a bit unclean. In particular, I want the rejection to happen as early and possible and, ideally, to be carried out by cognito itself, and not by my backend.
Clarifications:
I mentioned a list of #gmail.com accounts as the whitelist. I am open to any other mechanism for defining the whitelist.
In a way I am asking whether I can have user directory functionality (in particular: determining if a user is in a certain group of users) with an cognito identity pool.
The purpose of the Identity pool is to provide access to authenticated identities. Therefore, this resource cannot manage users (ie: white listing a user group).
There are two ways to do this:
Link 3rd Party Identity into a User Pool and white list by User Group. Your user group will have a Roles and permission it will assume that will allow your test users to have the functionality they need without allowing other users who log to have that functionality.
Manage users from the 3rd Party Identity - I am not an expert at Google authentication.. but some OpenID providers allow you to create user groups with different access roles. This is an example for Google.
You can invoke a trigger and execute a lambda function when the user submits their information to accept or deny the sign in request.
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/