Re: [xacml-comment] who should use XACML?

[Oleg Gryb <oleg_gryb@yahoo.com>]

--- On Wed, 9/24/08, Ludwig Seitz <ludwig@axiomatics.com> wrote:

> From: Ludwig Seitz <ludwig@axiomatics.com>
> Subject: Re: [xacml-comment] who should use XACML?
> To: xacml-comment@lists.oasis-open.org, arcticranger3@yahoo.com
> Date: Wednesday, September 24, 2008, 7:06 AM
> On Tue, 2008-09-23 at 12:20 -0700, Oleg Gryb wrote:
> ...
> > 
> > If you can easily derive all your authorization
> decisions from a user ID only then I would not recommend
> using XACML - use a traditional RBAC model instead, 
> > because XACML will definitely add complexity and
> increase the cost of your authz solution.
> 
> I have to disagree here. How will XACML increase the cost
> or the
> complexity as compared to an RBAC model? 

RBAC is conceptually much simpler than XACML. I'm not sure if we need to argue about that. Authorization scenario in RBAC usually looks like this: 1. Get a list of roles for a user.
2. Make an authz decision based on permissions assigned to these roles using repositories like LDAP, DB, or custom built adapters.

In XACML we have policies and PDP-PIP concepts, which are more complicated in nature and require more efforts to understand and utilize them. Usually attribute resolution mechanism should be built by an implementer to make a XACML-based solution efficient and easy to use for authz service consumers.

The both commercial implementations that I worked with have bugs and are not very stable. It's not a surprise considering the age of the implementations ans the standard itself. 

RBAC model is usually embedded to the major application servers and platforms (e.g. abstract roles in WebLogic and other J2EE containers or role provider in .NET)

In regards additional cost: I've evaluated 2 vendors and upfront cost just for license fees was between $300K and $500K for our DEV/QA/Prod environments that are not that large - we had only one web application to support.

> 
> You are comparing two different things here, RBAC is a
> theoretical model
> that may be implemented in many different ways. XACML is a
> standard that

Both commercial implementations that I've evaluated claimed that they were XACML 2.0 compliant, but they were absolutely incompatible. While  XACML is a real specification and standard, it still has important features that could be implementation-specific (e.g.  attribute resolution, policy/policy sets reference resolution)

> defines how to write and interpret policies and requests.
> You can use
> XACML to implement RBAC for example.
> 
> I guess what you are referring to, when talking about
> adding complexity
> is that you get some overhead when using XACML as compared
> to a custom
> made (proprietary) solution that only implements the
> functions you need
> for your application.

It's true that RBAC is rather a concept than specification, but yes, implementations are usually available "out of the box", do not reacquire additional cost and substantial learning efforts.

Having said all that, I want to remind that there are great advantages of XACML as well. I think that the most important one is a formal policy definition language and PDP engine specification that allow to externalize authorization logic. From what I've heard and learned while was working for big enterprises, this advantage alone could easily justify existence of XACML and all additional complexity/cost that comes with it  because externalizing of authz logic is a dream of any CIO/CISO and security auditors. 

Yes, I agree that RBAC model can be implemented easily with XACML-based solution while opposite would be problematic. It means that XACML is more comprehensive and more general solution than RBAC.

I want to return to my initial point: it's important to understand authz scenarios well before making a final decision about authorization model. 

PS. All of that is my opinion only that is backed by my practical experience of building authz solutions using both RBAC and XACML models. I'm not a member of TC and do not represent TC's point of view in any way.

> 
> 
> > --- On Mon, 9/22/08, kurt steele
> <arcticranger3@yahoo.com> wrote:
> > 
> > > From: kurt steele <arcticranger3@yahoo.com>
> > > Subject: [xacml-comment] who should use XACML?
> > > To: xacml-comment@lists.oasis-open.org
> > > Date: Monday, September 22, 2008, 12:33 PM
> > > I am doing some research for a media firm in NYC
> and I have
> > > a simple question.
> > >  
> > > They need a solution for:
> > >  
> > > 1. authorization of users of our CMSXACML does
> not restrict this vocabulary, it just gives a format how to
> write stuff down.
> > > 2. general users of our public entertainment
> websites. 
> > > There are 300 or so of these and the rights
> policies can be
> > > complex.  The policies often specify restrictions
> based
> > > on geographic location of the subject and the
> resource.
> > >  
> > > Is XACML targeted at both of these scenarios?  Or
> > > is it only meant for inter-agency or
> inter-company rights
> > > interaction?  
> 
> XACML is not designed for a specific application (or a
> specific access
> control model). XACML gives you a sort of toolkit of
> datatypes and
> functions that you can use to build the policies required
> for your
> application. If your application is easy, the resulting
> policies will be
> (relatively) easy and you will not need a lot of the XACML
> functions.
> 
> > >  
> > > I find it hard to equate internal CMS access with
> public
> > > website access, they seem like very different
> animals to
> > > me.  So any views on that would help also.
> 
> Yes they will probably have a very different vocabulary to
> describe
> (access control) requests (e.g. URLs vs document-ids), but
> this is not a
> problem with respect to XACML. In XACML you describe
> policies and
> requests using a vocabulary of attributes defined by the
> persons that do
> the integration of the access control software with the
> application.
> 
> This probably means that you will need two different
> integrations,
> one for CMS and one for website access, but the underlying 
> access control engine, policy management tools and policy
> database can
> be the same, if you use a standard based approach like
> XACML.
> 
> If you are familiar with the P*P vocabulary (e.g. from
> chapter 3 of the
> XACML 2.0 standard or from RFC2904) then you will need
> separate PEPs
> (and probably PIPs) for CMS and website access, but you
> will be able to
> use the same PDP and PRP and PAP.
> 
> /Ludwig Seitz
> 
> 
> -- 
> This publicly archived list offers a means to provide input
> to the
> OASIS eXtensible Access Control Markup Language (XACML) TC.
> 
> In order to verify user consent to the Feedback License
> terms and
> to minimize spam in the list archive, subscription is
> required
> before posting.
> 
> Subscribe: xacml-comment-subscribe@lists.oasis-open.org
> Unsubscribe: xacml-comment-unsubscribe@lists.oasis-open.org
> List help: xacml-comment-help@lists.oasis-open.org
> List archive:
> http://lists.oasis-open.org/archives/xacml-comment/
> Feedback License:
> http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines:
> http://www.oasis-open.org/maillists/guidelines.php
> Committee:
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml