Attribute Based Access Control for Amazon Web Services

The ForgeRock Identity Platform helps modern enterprises implement fine grained access control across a variety of resources and target systems. With Amazon Web Services launching session tags, this capability is now extended to one of the more valuable assets for an enterprise: it's cloud resources.

Session tags give customers the ability to pass identity attributes from the ForgeRock Identity Platform into an AWS session and create permissions rules in AWS IAM based on these attributes. This attribute-based access control model (ABAC) is helpful in environments that are growing rapidly, where role explosion becomes a problem. 

An example of how this feature would be used is an organization that has three projects hosted in AWS called Heart, Sun and Lighting with the following configuration:

• A role called “developer” in AWS IAM with the access-project tag key.

• Federation from AWS to ForgeRock Access Management (AM) to allow Single Sign On, allowing employees to log in with their corporate credentials. 

• A single IAM policy that allowed user access when the role and the resource are tagged with the same value for access-project.

You can learn more about ABAC in AWS here.

 

 

Configuration

Below, I will explain how to configure ForgeRock AM to pass the necessary identity attributes to take advantage of an AWS IAM policy that leverages tags. The term tags and attributes are used interchangeably. This blog assumes that AM is already acting as an identity provider to AWS either as a SAML Identity Provider (IdP) or an OpenID Connect Provider (OP). The following links provide information about configuring ForgeRock AM and AWS IAM for SAML federation:

• Configure AM as a SAML IdP here

• Configure AWS IAM as a SAML SP here

 If you’d like to configure ForgeRock AM and AWS IAM for Open ID Connect federation:

• Configure AM as an OIDC Provider here

• Configure AWS IAM as a client here

SAML:

To take advantage of Session Tags, the SAML assertion that AM sends must contain attributes that are prefixed by PrincipalTag:team. To map these attributes from attributes in the directory, log in to the AM console and navigate to your Realm > Applications > Federation > Entity Providers > and select “urn:amazon:webservices” service provider. Next select Assertion Processing and under “Attribute Map”, add the relevant mappings. Mapping are defined as SAML Attribute Name=Profile Attribute Name. For example, to send the session tag called access-project you could add the following mapping: https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-project=access-project.

The other attribute that AM can optionally send is called TransativeTagKeys. Transitive tags are optional attributes that specify the set of attributes that customers want to persist from session to session. This helps in a role chaining scenario, where a user moves across AWS accounts, but the session tags should remain present. Keep in mind that only tags included as PrincipalTags in the assertion can be set transitive.

OIDC:

To take advantage of Session Tags during an OIDC flow, the id_token that AM sends after authentication can must pass the https://aws.amazon.com/tags claim. This claim must come in the form of a map within the id_token. An example of the decoded id_token can be seen below:

{
  "sub": "demo",
  "aud": "ac_oic_client",
  "jti": "ZYUCeRMQVtqHypVPWAN3VB",
  "iss": "https://xyz.com",
  "iat": 1566583294,
  "exp": 1566583354,
  "auth_time": 1566583292,
  "https://aws.amazon.com/tags": {
    "principal_tags": {
      "access-project": [
        "Heart"
      ]
    },
    "transitive_tag_keys": [
      "access-project"
    ]
  } 
}

 

To alter the id_token that AM creates, navigate to your Realm >Scripts and select the OIDC Claims Script, which is the default script used for an OIDC provider. Here, you are able to map attributes stored in the Directory Service to claims sent on the id_token.

 

 

 

Similar to the SAML flow, you can pass both principal_tags and transitive_tag_keys to set the session tags as well as the tags that should persist from session to session.

In conclusion, ForgeRock is excited to see AWS embracing identity standards to make the use of cloud resources more secure. With identity practices such as zero trust, and an increasing number of threat vectors, centralized attribute-based access control is a requirement for a modern enterprise. This powerful capability is available out of the box by the ForgeRock Identity Platform and shows great synergy in the ForgeRock/AWS partnership.