RBAC vs ABAC

Over the last week there has been a very interesting discussion around role based access control vs attribute based access control. My personal opinion is that there really isn't any razor sharp division between the different paradigms and that in many cases a blended solution is what gives best support for the business case. Let me demonstrate what I mean with an example.

The business case is that VPN system needs to be converted from a "if you can authenticate then you have full access" to a system that only gives access to the systems the user needs. The idea is that you somehow can define groups of users that need access to certain systems. For now the only user groups that have been defined are the different company divisions and consultants vs employees but the system needs to be flexible to support other group definitions further down the line.

The access control device supports definition of access groups through either AD groups or through AD attributes. The AD attributes are analyzed in an XACML light module (if attribute company="truck manufacturing" and user_type="employee" -> user_is_member_of_access_group_employee_in_truck_manufacturing). Alternatively the access control device can simply look for users that are member of the AD group employee_in_truck_manufacturing and then apply the access rules for this  group.

This means that at first glance you have a choice between a more ABAC oriented approach (access device looks at attributes and makes a decision) or a more RBAC oriented approach (access device looks at a group membership/role).

The complexity here is how do you populate the attributes and/or place the user in the correct AD group?

Assuming that the attributes exists somewhere, i.e. in the HR system, you can populate the AD record using your favorite provisioning tool at AD account creation time and then maintain them either using the provisioning tool or a separate metadirectory product.

The AD group membership can be solved by implementing a rule based AD group allocation module in the provisioning product. The provisioning product simply evaluates rules written in XACML or other suitable language (LDAP filters, simple boolean logic, regexp) and then provisions AD group memberships.

Now the conclusion you can draw from this is that in the use case where the access control decision is done based on user attributes the essential difference between the two choices is only the exact location of the evaluation logic. Should it live in the run time access control device or should the decision be made in the provisioning product?

In most cases I would argue that the correct choice depends more on the capabilities of respective product. If the decision rules are easily modeled in the rules language offered by the provisioning product then it may make more sense to place the logic there. If the access control offers the better platform then use that.

One advantage of using the provisioning platform may be that it is easier to explain to the helpdesk and the end users that "if you aren't member of the AD group truck_manufacturing_employees then you won't have remote access to the trucking portal" then having to say "if your employee_type attribute is employee and your company attribute is truck_manufacturing then you have access". This is especially true if the attributes contains codes instead of names.

If you want to learn more about ABAC I recommend David Brossard's excellent ABAC primer "Authorization is not just about who you are".

Upgrading MIIS 2003 to ILM 2007

I recently upgraded a Microsoft Identity Integration Server 2003 to Identity Lifecycle Manager 2007. As far as I have been able to determine there are very few differences between these two products other than the fact that ILM supports AD 2008.

MIIS/ILM is basically a quite decent metadirectory engine that also can be used as a poor mans provisioning solution although the total lack of support for requests, approval workflows, self service and recertification to just pick a few of the features you normally would expect in a provisioning solution can be a tiny bit limiting. Microsoft has addressed some of these concerns in Microsoft Forefront that was released earlier this year.

The upgrade process was actually very straightforward.

1. Take backup of encryption key in old MIIS install
2. Take backup of old database (SQL 2000)
3. Import backup into new database (SQL 2005)
4. Put the encryption key on new app server
5. Start install and do some basic configuration
6. Get some coffe and let the upgrade run for about an hour
7. Load up the encryption key in the new ILM install
8. Patch with the latest patch
9. Done

The whole process took about two hours for the db steps and another hour or so for the application step. I was very impressed with the ease of the upgrade process. Normally IDM upgrades are really complex and time consuming so this was a very pleasant surprise.

One interesting feature was that the custom dlls that contain our custom rules actually got copied over to the file system of the new application server automatically. I assume that MIIS/ILM keeps them in form of blobs in the database and the upgrade process copy the files out of the db.

What a difference a year makes

There was a posting in of the IDM groups on LinkedIn today that made me take another look at the 2009 Forrester IAM wave report. The report is getting a bit old but it is sometimes interesting to look back and see what has happend in the IAM market over the last year.

In my opinion the biggest change is clearly the aquisition of Sun and the demise of Sun Identity Manager. Suddenly one of the strongest players in the market just disappeared which opened up a lot of room for other systems. One of biggest winners seems to be Courian that suddenly got a shining example of why buying a suite from one of the big boys doesn't neccessarily mean that you have a stronger support and continued development track in front of you.

Other big changes are IBM TIM 5.1, Microsoft Forefront and Oracle 11g.

TIM 5.1 meant that IBM got substantially improved role management, access recertification and group management. I think largely that the features are well implemented but they really don't have the depth that some of the free standing role management tools have (i.e. Oracle Identity Analytics). Martin Kuppinger at Kuppinger Cole wrote an interesting posting about TIM5.1 in his very good blog.

Microsoft Forefront really means that ILM stops being a glorified metadirectory engine and takes the step into being a proper provisioning platform. If I was in a Microsoft only shop and had a business that was trying to deploy ten different Sharepoint portals (don't they all these days?) I would clearly consider taking a deeper look at the product.

Oracle 11g has a lot of nifty new features that I have been talking about in various posts.

Overall I think that the wave still gives a good overview of the IAM marketspace and I am really looking forward to the 2010 version of the Forrester IAM wave.

(Full disclosure note: I have an immediate family members that works for Forrester)

OIM Howto: Target system group memberships through OIM groups and access policies

In OIM there is often multiple ways to implement the same functionality.

One such case is target system group memberships. In Leverage standard connector group management I described how to leverage the functionality provided by the OIM AD connector to manage AD group memberships. You can also use the exact same functionality as well as the OIM rules, groups and access policies framework to manage group memberships.

1. Create a rule that adds users to an OIM group under certain circumstances (i.e. user location is "New York" or costcenter is 2387)
2. Add an access policy to that group that provisions the AD user object to the user with the group child form row set to give out the appropriate AD group

You can give a specific user more than one AD group through this strategy as the access policy evaluation engine basically adds the union of all child form rows to the process form of the access policy with the highest priority. Where you do run into trouble is if the same AD group membership is given to the same user by more than one access policy. If this happen the second group membership add will result in an error.

Taking the route over OIM groups and access policies has the advantage of making things clearer for administrators as well as auditors. It makes it possible to use certain out of the box OIM reports that covers OIM group memberships as proxies for AD group membership reports which certainly is helpful in certain situations.

OIM Howto: One resource object per target system group

In most cases of target system group management you need to manage a large number of different groups but sometimes you only need to handle a handful of groups. This commonly happens if the primary purpose of the OIM system is to manage some specific target system that actually uses groups on an LDAP server (often AD) to do fine, medium or coarse grained authorization. In some cases access to an application may be granted by an AD group membership (commonly used by portal software such as Plumtree).

In these cases it may be appropriate to create an independent resource object for each target system group. There are some substantial advantages to this approach:

• In the user resource view an administrator will clearly see what target system group or application the user has access to
• Attestation works cleaner
• Out of the box reports works better

There is also nothing that stops you from doing a "mix and match" approach where some AD groups are represented as independent resource objects and other are grouped under a general "Add AD group" resource object.

The implementation basically follows the steps in Support for request based OIM group memberships other than the fact that you will not need any object form as the group name is reflected in the resource object itself.

The downside of OIM resource object proliferation

The basic function of a resource object in OIM is to represent access for a specific user to a specific system. In many OIM architectures you chose to leverage the resource object to represent all kinds of entities in order to make the entity requestable in the request interface or attestable in the attestation framework.

Examples of entities that can be modelled as resource objects are:

• AD group memberships (adds as well as removals)
• Updates to process forms with approval workflow (with triggerd tasks or with entity adapter)
• Contractor extensions
• OIM group memberships

One problem you will get if you have a lot of "transaction oriented resource objects" is that the user resource view can get drowned in objects so that it is hard for the OIM administrators to find the resource object instances that they really are interested in. Lets say that you have a user that has worked for the company for five years and have twenty AD group membership adds, five removals and ten resource object instances that represents user data updates. This user will have thirtyfive extra resource object instances in his resource object instance view.

You can of course argue that the state changes and group memberships should be properly recorded in the user's resource object instance view (it is not a bug, it is a feature!). If your customer insists that it will look ugly and limit administrator productivity you can simply change the design to have the resource object being raised against a dummy organisation or user. Simply add the real target user login to the object and process form and problem is solved.

Well, of course excluding training the end users about the fact that they need to pick "AD group user" instead of "John Smith" as the user when they want to request an AD group membership for John Smith. Depending on how big your user population with request generation privileges this may or may not be a problem.

OIM 11g: Approval Workflow Orchestration with BPEL

In OIM pre 11g you were basically forced to implement decently complex approval workflow in Java code as the built in workflow editor simply didn't support more complex workflows. Coding the approval workflow was not a big problem if you had basic Java programming skills but it did mean that the person that did the approval configuration had to be a programmer.

Implementing in code also meant that the implementation really lacked agility. You do need to test code more extensive than configuration and that means that your cycle time will be longer than if you could create approval workflows through configuration.

In OIM 11g approval workflow configuration is done through BPEL. This means that you can get a business analyst with BPEL skills to do most if perhaps not all of the approval configuration and there are many more people with BPEL skills than OIM approval API available on the market.

It is clear that this was a long overdue improvement of OIM that will help customers both to have quicker and less painful implementations as well as improving the maintainability of OIM.

One thought that kind of strikes you is that this may be the first step to move more and more of the workflows in OIM from the mysterious objects in the design console and the Java API code into the world of BPEL. Interesting concept isn't it?