Unable to map AWS SSO Attributes to SAML Assertion values

Question

Hi,

I am sending the following user level attributes as part of SAML assertion from Okta.

```
Attribute 1 name: https://aws.amazon.com/SAML/Attributes/AccessControl:team 
Attribute 1 value: user.team
Attribute 2 name: https://aws.amazon.com/SAML/Attributes/AccessControl:Division 
Attribute 2 value: user.division
```

Below are configured  Attributes for access control in SSO (tried many combinations):
```
Key Value
team	${path:team}
Division	${path:division}
ad	${path:appdiv}
Mteam	${path:user.team}
MDivision	${path:user.division}
Mname	${path:name.givenName}
```

Cloud trail history entry for SAML:
```
“requestParameters": {
        "sAMLAssertionID": "_1f0a7019-a9bb-461d-afc3-4e468e29f36c",
        "roleSessionName": "saxxxxxla@xxxx.com ",
        "principalTags": {
            "MDivision": "",
            "Mname": "Sandeep",
            "Mteam": "",
            "Division": "",
            "team": "",
            "ad":""
        },
```
Cannot see team and Division getting populated

Used SAML tracer to see assertion detail going from Okta to AWS: Okta is sending Attributes with values populated

Any thoughts on where am I going wrong?

Thanks

Accepted Answer

Both jsonc@ and posquit0@ are correct here.

1. jsonc@ is correct in saying that the reason why your values are not populating is because you're passing them as attributes of 'user'. If you wish to see them reflected in AWS SSO, then move to using the following, instead:
   * ${path:name.familyName} for the first name of your user.
   * ${path:enterprise.division} for the division name that the user belongs to.
2. posquit0@ is correct, too. If you don't care about seeing the fields and values reflected in AWS SSO, but want to pass them in the assertion and leverage them for ABAC in IAM Policies, then simply remove all attribute configurations in AWS SSO ABAC (leaving it enabled) and build your policies to expect the attributes & values that you're passing. AWS STS will pick up on these as they're passed in the SAML Response and they will be used against any applicable/enforced IAM Policies.

Whichever works best for you, but I would think that if you're going to the effort of passing the attributes and values, you would want to see them reflected in AWS SSO. It also means that you can see what is configured in AWS SSO ABAC and what values each user has, and don't then have to simply remember what you're passing over from Okta.

Answer

I'm wondering if it's because attributes for access control have a list of supported attributes.

From documentation, "The following table lists all external identity provider (IdP) attributes that are supported and that can be mapped to attributes you can use when configuring Attributes for access control in AWS SSO. When using SAML assertions, you can use whichever attributes your IdP supports."

https://docs.aws.amazon.com/singlesignon/latest/userguide/attributemappingsconcept.html#supportedidpattributes

Could you try ${path:enterprise.division} and see if that works?

Examples of supported values:
${path:enterprise.employeeNumber}
${path:enterprise.costCenter}
${path:enterprise.organization}
${path:enterprise.division}
${path:enterprise.department}
${path:enterprise.manager.value}

Answer

Just delete all configured attributes from `Attributes for access control` in the AWS web console. It will just works with SAML assertions.

Answer

Hi Jsonc/Pos/Ciaran,

Thank you for your responses. I managed to get it working but could not update my findings here in time. Apologies.

I was able to make the below changes to AWS SSO App in Okta with attribute mappings.

===============
Worked
===============
```
Okta - AWS SSO APP (Sign On attribute mappings)
Name => Value
https://aws.amazon.com/SAML/Attributes/AccessControl:user.team => user.team
https://aws.amazon.com/SAML/Attributes/AccessControl:enterprise.division => user.division

AWS SSO Changes:
Key    =>       Value 
team =>	${path:user.team} 
division =>	${path:enterprise.division} 
Mname =>	${path:name.givenName}

Cloud trail history entry for SAML:
  "requestParameters": {
        "sAMLAssertionID": "_409ef549-04ab-4bd5-9f0d-3d8f06e7ce14",
        "roleSessionName": "sanxxxxx@xxxx.com",
        "principalTags": {
            "division": "IT",
            "Mname": "Sandeep",
            "user.team": "red",
        }
```

This did the trick. It was interesting to see AWS only recognized these values only when it has user or enterprise in the name of attributes passed through SAML Assertion.

===============
Did NOT work
===============
```
Okta - AWS SSO APP (Sign On attribute mappings)
Name => Value
https://aws.amazon.com/SAML/Attributes/AccessControl:team => user.team
https://aws.amazon.com/SAML/Attributes/AccessControl:division => user.division

AWS SSO Changes:
Key    =>       Value 
team =>	${path:team} 
division =>	${path:division}

```

One follow-up, do I need to map attributes in SSO for profile attributes passed through SCIM or do those automatically get passed on as Session Tags & can I just use them in policies as "PrincipalTag/user.city"?

Thanks,
Sandeep

Answer

Thank you @Ciaran Carragher. Will look at the blog.

Unable to map AWS SSO Attributes to SAML Assertion values

=============== Worked

=============== Did NOT work

Relevant content