I was in a conversation recently in regards to Extensible Access Control Mark-up Language (XACML) and Attribute Based Access Control’s (ABAC) role in Role Based Access Control (RBAC), Risk Adaptable Based Access Control (RAdAC) and Security Access Mark-up Language (SAML). The question surrounded whether ABAC can or should replace the other Access Control models and/or the open standard languages.
The short answer is no, and well, kind of yes.
Let me expound upon my vagary if you will.
Role Based Access Control (RBAC)
To start with Role Based Access Control we should start with what works. The RBAC tools on the market have an advantage of tying the Identity to a Role that can be used for high level access rights that don’t need to change all that often. Aveksa, Sailpoint, Oracle Identity Analytics, etc. pride themselves on the ability to role mine your application stack and set the role to the associated entitlements. This allows the organization to fulfill most security audits and allows for easy re-certification of said roles quarterly, bi-annually, annually or whatever the requirement states. The failing, if you were to call it such, is that to change the entitlements typically becomes very intricate as the roles the organization has explodes. This forces the governance model to keep roles shallow at best.
Where ABAC shines is by allowing a deeper, more fine-grained authorization model by using policy combined with attribute values in order to allow a level of authorization commensurate with the values presented. To do this, ABAC essentially strips out the Identity and relies solely on those attribute values to make a decision. This can extend an RBAC separation of duty (SOD) policy greatly and alleviate a lot of risk while making SOD decisions in real time.
So while “yes”, you can replace your RBAC vendor’s toolset with an ABAC solution the real question is why would you? The tools work very well together and allow for a greater sum of their parts as opposed to their own private silos. If I had my druthers within my customer sites I would have an Identity Provisioning system (to automate Identity creation and management) that ties into my RBAC vendor tool (to grant high-level entitlements and set automated recertification policy) that leverages my ABAC tool to authorize application access at a fine grained level (with perhaps an SSO tool to manage Authentication, which XACML/ABAC does not).
Risk Adaptive Based Access Control (RAdAC)
Ah RAdAC, the grand unknown! RAdAC essentially is the process of taking information we know about the user, whether that is attributes, meta-data or some other method of taking a plethora (hopefully) of information, running said data into a risk engine algorithm and spitting out data to make a much more informed decision. This is particularly important on highly classified systems. In this case ABAC is a natural fit in conjunction with a RAdAC tool in which the RAdAC tool becomes the defacto decision engine with ABAC the data provider (potentially as this can be some data aggregator like a virtual directory) and the authorization enforcer. ABAC vendors can enforce based on classifications (such as meta-tagging your data as “Secret”, “Top Secret” and “Confidential”) and can run policy based on location or various credentials much in the same way a RAdAC system so you can replace but again the why comes into play here. RAdAC vendor tools typically have a better risk engine to help you define the risk algorithms instead of having to determine the set, write the policy and hope it doesn’t change. Once again ABAC plays nicely with the additional Access Control method.
Secure Access Mark-up Language (SAML)
This time let’s dissect Extensible Access Control Mark-up Language (XACML ) vs. SAML. This really isn’t a “Vs.” situation. SAML tends to be used in the Authentication side of the house with limits on how deep it can go into Authorization. Try locking down individual attribute lines in a web based widget framework with SAML. It isn’t going to happen, but that is OK. The point to XACML when used in conjunction with SAML is that it can extend the security framework by providing a more robust Authorization framework (i.e. fine-grained). So don’t throw away your Web SSO vendor integration yet. Can you? Well, once again the answer is “yes”, but why would you? Keep your infrastructure and expand. ABAC should not be used as a rip and replace technology, it is a flexible architecture that can “add to” instead of “take away”.
Long story short, ABAC is the nice kid on the playground that plays by himself until someone walks up and asks him to play. Then he plays well with others.