Our experts are thinkers AND doers focused on accelerating business outcomes. To showcase our deep expertise, we created a blog series called “The Digital Build.”

Federated Identity is a process of establishing trust between sources for authenticating users and distributing information needed to authorize access to resources. Single Sign-on is a subset of the federation identity which allows the user to authorize and access data using a centralized domain. The goal of federated Identity is to provide users of a particular domain to successfully authenticate and authorize the resource in another domain without the burden of redundant user administration.

Now, when providing the user federation, the user must be given access permissions that authorize only the permissions dedicated to them. The permissions need to be set for an identity in IAM (Identity and Access Management). This can be achieved by assuming a role, which returns a temporary credential for the user to achieve the task. The temporary credentials include Access Key ID, Secret Access Key, and Security Token.

In AWS (Amazon Web Services), ways to set permissions in IAM are as follows:

1. AWS-managed policy: AWS-managed policies are independent policies that are produced and maintained by AWS. These policies are termed “standalone policy,” which refers to a policy that has its own Amazon Resource Name (ARN) containing the policy name.
2. Customer-managed policy: Customer-managed policies are standalone identity-based policies that you simply create, and will be attached to multiple users, groups, or roles in your AWS account. Users will be able to manage and build policies using the AWS Management Console, the AWS Statement Interface (AWS CLI), or the IAM API (Application Programming Interface).
3. Inline policy: Policies are created, managed and embedded directly into a single user, group, or role.

The above-mentioned ways can be used to generate a Federated URL. The Federated URL, along with the sign-on URL and Cloud Identity Service, constructs a digitally signed token that may be verified (and therefore trusted) by the partner organization. The URL has permissions encrypted as session tokens, which allows the user to access the service provider for the amount of time specified. Federated URL can be generated using AWS Security Token Service (AWS STS) as an internet provider that permits you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) customers or for customers you authenticate (federated customers).

The privilege consists of a response element which indicates by a percentage of how close the policies and tags for your request are to the upper size quota. This size calculated is referred to as “Packed Policy Size.” These policies have a maximum size between 2048 characters and 10240 characters, depending on what entity the policy is attached to.

The efficient way to set IAM permissions among the mentioned ways seems to be using the Managed Policy, which is a standalone policy administered by cloud providers. In AWS, the Managed Policy is depicted as “Amazon Resource Names” (ARN) and the least being the Inline Policy since in the latter case, the policy is custom created and has the situation of using more characters which increases the possibility of larger packed policy size.

The maximum time that a user can use that federated URL is from 15 minutes up to 12 hours.

Simple Visualization of calculating the packed policy size in a Federated URL:

Let us consider a situation where an organization has an AWS root account and wants to give temporary access to the marketing team to have read-only access for all S3 buckets rather than allowing them all privileges. As mentioned, in the ways to set permissions in AWS, there are three ways to provide them with the required permissions (AWS-managed policy, Customer-managed policy, and Inline policy).

Below is the code snippet which helps us determine the packed policy size:

1. AWS Security Token Service enables us to request temporary, limited-privileged credentials for Identity and Access Management (IAM) users or for users that you authenticate (federated users).

2. The ‘AssumeRoleRequest‘ for a particular user with a specific role ARN. The ‘AssumeRole’ API helps the AWS admin to specify the duration for which the temporary credentials generated are valid.

3. Since, in the above scenario, the admin needs the external user to just have the read-only S3 access, let us consider two ways to add read-only S3 permissions to the above ‘AssumeRoleRequest.’

The above two scenarios can also be used together when both Inline Policy and a particular ARN must be used. When using the method of ARN, a restriction of 10 ARNs (Amazon Resource Names) at maximum is provided, or else the exception is thrown by SDKs.

The above scenario shows the Read-only access for S3, but the policies can have a mixture of any permissions required like read-only S3 access and Full EC2 access, etc.

4. Now that we have added the required role, duration, and the necessary permissions, the temporary credentials must be generated for the user to access the console / have programmatic access.

The “fedTokenResult” will hit a successful result only when the Packed Policy size is lesser than 100% or the exception “PackedPolicyTooLargeException” will be thrown.

To get the Packed Policy size, the snippet below can be used:

The “fedCredentials” will result in temporary credentials like “AccesskeyID“, “AccessSecretKey” and “SessionToken.” These credentials can be used to generate a Federated URL / gain programmatic access for the given permissions.

Special case in Assuming a Role:

When a user is trying to assume a second role provided by the cloud, for example: when User 1 has the permission to assume Role A and Role B, then the maximum time the user gets restricted is about an hour. According to AWS support, this hour restriction for role chaining is for security consideration. Say if the credentials are compromised in this case, then AWS does not want to leave an avenue to use the credentials to extend the role chaining indefinitely.

The workaround suggested is to assume the target role directly instead of role chaining. This can help us to use up to a max 12-hour duration.

Also, considering the use of IAM permissions using Managed ARN will be a better option since this is managed by the cloud provider; the Internal Packed Policy size calculation is less compared to using a custom Inline Policy.