Todd MichaelB.41090 (Customer) asked a question.
Let me briefly explain my workflow for context and then I'll get to my issue:
I log all my users in via our upstream enterprise SAML IDP using Okta's SAML Identity Provider feature and it works well. When a user logs in for the first time using their upstream SAML Identity Provider credentials they get a user entry in the Okta Universal Directory (UD) and I have some group rules that assign them to some local Okta groups that correspond with group names passed via a memberOf attribute from the Identity Provider's SAML assertion. The one customization I have to add (via Profile Editor for Groups) is a custom group attribute called group.friendly_name because group.name is configured to match our upstream enterprise group names and they're long and unusable for my purposes.
Next I need to pass attributes from my Okta AWS SAML application to AWS so I can use them in IAM policies. This is all configured under Applications --> My AWS App --> SignOn --> SAML 2.0 --> Attributes. Here there are two sections: Attributes and Group Attributes.
In the Attributes section, when I try to pass the group.name as a custom attribute like so it works as expected:
Name: https://aws.amazon.com/SAML/Attributes/PrincipalTag:Team Value: getFilteredGroups({my_list_of_group_ids}, "group.name", 100)
Unfortunately, as noted earlier, group.name is unusable so I want to use my custom attribute, group.friendly_name. But when I try to pass this value, it doesn't work:
Name: https://aws.amazon.com/SAML/Attributes/PrincipalTag:Team Value: getFilteredGroups({my_list_group_ids}, "group.friendly_name", 100)
And rather than Okta passing the friendly name, it literally passes the following value in the SAML assertion:
getFilteredGroups({my_list_group_ids}, "group.friendly_name", 100)
I did some reading and the instructions suggest that in order to work with groups, I should move my statement from the Attributes section to the Group Attributes section directly below it.
Unfortunately this doesn't work at all. Not only does it not match, saving it in the console chews up my formatting, replacing all the quotes with their ASCII equivalents. This is probably not an issue in and of itself, but I'm calling out simply because it doesn't work. How can I pass this desired custom attribute to my application?
Appreciate any advice.
Hello @Todd MichaelB.41090 (Customer) Thank you for reacting out to our Community!
You might want to try the Custom group attributes for this, please see our article on this below:
https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-custom-group-attributes.htm
Community members help others by clicking Like or Select as Best on responses. Try it today.
Thanks @Paul S. (Okta, Inc.). Perhaps my long message lacked clarity. I am indeed already using custom group attributes. My issue is that I'm unable to pass the custom group attribute via an application SAML assertion. I can pass the group.name (standard attribute), but I'm unable to pass group.friendly_name (my custom group attribute). The link you shared doesn't go on to explain how to use these group attributes, unfortunately. I'm not even sure if it's possible. That's what I'm trying to sort out. Again, thank you!
@Todd MichaelB.41090 (Customer) Did you manage to solve your issue? I am facing with the same one, can't quite figure it out how to proceed due to lack of proper docs/example.
Hi Igor,
The Solutions Team helped me with this. If you want to do anything with custom attributes you need to use the Okta Workflow Engine. You can setup workflows that will enable you to intercept and freely edit the SAML assertion. They demo'd this for me and it looks perfectly straightforward. I just haven't gotten to it because I subsequently realized that for my purposes at the time, I could setup ABACs that leveraged the Team tag of the assumed role so I haven't yet gotten to the point where I need session tags (from Okta). I eventually will get back to this and plan to use Workflows to get it done. Hope that helps.
have you tried creating a friendly name okta group that contains a rule of specific roles to workaround the issue. Like group.name for example could be a group called Workday_administrator if you need to send over an attribute called administrator just refer it to substring . Not everyone has workflow’s so going to try it another way.