By using AWS re:Post, you agree to the AWS re:Post Terms of Use

Unable to map AWS SSO Attributes to SAML Assertion values

1

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

5 Answers
1
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.

profile pictureAWS
answered 3 years ago
profile picture
EXPERT
reviewed 5 months ago
1

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

answered 3 years ago
  • Glad that you got sorted, Sandeep.

    As for your follow-up question - If the attribute and value are present on the user principal in AWS SSO, and you have them in the AWS SSO ABAC list, then you can use them in ABAC IAM Policies, yes. You won't hav to go down the route of using "user.city" in your IAM Policy, however. Have a look at this blog on the matter, as it explains and demos it quite nicely.

1

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}

answered 3 years ago
1

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

profile picture
EXPERT
answered 3 years ago
0

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

answered 3 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions