OpenAM as a SAMLv2 IdP for the AWS Administration console. 2nd Part.
In a previous blog post, we defined a fixed role for the users federating to AWS, however if we want to add flexibility and allow each user to map to a different role, depending on the type of user, we can assign the role using a profile attribute.
Here a couple of configuration examples/use-cases.
a) Users wanting to have multiple federated logins for different roles in the same AWS account
In this case the AWS account will be the same, but the IdP account will be different depending on the role that the user wants to use. For example a user demo-dev with an attribute/role holding a “Dev” role can map to an account in AWS with a role with certain “development” permissions, while another account demo-prod can hold a different “Production” role in the same attribute/role and map to the same AWS account with a different role with “Production” permissions.
In this case we have two OpenAM IdP login names for the same user account in AWS, each with a different role. In our example we have “demo-dev” and “demo-prod”:
We are going to use one of the user’s profile attributes to set the Role for the user. In this example we will use the “User Alias List” attribute to set it up, but in a real case scenario you might want to set your own specific attribute for it, like for example “AWSRole”.
For this example (as in the previous post) the Attribute “mail” will be used to map the AWS user account and it contains the value email@example.com. The attribute “User Alias List” will be used to map the AWS Wole and it contains the Role value:
- mail: firstname.lastname@example.org
- iplanet-am-user-alias-list: arn:aws:iam::123456789012:role/sso-Dev,arn:aws:iam::123456789012:saml-provider/forgerocklabs
For the “demo-prod” user we will use a different Role:
- mail: email@example.com
- iplanet-am-user-alias-list: arn:aws:iam::123456789012:role/sso-Production,arn:aws:iam::123456789012:saml-provider/forgerocklabs
Now we need to map the attributes of the User Profile to the attributes in teh SAMLv2 ASsertion, this is easy. In the Federation tab, select the AWS Service Provider and go to the “Assertion Processing” sub tab (See previos post for more info on how to get there), and set the Attribute Mapper to:
So it looks like this:
That’s it, now if you use the IdP Inititated SSO https://idp.forgerocklabs.org/openam/saml2/jsp/idpSSOInit.jsp?metaAlias=/idp1&spEntityID=urn:amazon:webservices and login as demo-dev in OpenAM, you will get logged in in AWS as firstname.lastname@example.org/Development and if you login in OpenAM as demo-prod you will be mapped into email@example.com/Production in the AWS console.
Now the other case.
b) Users wanting to have one federated login for different roles in the same AWS account
In this case the AWS account will be the same, and the IdP account will have multiple roles assigned, with a configuration like this then the user will need to select during login time what role to use.
The configuration in OpenAM is the same, except that the User Account should contain all the possible roles it can use. In this example we have the user “demo” with both roles sso-Dev and sso-Production assigned to the multivalued attribute “User Alias List” (as mentioned before this is just for the sake of the example).
The AWS SP Configuration remains the same, but now when using the IdP Initiated SSO URL and login in as “demo”, the user will see a selection menu from the AWS console, indicating he/she needs to select what role to use:
There are more options to configure the OpenAM to federate with the AWS console, the OpenAM flexibility allows to define Custom SP Attribute mappers (plug-ins) to for example construct values out of user profile attributes, session attributes or even external (3rd party) attributes. So depending on your needs there is always a solution using OpenAM.