I’ve been exploring LDAP as a userid repository (as can be used by MQ multi platform). This got me into an interesting rabbit warren of Role Based Access Control (RBAC) and Attribute Based Access Control(ABAC), and how you set up your repository to hold userid and access information.
In LDAP on z/OS I can set up a user
dn: cn=adcda, o=Your Company
With this, if I try to logon with cn=adcda, o=Your Company . It will try to use RACF to check the password I specified and the userid in ibm-nativeId (adcda) is valid. I’ve logged on to MQ on Linux using this definition, and had RACF on z/OS check my password. (I thought this was pretty neat).
This definition has an attribute sn ( surName) of adcda and a cn (commonName) of mqadmin.
You can set up statics LDAP groups
These have a list of members
Groups within groups
A group can have a group name to be included
You can display group members
ldapsearch …–b “ldap_team_nested,o=myorg” “objectclass=*” ibmallMembers
You can also have smart, dynamic groups
This is the “new” way of doing it – which has been available for about 30 years.
dn: cn=dynamic_team,o=Your Company
memberurl: ldap:///o=Your Company?sub?(cn=mqadmin)
- query the tree under o=Your Company ( a more realistic subtree would be ou=users,o=Your Company)
- sub, says all levels in the tree (base is search just the specified URL, one is search just one level below the specified URL)
- list all those with the specified attribute cn = mqadmin.
Instead of updating a group – you add information into the user’s entry, and it would get picked up automatically.
Ideally there would be an LDAP attribute “role” which you could use for this. The default schemas do not have this.
If you are using RACF you can set up a userid, and connect it to a group. RACF does not support nested groups for authority and access checking.
Access to resources
Using group or Access Control List
Many systems provides group or Access Control List (ACL) to control access to a resource.
For example you might say users in group MQADMIN can update dataset MQ.JCL, and userids in group MQOTHER can read the MQ.JCL dataset.
This has limitations in that the resources are treated individually, so if you have 10 files, you have to grant a group access to 10 profiles.
Role Based Access Control(RBAC)
I struggled initially to see the difference between RBAC and group or ACLs.
With RBAC you do not give update or read access to a resource, you give access to a “task” or “role” like “Maintain records”, “client admin”, or “clerk”. You then give the tasks the appropriate access. You could implement this at a basic level using groups called MAINTREC, and CLIENTADM to give it update access to the resource, and group CLERK with a read access.
Attribute Based Access Control(ABAC)
ABAC seems to take this further. There are products you buy which can do this for you, but I could not see how it was configured or how it worked. Below is my interpretation of how I might configure it using LDAP.
You could have a user defined like
dn: cn=colin paice, o=Your Company
A set of resources like
dn: cn=doctor update,o=Your Company
This is a list of resources a doctor needs to do their job.
And a set of rules
resource: cn=doctor update,o=Your Company
If someone (Doctor Colin Paice) wants up update a patients record, you can do a query using dynamic groups
- What roles does Colin Paice have?
- What is the resource group for the DB2 table HOSPITAL
- Is there a valid rule for the list of roles for Colin Paice, with the resource group for the table HOSPITAL.PATIENTS, where access is from LONDON, and reason is Patient Update.
Is it that simple?
You have to be able to handle the case when a doctor may only look at the patients notes if the doctor is the “attending physician” – so the person is a patient of the doctor. This might mean a “patientOf: Doctors_name” field in the user’s record.
It looks like you have to be very careful in setting this environment up, as you could have many thousands of rules, and it could be very hard to manage.
Even if it is hard, I think the idea of virtual groups, were you select records based on a criteria is a good idea. It may be faster than using groups because it can exploit the index capability of the underlying database, rather than build lists of group membership.