Skip to main content

We are using OpenID connect with User provisioning enabled. When a new (previously unknown) user logs on with OpenID Connect, a user record is created and based on the template, automatically assigned to a guest group. This guest group has a startup object with a task that initiates a registration process. The user has to add some additional information and submit this information to be validated by a backoffice system. The backoffice system validates and if valid, removes the user from the quest group and assigns the user to a member group. The user can now logon and gets the menu and functionality of a member.

What happens however is that the provisioning functionality not only assigns the defined user group on creation of a new user, but also on any subsequent log on. So the guest group, while deleted through the API, is assigned again and with that the registration flow is started as well.

My question: is there a way to have a process started only once based on provisioning?
 

An additional question could be: in what situation would it be relevent to execute the provisioning logic on a normal log on?

 

Hi Robert,

The user groups are always re-provisioned for situations where the user groups are completely based on claims. This way, you can automatically revoke and grant user groups on (for instance) AAD user groups. When the user joins an AAD group, they automatically obtain the correct rights in IAM and vice-versa.

You can circumvent the re-provisioning of the guest group by not removing the guest group for the user, but instead setting the end_on for the guest group to yesterday.

This is a bit hacky - the end_on is currently simply not considered when re-provisioning user groups, but we’ll refrain from changing this behavior until there is an option to prevent user group re-provisioning.

Hi Anne,

Thanks. The hacky 😉 solution was the one we had implemented as a work-a-round. W’ll make it the definitive solution for now.

Terms & ConditionsCookie settings