Has anyone ever mapped the remove roles assertion mapping from Okta. We are trying to map removing multiple roles if they have one role. EX if they are a customer we remove Employee and partner. Also if they are Partner remove employee and customer. If Employee remove customer and partner.
Currently Okta is sending the expression as a text not the actual roles to be removed.
Anyone that has worked with Okta and remove role mapping we would love some help on this issue.
Yep - more of a workaround than a fix though as it doesnt remove using assertion mapping.
use okta groups to manage adding the roles by assertion.
then use workflows to remove the role from the user when theyre removed from the okta group or added to a "remove X role group"
you can then use okta group rules to manage which users need to have what role removed and let workflows handle the work - be careful to watch the rate-limits. 🙂
Workflows is an 'extra' with Okta - but you can run five workflows without paying more (plenty for what you're wanting to do)
I'll come back in a bit with screenshots if needed.
I've read some of your other posts on this topic. Would it be possible to either get screen shots of your Okta workflows configuration or an extract? I'm a coworker of tavasjn24 and we're trying to solve the role removal problem and I'd be very interested in how your workflows function.
Our last attempt was to enable Integration on the Okta app even though Khoros doesn't support it. That gave the ability to put an Okta expression into the mapping for an app attribute named removeRolesKhoros like this:
That app attribute is then mapped on the SAML assertion to appuser.removeRolesKhoros
The problem is the mapping triggers when User_Type changes on a user Okta profile but Okta only displays a message that it hasn't been applied yet when the change happens. Only applying the mapping on that single user or pushing Force Sync on the app gets it to apply. 😞
Again any screen shots or the workflow configuration you can share would be a huge help.
So, set up Okta groups. Manage membership to this based off user_type field. then you can use the "user removed from group" trigger in workflows to kick it off.
(photo 1)
In a nutshell - the user is removed from the okta group when the user_type field in their profile changes away from one of the groups you're wanting to monitor.
Being removed from any group triggers workflow 1 - the true false statements check its one of the groups you're monitoring and then if true passes the groupname (and with it the role you are removing) and the required user data into the child flow which uses the khoros API to remove the role.
(photo 1)
(photo 2)
You'll need a child flow that will be responsible for acquiring the users khoros id (if thats not already stored in the users profile) and another that will actually make the api request to khoros directly to remove the role.
(photo 2)
not pictured are two subsequent child flows, one which fetches and updates the users khoros id if its not in their profile - second is the one that fetches the api-key needed to run apiv2 calls.
Our method stores it in a table in okta with a time stamp, when the key is requested it checks its age, if its still valid passes it back, if not requests a new one, stores that in the table and then provides the valid key back to the flow
