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

[Ludwig Seitz <ludwig@axiomatics.com>]

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? 

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
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.


> --- 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