Negative roles

[kuronen]

With standard edition I've used to doing my own 3 level role system where I've implemented so called negative roles or override roles. In practise it works like this:

- I have several roles configured, including "Employee" that entitles user to AD and LDAP
- Also several detailed roles are configured such as "LDAP access" or "AD access" to provide additional control for easy administration
- A test person has a role "Employee" but I dont want him to access LDAP
- I add him a a negative role "LDAP access"
- System removes the entitlements configured for "LDAP access"
- The result is a user with roles "Employee" and "-LDAP access" with only entitlement for AD

How do you do similar functionality with Userapp?

[klasen]

On 2019-06-07 07:34, kuronen wrote:
> How do you do similar functionality with Userapp?

The AE role model does not support excludes.

--
Norbert

[lhaeger]

kuronen wrote:

> - I have several roles configured, including "Employee" that entitles
> user to AD and LDAP
> - Also several detailed roles are configured such as "LDAP access" or
> "AD access" to provide additional control for easy administration
> - A test person has a role "Employee" but I dont want him to access
> LDAP
> - I add him a a negative role "LDAP access"
> - System removes the entitlements configured for "LDAP access"
> - The result is a user with roles "Employee" and "-LDAP access" with
> only entitlement for AD
>
> How do you do similar functionality with Userapp?

You would greate Level 20 roles for AD and LDAP and have a Level 30 Employee
role containing both Level 20 roles. Then you add a Test User Level 30 role
that only gets AD but not LDAP as Level 20 child roles.

Role models are additive only for a reason. What you've been implementing
quickly turns into a nightmare in larger role catalogues and is both hard to
follow and hard to maintain once you delegate Level 30 role definitions to the
business units that actually need them. You should build your role model to not
require overrides or "negative roles" as you called them.

If you use this feature for test users only, It might be better to flag them as
such (e.g. employeeType=testaccount) and take care of them during entitlement
implementation instead (e.g. permanently disable their account in LDAP instead
of not giving them one at all). That way your test accounts would be more
similar to real accounts and tests overall more "end to end"-ish.

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)

[kuronen]

The override role model has worked very well with quite large universities. Problem is more situated in business processes where we've had to be very strict. People coming from the registry sources play by the registry, not by the IT administration. IT department is not HR and not authorized to be the source registry for user data. I've seen organizations where the IT administration (leadership) softens up with organizational demands resulting to whole IT dept jumping by every request making exceptions after exceptions. In those situations I suppose technical limits is one way to set some limits to the madness, even if the problem is more in the business processes.

You mentioned the word "flagging". I could go around the problem leaving the role automation strict but in case of exceptions i could flag the user as manually operated. Thanks for the idea.