kuronen
Visitor.
113 views

Negative roles

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?
Labels (1)
0 Likes
3 Replies
Micro Focus Expert
Micro Focus Expert

Re: Negative roles

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Negative roles

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.)
0 Likes
kuronen
Visitor.

Re: Negative roles

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.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.