[midPoint] How to treat roles and groups in a different way

[Shawn McKinney]

> On Oct 11, 2016, at 10:01 AM, Ivan Noris <ivan.noris at evolveum.com> wrote:
> 
> from what I see now:
> 
> - role in midPoint can do anything, including putting accounts to groups, or setting attributes for accounts
> 
> - in your case, I think two resources would be required: LDAP resource and Apache Fortress (REST) resource
> 
> - roles can be configured to set either LDAP groups (as in our numerous samples) or any attributes required by Apache Fortress or both
> 
> - one role can provision accounts in LDAP, Apache Fortress or both. It's actually an abstraction above the groups or whatever application uses for similar purposes
> 

If I may interject.  I see the 2nd resource (rest) as a red herring as it would be best to cover both with LDAP.

In order to understand what kinds of data ops the LDAP resource must do we need a clarification of what a fortress ‘role’ is and how its assignments work.

A fortress role is ‘just’ an ldap group w/ some addition attributes for setting temporal constraints.  Here’s an example in ldif:

dn: cn=emrole1, ou=Roles, ou=RBAC, dc=example,dc=com
ftCstr: emrole1$0$0800$2300$20120101$none$none$20130101$23456
roleOccupant: uid=emtestuser1,ou=People,dc=example,dc=com
objectClass: top
objectClass: ftRls
objectClass: ftProperties
objectClass: ftMods
description: em test role 1
ftRoleName: emrole1
ftParents: emrole2
cn: emrole1
ftId: 1634a3d6-fbc6-4972-a810-6377665a69ed

Here the ftRls object class is structural and subordinate to organizationalRole, which uses roleOccupant to contain members but those types. You can see there are also some additional attributes for storing the default temporal constraints.

The occupant, emtestuser1 which means they have been ‘assigned’ this role.  

In a fortress LDAP DIT role assignments point both ways.  First it is as listed above.  This is good because it works with traditional access control mechanisms outside of fortress control.  It is also good because it makes the role-user query available in one ‘read’.  i.e. given a role, we know who the users are.

But there is also this user-to-role assignment in the user tree:

dn: uid=emtestuser1, ou=People, dc=example,dc=com
displayName: emtest user1
ftRC: emrole1$0$0100$2359$20120101$none$none$20140101$1234567
ftRA: emrole1
objectClass: top
objectClass: inetOrgPerson
objectClass: ftUserAttrs
objectClass: ftProperties
objectClass: ftMods
uid: emtestuser1

Here the user’s entry in LDAP points back to the role (group).  Why is this?  

Two reasons:

1. It allows overrides on the role assignment’s temporal constraints.   Each user-role assignment has its own copy of what the valid times and dates for usage are.

2. More efficient user->roles.  i.e. given a user we can get their assigned roles in one read which is faster for runtime processing.

Thanks,
Shawn