Role Creation for SAML 2.0 Federation (Console)

Needed Procedure prior to the Creation of a Role for SAML:

For the sake of preparing for the creation of a role for SAML 2.0 federation, you will need to follow the below steps:

1. Prior to heading for the creation of a role for SAML-based federation, you will need to get a SAML provider created in IAM.
2. Get the policies ready for the role which is going to be assumed by SAML 2.0–authenticated users. A SAML federation role will be having the following 2 policies:

– Role trust policy to define the role’s assumers.

– IAM permissions policy to define resources and actions that allowed to be accessed by or denied for the federated user.

Upon the creation of a trust policy for the required role, 3 values need to be utilized making sure that ensure that this role is only assumable by your own app and nothing else.

• Action element: action sts:AssumeRoleWithSAML.
• Principalelement: {“Federated”:ARNofIdentityProvider} Instead of ARNofIdentityProvider place the ARN of SAML identity provider which was previously created in the first step.
• Conditionelement: condition StringEquals. It used in order to test that the saml:aud SAML response’s attribute is the same as that of SAML federation endpoint.

The below is an example of a trust policy which was designed for a specific SAML federated user:

{

“Version”: “2012-10-17”,

“Statement”: {

“Effect”: “Allow”,

“Action”: “sts:AssumeRoleWithSAML”,

“Principal”: {“Federated”: “arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:saml-provider/PROVIDER-NAME“},

“Condition”: {“StringEquals”: {“SAML:aud”: “https://signin.aws.amazon.com/saml”}}

}

}

Instead of placing principal ARN replace it with the actual ARN for the SAML provider which was created in IAM. It’s going to include a provider name and an account ID.

How to Create a Role for SAML?

Upon the completion of the previously required steps, it’s now possible to get the SAML-based federation role created.

Creating an SAML-based federation role:

1. Login to Management Console and head straight to IAM console through the following linke https://console.aws.amazon.com/iam/.

2. From navigation pane, select Roles then click on Create role.
3. Select SAML 2.0 federation role type.

4. At SAML Provider, select which role provider you want for your role.

5. Click on the SAML 2.0 access level method.

– Select the option Allow programmatic access only for the sake of creating a role which is capable of getting assumed programmatically from either API or CLI.

– Select the option Allow programmatic and AWS Management Console access for the sake of creating a role which is capable of getting assumed programmatically as well as through the console.

Both ways will create similar roles, but the role which is capable of being even assumed through the console contains a trust policy that is associated with a specific condition. This specific condition will explicitly make sure that the SAML:aud attribute is specified as https://signin.aws.amazon.com/saml.

6. In the case that you choose to get a role for programmatic access created, select an attribute from the ones found in Attribute list.

After this, enter in Value box a specific value to be added to the role. This will the access of this role to only users from the identity provider that has a SAML assertion which contains the attributes which were set by you. You will need to set a minimum of 1 attribute for the sake of making sure that this role will be limited to a chosen user subset from your company.

In the case that you choose to create a role for programmatic access along with console access, the SAML:aud attribute will be directly included and specified to the SAML endpoint URL which represents this link https://signin.aws.amazon.com/saml.

7. For the sake of including additional attribute-related conditions to this trust policy, select the Add condition (optional), then choose your extra condition, and finally set a particular value.

Keep in mind the following:

In the list you will find the generally relied on SAML attributes. More attributes are supported by IAM for being utilized in the creation of conditions. In case you require a condition, which is not found in the list, you are capable of adding this condition manually. In order to do this manually, you will need to get the trust policy edited after the role creation.

8. Go over the SAML 2.0 trust data then click on Next: Permissions.
9. Your IAM account has a list of managed and customer managed policies. Choose which policy you’d like to utilize for the permissions policy or select the option Create policy for opening a new browser tab and start creating a new policy. Upon completing with the policy creation, get this tab closed then head back to the original tab. Choose the check box which is located beside the permissions policies you selected for your web identity users. In case you’d prefer you get the possibility to choose no policies, but attach them to the role another time. The default is that a role will have no permissions.
10. It’s optional to get a permissions boundary set as a more advanced feature.

Head to Set permissions boundary section and select the option Use a permissions boundary to control the maximum role permissions. Choose which policy you’d like to utilize for permissions boundary.

11. Click on Next: Tags.
12. It’s optional to get metadata added to your role through attaching tags as key–value pairs.
13. Click on Next: Review.
14. As a Role name, enter a unique role name of your choice, which won’t be distinguishable by case. ( APPLICATION and application cannot be both created as role names). Since it’s possible for different resources to reference your role, you will not be able to get the name edited after its creation.
15. It is optional as Role description, to enter a description of your choice for this role.
16. Go over the role then click on Create role.

create a a policy using visual editor