Using Okta for Conditional Access to AWS Assets with MFA Validation
Okta's integration with Amazon Web Services (AWS) allows end users to authenticate to one or more AWS accounts and gain access to specific roles using single sign-on with SAML.
Here’s how you can further secure this integration with multi-factor authentication (MFA) access using Attribute Based Access Control (ABAC) and dynamic session tags. By implementing this solution, you have the ability to create AWS IAM policies for conditional access based on MFA usage, enabling you to implement additional layers of authentication for critical AWS resources.
AWS IAM Session tags are key-value pair attributes you pass when you assume an IAM role or federate a user in AWS STS (Secure Token Service). You do this by making an AWS CLI or AWS API request through AWS STS or through your identity provider (IdP). When you use AWS STS to request temporary security credentials, you generate a session. When you use the session credentials to make a subsequent request, the request context includes the aws:PrincipalTag context key. You can use the aws:PrincipalTag key in the Condition element of your policies to allow or deny access based on those tags.
AWS supports AssumeRoleWithSAML operation for authentication with SAML-based federation. This operation returns a set of temporary credentials you can use to access AWS resources. For more information about using SAML-based federation for AWS Management Console access, see Enabling SAML 2.0 federated users to access the AWS Management Console. For details about AWS CLI or AWS API access, see About SAML 2.0-based federation. You can pass SAML attributes as session tags with the AssumeRoleWithSAML operation. To pass the SAML attributes, include the Attribute element with the Name attribute set to https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}. Use the AttributeValue element to specify the value of the tag. Include a separate Attribute element for each session tag.
Configure SAML 2.0 for AWS Account Federation
You will require the AWS Account Federation App to configure SAML 2.0 for federating into AWS accounts. Follow the steps outlined in Okta documentation for connecting Okta to a single AWS account. Modify the IAM trust relationship policy to include additional action “sts:TagSession” to allow session tags. Your trust relationship policy should look like the one below:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "<COPY & PASTE SAML ARN VALUE HERE>"
},
"Action": [
"sts:AssumeRoleWithSAML",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
Configure the AWS Account Federation app
To enable passing session tags as dynamic attributes, we must first enable updates for user attributes in Okta provisioning. Go to the Provisioning Tab in the AWS Account Federation App and enable updates for user attributes.
In Okta, you can pass Dynamic Authentication Context to your SAML apps through the SAML assertion during application authentication. We will use session.amr values to pass the session attributes as dynamic tags.
- Go to the Sign On tab.
- Choose Edit, and then expand the Attributes (optional) section.
- In the Attribute Statements (optional) section, enter
- Name as https://aws.amazon.com/SAML/Attributes/PrincipalTag:MultiFactorAuthPresent
- Select Name Format as URI Reference
- Enter Value as Arrays.contains(session.amr,"mfa"). The session.amr object returns an array of values for AMR object. The function checks for the MFA value that is present whenever any MFA factor verification is performed and returns a Boolean value of true if verification is performed or false if verification is not performed.
Attach MFA policy in Okta
Create conditional access IAM policies
Now that you have everything configured and set up to pass dynamic tags as SAML assertion values, you can set up an IAM policy with conditional access to validate this solution. In this example, you will attach two policies to the Role you selected in the above step where you configured SAML 2.0 for Account Federation. You can use the AWS-managed policy AmazonS3FullAccess to allow S3 actions. Next, you will create a customer-managed policy to condition S3 access based on MFA status. The example policy language is given below.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/MultiFactorAuthPresent": "true"
}
}
}
]
}
This policy denies access to any S3 actions for users that have not been authenticated using MFA with Okta. That is based on the fact that an explicit deny overrides any allow statements. You can view our IAM policy evaluation documentation to gain a deeper understanding of evaluation logic.
To test this conditional access, use Okta user credentials without MFA access. Federate into an AWS Console and try to create a S3 bucket. Your access will be denied since the session tag for MultiFactorAuthPresent returns a false value.
Now enable MFA access in Okta by modifying the security policy and trying to create the S3 bucket. This time you will be able to create the S3 bucket. For troubleshooting any issues with access and policies, check the session tag values in CloudTrail record for AssumeRoleWithSAML APIs.
Conclusion
Session Tags enable customers to use Okta’s dynamic authentication context values to build permissions and simplify fine-grained access to AWS resources. This feature helps customers apply conditional access for MFA authentication and enforce an additional layer of security for accessing AWS resources.
