Unfortunately, we ran into what I think is a big limitation for SSO. We had the option enabled to set custom roles alongside SSO - which was VERY hard for our team to implement, since we had to modify our SSO response to include values that inSided wanted, rather than having an interface to map already existing attributes to make descisions about roles - i.e we already had data in the response to identify the correct roles.
Anyway, with that out of the way, we came to learn that ANY manual modifications to use roles via control will get overridden by SSO upon next user login. For us, this is a deal breaker because we will have several scenarios where we need somebody to be in a role to gain access to specific categories which cannot be assigned via SSO. For example, we had planned to leverage the community to run a beta program. Now we have to somehow edit our SSO response to identify a beta customer - which may only be 10 users at a time? that does not make sense to me. Likewise, new customer onboarding is a use case we are pursueing right now - we do not have a way to easily detect a ‘new customer’ between our systems so its not possible for us to add this to the SSO response. Our workaround would be to use API or just have a trigger in gainsight to tell our community admin to add them into the correct role.
Right now we have custom roles disabled, and luckily we have a strong engineering that built a script that checks for new users and assigns roles every hour. That is NOT ideal, since it could be up to an hour before a user gets access to a place they need to be in (i.e new customer).
Given the these paramters, the idea here is to allow an option to manually add ‘additional’ roles to a user via control, and NOT have it overwritten via SSO. These are only in addition to the role IDs defined in the SSO response. I do not mind if a change in the group IDs in the SSO response enforces a custom role change, but if the role was configured manually it should be left alone.
Thought:
User1 belongs to roles 5,10,15 in SSO. In control we add them to role 20.
User1 continues to be part of 5,10,15, 20 upon next login.
A change occurs and SSO now has the user as 1, 10, 15
Next time the user logs in, their roles should be 1, 10, 15, 20