OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Very useful dialogue, thanks. Our media apps do a lot of asset sharing across geographic territories, so an interop solution is attractive.  
I need to: 
1) start with an intake of subject attributes I can reasonably expect to acquire on an inbound non-authenticated HTTP request.  
2) articulate more linkages supporting the use of XACML in both the CMS and public webserver scenarios.  One might be that the CMS itself holds metadata on an asset that winds up being utilized in a policy.
3) go over these responses again, they were pretty dense.

--- On Wed, 9/24/08, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

From: Oleg Gryb <oleg_gryb@yahoo.com>
Subject: Re: [xacml-comment] who should use XACML?
To: xacml-comment@lists.oasis-open.org, arcticranger3@yahoo.com, "Ludwig Seitz" <ludwig@axiomatics.com>
Date: Wednesday, September 24, 2008, 2:01 PM

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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]