https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html#using-rules-to-assign-roles-to-users
As stated in the document:
Rules are evaluated in order, and the IAM role for the first matching rule is used, unless CustomRoleArn is specified to override the order. For more information about user attributes in Amazon Cognito user pools, see Configuring User Pool Attributes.
You can set multiple rules for an authentication provider in the identity pool (federated identities) console. Rules are applied in order. You can drag the rules to change their order. The first matching rule takes precedence. If the match type is NotEqual and the claim doesn't exist, the rule is not evaluated. If no rules match, the Role resolution setting is applied to either Use default Authenticated role or DENY.
My understanding is that we can customize these rules to map the JWT token's field to a specific AWS role granting.
Yet I couldn't find any options of creating/editing these rules on the AWS Console
Am I misreading the documentation? Or is this an undelivered feature or something?
It turns out that custom roles using Cognito Identity Pool only works with Cognito User Pool
User Pool can only be integrated with external SAML IDP (not JWT), so I think it's not possible to do access control for JWT bearers with Identity Pool
I guess what we can do is create multiple Identity Pools for multiple IAM Roles and do the access control from the IDP, even then we'll have to create multiple IDP clients for multiple Identity Pools
Related
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.
I have a cognito user pool with many groups. Each group is associated with an IAM role. A user in the pool can be a member of more than one group. I also have an identity pool for which the cognito user pool is the identity provider. The problem I'm running into has two parts.
I am unable to use the precedence ordering for the group roles. This is because the IAM roles have different permissions and there is no point in ordering them. A user will select the group/role that they want to use which rules out any system for ranking them. This rules out using the cognito:preferred_role field in the identity token.
2)I then looked at using the rule based mappings in conjunction with a custom attribute. This way a role could be specified in the custom attribute and then the token could be regenerated. However, the rule based mapping only allows 25 rules per identity pool and this is not nearly enough for our the number of groups/roles.
Lastly, I looked at using the CustomRoleArn parameter in the GetCredentialsForIdentity API method. When using it I got an error saying "An error occurred (InvalidParameterException) when calling the GetCredentialsForIdentity operation: Only SAML providers and providers with RoleMappings support custom role ARN". This brings us back to the 25 rule limit.
So is there a way to specify an IAM role for and authenticated user to assume that isn't some obtuse ordering system or limited by the number of rules I can use?
I am new to AWS...
We have a home grown user authentication and authorization.
We define authorizations(roles) in company terms, role1 allows you to do tasks1 and tasks2. Role2 allows one to perform tasks3 only.
I can see how I can use Cognito for my user/password management.
Unclear if I use cognito for roles verification, i.e authorization.
Thoughts?
In a Cognito User Pool one can define both Users and Groups, which can be leveraged to drive fine-grained RBAC permissioning. You can define a custom attribute in the User model (e.g., "department" or "role") and map this attribute to Groups.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-user-groups.html
Each group can optionally be associated with an IAM role, so it's possible to restrict access to AWS resources (e.g., certain DynamoDB tables) by group -- as an additional layer of security.
However, if you don't need/want to map users to different IAM roles, maybe just handle authentication completely from within your application.
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.
Anybody could explain why the operation assume-role-with-saml needs some parameters that are already in the saml-assertion such as role-arn and principal-arn?
After some research I'm able to answer. I was asking why send the --role-arn parameter if it is already in the saml assertion. In fact the saml assertion can have more than one role so in the api request is necessary to identify which role should be assumed. I found the answer in this link
The Amazon documentation for assume-role-with-saml provides the information:
The --role-arnstring option identifies the role that the caller is assuming.
The --principal-arnstring option requires closer reading. Amazon says
The Amazon Resource Name (ARN) of the SAML provider in AWS IAM that describes the IdP.
The explanation for the latter is given a few paragraphs before:
Before your application can call assume-role-with-saml , you must configure your SAML identity provider (IdP) to issue the claims required by AWS.
The same page provides a link to Using Identity Providers, which explains the term:
Using identity providers, you can manage user identities outside of AWS, and you can give these external user identities permissions to use AWS resources in your account.
That is, you could associate an external user identity with a role using the --principal-arn option. The --role-arn option is not really optional, but a required parameter.
The saml-assertion (--saml-assertionstring) option) is additional "glue" which may be used to check permissions. Following the link in the description for this option to Configuring a Relying Party and Adding Claims, Amazon says
You also need to create appropriate claim rules in your IdP with AWS as a relying party. These rules map information about users and groups in your organization into appropriate SAML attributes. This lets you make sure that SAML authentication responses (assertions) from your IdP contain the necessary attributes that AWS uses in IAM policies to check permissions for federated users.
and in turn, that links to a page describing the assertions: Configure Assertions for the SAML Authentication Response