Skip to main content


 

Symptoms


We have an In-House developed webservice application that uses API to interact with K2 to initiate and move processes.

We frequently receive the error that a user "does not have rights to Start Process" even though all domain users have been granted rights to start process that the error is referring to.
 

Diagnoses


In case process rights are granted through Domain Users group sometimes may have issues with not being resolved or updated.

By design, if an identity can't be resolved, it is disabled in the identity service cache – It also sets the expireOn value to the current time plus the configured cache timeout.
But, there is no real way to know whether it couldn't resolve the identity because it wasn't found (no longer exist at the provider), or an exception occurred.
There is some code that handles certain situations when errors occur and then leaves the cache intact, but it doesn't cover all scenarios.
Just as an illustration – If the domain users group's identity is requested to be resolved, and an error occurs, it might set the group as disabled, and when the user's request to return containers, the result won't contain the domain users group seeing that it is disabled causing the authorization error.

To avoid issues with specific process rights for the processes where all users should be able to start then, it is better to use "Everyone" group – this is a special group surfaced in K2 (it is actually not a group in Windows but "Special identity" which only looks like a group). It is the right group to use for the cases where all users should be able to do the configured rights without the overhead of going to the provider or making use of cached data. This group does not need to be cached or fully resolved and any of your domain users will have rights granted through this group in K2. This group is surfaced when you configure process rights in Workspace.

 

Resolution

In case process rights are granted through Domain Users group sometimes may have issues with not being resolved or updated.

By design, if an identity can't be resolved, it is disabled in the identity service cache – It also sets the expireOn value to the current time plus the configured cache timeout.
But, there is no real way to know whether it couldn't resolve the identity because it wasn't found (no longer exist at the provider), or an exception occurred.
There is some code that handles certain situations when errors occur and then leaves the cache intact, but it doesn't cover all scenarios.
Just as an illustration – If the domain users group's identity is requested to be resolved, and an error occurs, it might set the group as disabled, and when the user's request to return containers, the result won't contain the domain users group seeing that it is disabled causing the authorization error.

To avoid issues with specific process rights for the processes where all users should be able to start then, it is better to use "Everyone" group – this is a special group surfaced in K2 (it is actually not a group in Windows but "Special identity" which only looks like a group). It is the right group to use for the cases where all users should be able to do the configured rights without the overhead of going to the provider or making use of cached data. This group does not need to be cached or fully resolved and any of your domain users will have rights granted through this group in K2. This group is surfaced when you configure process rights in Workspace.




 
Be the first to reply!

Reply