RE: [xacml] XACML AzApi as part of F2F agenda

[Harold Lockhart <hal.lockhart@oracle.com>]

Raj,

 

As promised I will comment on the technical merits of defining a new Authorizaiton API and standardizing it in the XACML TC.

 

First of all, let's dispose of the idea that OASIS TCs can't define Java specifications. There are ample precedents, for example the SDO TC (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdo) which has an IBM employee as one of the chairs.

 

I think Anil's formulation is correct. The XACML Core spec defines an abstract request interface in XML, but clearly states that it is not required that implementations use it. Instead implementations have defined language bindings of the XACML API appropriate for the language the PDP is written in. We think it is time to settle on a standard one. It is our intention to define a number of them for different languages. We started with Java for obvious reasons, but we see a need for APIs in C#, perhaps C or C++, as well as scripting languages like Python.

 

In thinking about an API for Java, JSR 115 was the obvious candidate. In fact, it is possible to use the Java permissions model with or without a JSR 115 contract to invoke an XACML PDP. There are products which do this. The problem is that this makes it difficult or impossible to take advantage of many of the features which motivate the use of XACML in the first place. For example,

 

o There is no standard way to provide the range of inputs that XACML can reference in policies.

o There is no way to deal with the outputs, such as Obligations and Advice which XACML can return on both permit or deny. This is complicated by the

     fact that in Java permit and deny take distinct code paths.

o The Java model requires that new Permission object classes be defined and compiled in order to reference distinct Resource types. XACML allows policies referencing new resource types to be created administratively at any time.

 

After extensive study of the Java permissions model and JSR 115 considering these issues and others, we concluded that is was not practical to try to continue to extend it. Also the design process would be complex and it would not be compatible with existing systems anyway.

 

However there are things about JSR 115 we like a lot. For example, the notion that applications should not participate in access control any more than absolutely necessary. The infrastructure (container, libraries, tooling) should do all the routine work. However we don't want to limit this to J2EE containers. It should also be true all Java environments, such as Spring, JSF and pojo. I have a lot of ideas about how this can be done using the proposed API, but I will not discuss them here.

 

We also see a lot of short term benefits to using this API. For example, one of the early projects in open source will be to build a client stub which invokes a remote PDP using the SAML/XACML ( or WS-Trust/XACML) network protocol. This should make it a lot easier to build a XACML client and it will make the choice between a local (embedded) PDP or a remote PDP transparent to callers of the API.

 

As we developed the API we realized a few other things. Just like the network decision request, the API can be used to invoke a non-XACML PDP of any sort. Even a Java Policy object based on permissions could be called by the API, but of course it might not be able to make use of all of the inputs provided. Conversely we believe it will be possible to emulate Java checkpermissions using the new API. These alternatives enable a whole range of possibilities for migration. Instead of having to change out apps and policy infrastructure in one big bang, things can be done in stages. Applications can be converted to use the API while the administrative tools and procedures remain the same until a later date. Alternatively, a new authorization infrastructure can be put in place while applications continue to use their current API.

 

We are far from alone in advocating a new Authorization API. It is what we are hearing from our customers and the industry in general. At a Concordia workshop on Authorization in 2008 several large end user organizations identified it as a key need. The Burton Group and Kuppinger Cole has both been advocating for it for some time. Most recently at the Privilege Management Workshop held at NIST last September, one of the recommendations for action was an Authorization API.

 

I look forward to continued discussions on this matter.

 

Hal

-----Original Message-----
From: Nataraj Nagaratnam [mailto:natarajn@us.ibm.com]
Sent: Monday, November 30, 2009 11:28 PM
To: Prateek Mishra
Cc: XACML TC
Subject: Re: [xacml] XACML AzApi as part of F2F agenda

Wrt #3 below around Java interfaces --

I am not sure if XACML TC is the right forum to define Java APIs, especially when there are Java standard APIs already available and in use. JSR 115/JACC is sufficient in many cases - though it is written from container viewpoint, it is equally applicable to any type of enforcement points (even if it is apps). If there gaps that should be addressed in JACC, I think we should work that in. Those APIs are applicable to Java developers who can use it without any knowledge of XACML, or other means that a container may even provide. So it provides that level of abstraction as well.

Regards,
Nataraj Nagaratnam




Prateek Mishra ---30/11/2009 22:38:08---I would like to request discussion of the XACML AzApi during the F2F, as we continue to work to adv

From:	Prateek Mishra <prateek.mishra@oracle.com>
To:	XACML TC <xacml@lists.oasis-open.org>
Date:	30/11/2009 22:38
Subject:	[xacml] XACML AzApi as part of F2F agenda

---

I would like to request discussion of the XACML AzApi during the F2F, as
we continue to work to advance this towards standard status.

The API submission we made this past summer, has a number of features
would benefit from the TCs review -

1) Use of generics and a highly factored design to allow for new
categories and types of attributes. Is this adequate
to model the new materials in XACML 3.0 and other XACML use-cases?

2) A concept called "what is allowed" - which supports a limited but
extremely valuable form of scoped query against
access rules. One question is how this can be modeled or implemented in
the XACML 2.0/3.0 context

3) Based on experience with the open source and our internal review of
the API, we are planning to submit some additional
interfaces to the XACML TC within the next couple of weeks. The main
purpose of these interfaces is to allow Java developers with little
knowledge of XACML
to utilize the API. We would like to be able to describe these
interfaces in some detail to the TC, together with
the rationale for their introduction.

I would request the Chairs to allocate an hour and half for these
discussions, which would be led by Rich Levinson (he is out today - but
I thought
it important to get this message out to the chairs and TC).

Thanks,

- prateek


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php