Subject: Re: [xacml-comment] who should use XACML?
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 <firstname.lastname@example.org> wrote: > > > From: kurt steele <email@example.com> > > Subject: [xacml-comment] who should use XACML? > > To: firstname.lastname@example.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