Overview
Amazon Web Services (AWS) supports federated authentication with SAML2 and OpenId Connect standards. This gives capability to login to AWS Management console or call the AWS APIs without having to create an IAM user in AWS for everyone in your organization.Benefits of using federated single sign on login for AWS access
- No need to create IAM users in AWS side
- If organization having existing user store, we can use it as the user base for AWS
- You can use single identity for user, all over the systems used by your organization
- This makes administrator life easier when user onboarding or offboarding to the organization
In this tutorial we are going to look at following integration scenarios;
- Connect WSO2 Identity Server (WSO2 IS) to single AWS account
- Connect WSO2 Identity Server to multiple AWS accounts
1. Connect WSO2 Identity Server to single AWS account
Business Use case : Your organization owns a AWS account and need to give different level of privilege access to AWS console to organization users.
How to configure WSO2 IS to support this: This tutorial explains the required steps for this including Multi Factor Authentication (MFA) https://medium.facilelogin.com/enable-fido-multi-factor-authentication-for-aws-management-console-with-wso2-identity-server-57f77e367f41
2. Connect WSO2 Identity Server to multiple AWS accounts
Business Use case : Your organization can owns multiple AWS accounts (eg: Development, Production), you need to assign different level of permissions in these accounts using the existing identity used for users in organization user store (ldap, jdbc etc).
How to configure WSO2 IS to support this:
Following tutorial explains required configurations for this.
Following tutorial explains required configurations for this.
We assume a user Alex in organization ldap, which need to give EC2 Admin permissions in development AWS account and need to have only EC2 read only access to the production AWS.
Business Requirements:
- Organization use WSO2 IS as the Identity Provider (IdP). Use same IdP to authenticate users to AWS Management console as well
- User Alex in organization should be able to log into development AWS account as an EC2 admin user
- Alex should be able to log into production AWS account using the same identity, but only with EC2 read only access
- Alex should be able to switch role from development account to production account
Configuration Guide
1. Configure AWS
1.1. Configure AWS Development Account
Step 1: Configure WSO2 IS as an Identity Provider in Development Account
a. Log into AWS console using development account, navigate to Services, then click on IAM
b. Click on "Identity Provider" from left menu and then click on "Create Provider"
c. On the prompt window provide following info and click on "Create"
Provider Type : SAML
Provider Name: Any preferred name as identifier (eg:wso2is)
Metadata Document: Need to download WSO2 IS IdP metadata file and upload here. Following is the instructions to download IdP metadata file from WSO2 IS.
Login to WSO2 IS management console as admin user. Navigate to "Resident" under "Identity Providers" left menu. In the prompt window, expand the "Inbound Authentication Configuration", then expand the "SAML". There you can find the "Download SAML Metadata" option. Click on it, this will give option to save IdP medata in medata.xml file. Save it to local file system and upload it in AWS IdP configure UI as the Metadata Document.
AWS IdP configuring UI
d. Locate the Identity Provider that we created and make a copy of Provider ARN value. We need this value later in the configurations.
Step 2: Add AWS IAM roles and configure WSO2 IS Identity provider as trusted source in these roles
a. We need to create a AWS IAM role with EC2 Admin permissions since Alex should have EC2 Admin privileges in development AWS account.
Option 1 : If you have an existing role.
If you have an existing role with EC2Admin permissions, then we can edit the trust relationship of role by giving SSO access to WSO2 IS identity provider. If you do not have an exiting role, move to the option 2 which describes with adding a new role.
Click on the desired role -> Go to "Trust Relationships" tab and click on "Edit trust relationship"
If your current trust relationship policy is empty for this role, you can copy and replace following policy configuration there after replacing the <Provider ARN Value of IdP> value (i.e the Provider ARN value that you taken in step1)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<Provider ARN Value of IdP>:saml-provider/local-is"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
If you have a current policy in place, then you need to edit existing policy and include SSO access for WSO2 IS.
Option 2 : Create and assign permissions to a new role.
Option 2 : Create and assign permissions to a new role.
Go to "Roles" and Click on "Create new role". Select the role type as "Role for identity provider access" since we need to allow SSO access using WSO2 IS.
Select wso2is as the SAML provider and click Next.
On the next step just verify the trust policy and click on Next.
Select your preferred policy to be assigned to the role that you are creating. As per our sample scenario, we need to assign "AmazonEC2FullAccess" policy to give EC2 Admin permissions to this role.
Give a preferred role name and click on "Create". (eg: Dev_EC2_Admin)
b. Locate the Role ARN value in role summary page and make a copy of the value. We need this value later in the configurations.
Now we have configured WSO2 IS as a SAML Identity Provider for development AWS account and also created a role with EC2 full access permissions allowing sts:AssumeRoleWithSAML capability to WSO2IS saml-provider.
1.2. Configure AWS Production Account
Step 1 : We need to repeat the same step we did for development account previously with the step 1 and configure WSO2 IS as an Identity Provider for production account as well.Step 2 : Similar to we created Dev_EC2_Admin role in development account, we need to create EC2ReadOnly role in production AWS account. (As per our sample scenario, Alex should have EC2 read only access to the production AWS account). Only difference is you need to select the appropriate policy (AmazonEC2ReadOnlyAccess) for this role. Refer following which highlights only this step.
Once the role is created, make a copy of Role ARN value of this role as well. We need this value later in the configurations.
1.3. Configure account switch capability from AWS development account's Dev_EC2_Admin role to production account's Prod_EC2_ReadOnly role
a. Login to the AWS development account and configure an IAM policy that grants privilege to call sts:AssumeRole for the role that you want to assume (i.e we need to assume Prod_EC2_ReadOnly role in production account). To do this,1. Select "Policies" in the left menu and click on "Create Policy" option. Pick the "Create Your Own Policy" option there.
2. Give a relevant name for policy name and copy the following policy configuration after replacing <Prod_AWS_Account_Id> and <Prod_AWS_EC2_ReadOnly_Role> values as the content.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::Prod_AWS_Account_Id:role/Prod_AWS_EC2_ReadOnly_Role"
}
]
}
3. Attach the policy that we created in previous step to Dev_EC2_Admin role in development account. For this, click on the role name and click on "Attach Policy" in resulting window.
Now we have given permissions to Dev_EC2_Admin role in development AWS account to to assume the role Prod_EC2_ReadOnly in production account.
b. Login to the production AWS account and edit the trust relationship of role Prod_EC2_ReadOnly, by adding development account as a trust entry. To do this,
1. Click on the role name "Prod_EC2_ReadOnly" and navigate to "Trust relationships" tab and click on "Edit trust relationship" option.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::222222222222:saml-provider/wso2is-local"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<Dev_Account_Id>:root"
},
"Action": "sts:AssumeRole"
}
]
}
We are done with the AWS configurations. We need to configure WSO2 IS to SSO with these two accounts now.
2. Configure AWS app in WSO2 IS
1. Login to the WSO2 IS Management console, then navigate to Main -> Service Providers -> Add from the left menu. Provide any proffered name to "Service provider name" (eg: AWS) and click on register.
2. In the resulting window, expand the "Claim Configuration" section, then select the "Define Custom Claim Dialect" option and do following claim mapping.
https://aws.amazon.com/SAML/Attributes/Role -> http://wso2.org/claims/role https://aws.amazon.com/SAML/Attributes/RoleSessionName -> http://wso2.org/claims/emailaddress
3. Expand the "Role/Permission Configuration", then "Role Mapping" and add following role mappings.
What we do here is, map local roles in wso2is to AWS roles. We have two ldap roles called "dev_aws_ec2_admin" and "prod_aws_ec2_readonly" which assigned to organization users to give required access to AWS developer and production account.
When you do the mapping pick relevant role in your organization user store instead of dev_aws_ec2_admin and prod_aws_ec2_readonly. Also relevant Role ARN and Provider ARN values from each account.
dev_aws_ec2_admin -> Role_ARN_Of_Developemnt_Account,Provider_ARN_Of_Development_Account prod_aws_ec2_readonly -> Role_ARN_Of_Production_Account,Provider_ARN_Of_Production_Accounteg:
dev_aws_ec2_admin -> arn:aws:iam::222222222222:role/Dev_EC2_Admin,arn:aws:iam::222222222222:saml-provider/local-is
prod_aws_ec2_readonly -> arn:aws:iam::111111111111:role/Prod_EC2_ReadOnly,arn:aws:iam::111111111111:saml-provider/wso2is-local
4. Expand the "Inbound Authentication Configuration", under that "SAML2 Web SSO Configuration" and select "Configure".
In the configuration UI, provide following fields and click update.
Issuer : urn:amazon:webservices Default Assertion Consumer URL : https://signin.aws.amazon.com/saml Enable Attribute Profile: Checked Include Attributes in the Response Always: Checked Enable IdP Initiated SSO: Checked
5. Open the IS_HOME/repository/conf/user-mgt.xml and find the active user store configuration there. Change the MultiAttributeSeparator value to something different from comma (,) and restart the server.
Example:
<Property name="MultiAttributeSeparator">$$</Property>
Why we need to change this MultiAttributeSeparator value is, this property is used to separate the multiple attributes. By default this is set to a comma (,). But since we need to use AWS Role ARN, Provider ARN as a single value, we need to change it's value to something different from comma.
We are done with all configurations.
3. Testing
1. Before access AWS console, login to the WSO2 IS Management console and confirm whether user Alex is having required roles assigned. Also Alex's user profile has been updated with his email address which mapped as RoleSessionName claim in AWS.
2. Access the AWS console using following url. (Replace the <WSO2IS-HOST>:<PORT> as relevant).
https://<WSO2IS-HOST>:<PORT>/samlsso?spEntityID=urn:amazon:webservices
3. Previous step will redirect you to WSO2 IS login page and once user Alex provided credentials and authenticated, AWS will provide it's role selection page where user can pick the role for current session and continue.
4. Alex can switch role from development account to production role using either switch role option provided in AWS console or the Switch Role URL associated to AWS role.
AWS switch role url can be found in the role detail. Usually this is in the format of;
https://signin.aws.amazon.com/switchrole?account=<AWS_ACCOUNT_ID>&roleName=<AWS_ROLE_NAME>
If you provide production account id and role as "Prod_EC2_ReadOnly" in the above URL, you can see that Alex can switch to production account's Prod_EC2_ReadOnly role from development account where he was logged in.
