On the Webinar that Babak and I did on ABAC and XACML three weeks back, there were quite a few questions that popped up! Unfortunately we did not have time to answer all of them during the webinar, so we promised that we would collect them and answer them afterwards.

BTW today there is another webinar on a related topic: The Critical Role of XACML in SOA Governance and Perimeter Web Service Security

Q: Please, specify the major difference between role mining (role consolidation based on role attributes) and the privilege giving mining approach?

A: (Babak) Role mining is about finding groups of permissions that can be bundled in terms of roles that can then be assigned to users. The idea of privilege-giving attribute mining is to find those attributes that affect permissions and use them to create access rules. Let’s take an example. In a business application, users may have been assigned permissions to Create and Release Purchase Orders, to Maintain Vendor Master data, Release Requisitions, Register Service Entry and Release etc. In a role mining project doing a bottom-up survey of permissions, an analysis of these permissions and how they are grouped into roles will be made. If a role called Purchasing combines all of the above permissions, we would probably identify a Segregation of Duties violation between the rights to Release Purchase Orders and the right to Maintain Vendor Master Data. As a result we would suggest remodeling of the Purchasing role to avoid the conflict. In a top-down approach, Role mining is about identifying a role in business critical processes that will need to be entitled with certain permissions in order to serve its purpose in that process. Role mining projects are typically about top-down and bottom-up combined, which in the end will lead to considerable efforts to map permissions to roles in such a way that everyone is able to do his or her job without acquiring excessive permissions – quite a daunting task.

An Attribute Mining project would very much like the top-down approach in role mining start with business processes to define which RULES for access can be derived. Examples: Attestation of purchase orders exceeding the amount of $xx, can only be made by users who a) belong to the cost center charged and b) have a management level of 10 or higher. From this rule we can derive that the following attributes are privilege-giving: a) user profile’s cost center assignment, b) users management level, c) purchase orders cost center and d) purchase order’s amount. To verify, these attributes would allow a rule to be formalized like this: If user.costcenter = purchaseorder.costcenter and user.managementlevel>=10 and purchase.amount<=$xx then permit else deny.

Q: Tell me more / define better what you mean when you talk about a missing context of the RBACs model?

A: (Babak) What we argue is that RBAC is a static model which makes it difficult to capture the context that may affect an access decision.  If we try to capture the context for an access in terms of roles then we will easily get a role explosion. We may for instance need to differentiate permissions depending on time of day – some users have access only during normal business hours whereas others have 7*24 access. This could lead to the creation of two roles, one for normal business hours, one for extended access. Add other context-related conditions such as remote login, authentication strength, line encryption etc. and we end up with the need to capture very many different roles. It is worth noting that normal ERP systems typically need to handle very large numbers of roles (thousands) internally to capture all their user permissions. If a combined role structure from multiple ERP systems must be established with contextual aspects included, role explosion issues simply become unmanageable.

Q:  I didn't quite get the difference between attribute based access control and rule based access control. can you elaborate?

A: (Felix) In a nutshell, the main difference between ABAC and RBAC is that RBAC revolves around the concept of the role. ABAC can use any attributes (including the role) so it is much more flexible.

A:  (Babak) Attribute based access control is not in conflict with rule based access control. Rule based access control is about creating rules defining access permissions, but if these rules are based on attributes then we have a type of attribute-based access control.

Q: I understood there exists a better way in comparison to the RBAC model, but a language is not enough at all. You need a product which combines both. Is this the message you want to send out here?

A: (Babak) Well, the purpose of the workshop is to present the concept of ABAC and how it solves some of the common and well-known issues with RBAC. But you are right that we also need products to support this new approach. Axiomatics has a complete product suite to support xacml policy life cycle management 360. Most vendors of business applications and IAM products also have more or less elaborate support for XACML built-in.

Q: Is there a defined migration path from an established RBAC model to an ABAC model?

A: The OASIS XACML committee has released an XACML Profile for Role Based Access Control (RBAC) which can be used as a basis for migration projects. That said, one naturally needs to be aware of the constraints given by the architecture of legacy systems – “converting” an existing RBAC-based business application to an ABAC-based model may require a considerable effort. In some instances it may be more attractive to implement connectors that can provision attribute-based rules from a Policy Administration Point to application specific rule configurations which in turn may be RBAC based.

Q: How do you manage attribute based access to multiple resource? Traditionally, privilege attributes are bundled into roles and are assigned to users. If you have many attributes that control access to resources, doesn't that increase administrative burden?

A: No, as we said in the presentation it will most likely be much less number of attributes needed to define access permissions than the number of roles. This is because we will define access rules based on the attributes rather than representing different set of permissions in terms of roles.

Q: Sounds like this method will have significant application impact - can you respond to this concern?

A: Yes, we believe that many applications will in the future implement the XACML request-response protocol. Already today, most large vendors of Identity & Access Management products or applications that handle business critical data have some sort of “XACML story”.

Q: Does ABAC related to Claim Based Authentication? Are they like corresponding concepts?

A: (Babak) Yes, one way to see claims is as provisioning of attributes to the access control system, so these are definitely complementary technologies.

A: (Felix) Authentication and authorisation are two different concepts, but of course they are related: authentication tells us who the user is, and then authorisation tells us whether the user is allowed to do something. The concept of Claim-based authentication is based on the fact that a "Claim" will already deliver attributes to an application. What happens then? These attributes could be made available to the authorisation engine.

Q: Are there any good resources and real world examples to get started with ABAC?

A:  (Babak) Well a good place to start with is the XACML TC page. Axiomatics has also a very informative website (www.axiomatics.com) with all introductory information regarding ABAC and XACML.

A: (Felix) We also have recently released a XACML Technology report that is available from our web site.

Q: RBAC seems after implementation quite static in maintenance ABAC seems intensive in maintenance, since attribute values vary over time (daily, hourly etc) would it not make maintenance costs more expensive and more complex?

A: (Babak) Well this is really the other way around. The idea is not to change the time attribute manually but to fetch the data from the right attribute source which is perhaps a clock.

A: (Felix) To add to Babak's point there: ABAC will make use of information that already exists in an enterprise. The initial maintenance cost would be to deliver those attributes to the policy decision engine. And for that, good technology such as virtual directories already exist.