Re: [xacml] Bindings and frameworks for PEP to PDP access

[Erik Rissanen <erik@axiomatics.com>]

Prateek,

See one comment inline.

Regards,
Erik

Prateek Mishra wrote:
> This is an issue that was discussed at the f2f and was also featured 
> as case 2.1.1 of the interop.
>
> Its been some time since we discussed this issue, so I will first 
> point to the relevant text from the f2f.
>
> http://lists.oasis-open.org/archives/xacml/200703/msg00071.html
>
> [quote]
> C: closely coupled PEP/PDP
> ...
> D: PEP/PDP issues: how do you know what inputs the policies refer to?
> ...
> [\quote]
>
> The starting point of the analysis here is to understand three 
> distinct roles that are involved: (a) application developer
> (b) deployment manager (c) policy manager.
>
> The application developer inserts call-outs to the XACML engine and 
> processes results as returned from the PDP.
> This follows the model in Section 2.1.1. of the interop document.
>
> At the F2F it was suggested that JSR #115 satisfies these requirements 
> but a quick analysis of JSR #115 shows that while
> it allows for a policy engine to be connected to a java container but 
> it doesn't expose key XACML functionality.
>
> Some of the gaps include:
> (i) ability to pass arbitrary environment, resource and action attributes
> (ii) ability to process returned values from the PDP - especially 
> obligations.
>
> One additional constraint that should be noted here is that 
> application developers may not be aware of all the information
> required for the authorization call-out. The reason for this that 
> policy's are created by policy managers, and this information
> may not be available when the application is being developed.

I think this is a crucial point in this analysis, and I am not sure this 
assumption is right. I have always thought it as that applications are 
developed before policies are written. The application developer exposes 
attributes of resources and actions in the application in the request 
context and documents those attributes for policy writers and 
application integrators. Application integrators integrate the 
application with the application platform and authentication systems of 
the IT infrastructure. Together this results in a defined and documented 
request context for any attempted access to the application. The 
resource and action parts come mainly from the application and the 
subject and environment parts come mainly from the 
integration/authentication system. It is also likely that there are 
attributes about resources that are provided by the integration, such as 
how/where applications have been deployed.

All this provides the vocabulary for policy writers.

I have a gut feeling that trying to make applications provide the 
attributes which policy writers define is the wrong way around. But this 
surely needs more discussion.

All this leads to the greater issue that XACML integration today is in a 
state that so many of these steps requires manual tweaking, coding,  
design and integration so a plug and play deployment of XACML is not 
possible.

Prateek, Rich, am I right in my feeling that it is how to reduce the 
integration costs that you are looking for?

To get to a plug and play XACML world, the following needs to happen:

- Bit-by-bit interoperable API needs to be specified between the PEP and 
PDP and when applicable between an XACML aware application and the 
application hosting environment. In no other way would it be possible to 
just take a product out of the box and plug it into an XACML system and 
have it "just work" and without the need to code a custom PEP. An 
language neutral API would be a first step, but it in itself would not 
make products interoperable. These bit-by-bit APIs can be 
cross-platform, such as something SOAP-based, or platform specific, like 
a C och Java API.

BTW, I agree with Hal when he said in another email, there is already a 
language independent API in the form of the request/response context model.

I certainly think these APIs should to be specified. Though I am not 
sure in which forum that should be done. Perhaps a SOAP profile would be 
something for this TC?

- XACML needs to be adopted by application vendors. Otherwise end users 
need to do the integration coding themselves.

There is a lot that can be done by all of us to make this happen. For 
one, by providing a good spec and useful profiles.

- Best practices and common vocabularies need to be developed. Best 
practice is important since it decreases the design and analysis costs 
of XACML deployments. Common vocabularies would be good since this makes 
the policies more uniform and simplifies learning. Also, a common 
vocabulary specifies what kind of attributes applications and hosting 
environments need to provide in order to make it possible for policy 
writers to write usable policies without the need for further 
integration work. (But I still think that it is the applications which 
need to drive the vocabulary, rather than the policy writers.)

- We need a world of XACML skilled people out there. I suppose that this 
is something that has to grow over time. (Though, I have thought about 
that there needs to be a good XACML book out there. One idea I have had 
is that if members of this TC are interested, we could set up an "open 
source" book which we could write jointly.)

In summary, there is a lot of work of this sort which should be done, 
but has not been on the agenda of this TC.

I am not sure we need a "deployment manager" in this architecture 
though. But perhaps I don't quite understand what it you intend with it. 
To me a big point of XACML policies are to do what you intend the 
"deployement manager" to do. It seems to me that what you are planning 
to do is something like this:

1. Application provides application specific resource attributes
2. The deployment manager translates these to generic resource 
attributes (presumably using a configuration)
3. The XACML policy connects the generic attributes to users, so access 
permissions are specified.

It seems to me that step 2 is really just set of policies (the 
deployment manager configuration) of the type which XACML was intended 
to do. I would rather do it like this:

1. Application provides application specific resource attributes
2. The XACML policy connects the specific attributes to users

I don't see the need to split up this process in three steps.


> The deployment manager interacts with the PDP and PEP (in this case 
> the application) to create the appropriate linkages.
> At this stage adequate information may be available to complete the 
> linkage between the two. Specifically, the deployment
> manager requires:
>
> (i) what requests are being made from PEP and what attributes are 
> currently being transferred
> (ii) Which policies at the PDP are relevant to the PEP requests, and 
> what attributes should be included in the requests originating from 
> the PEP
>
> So some form of reconciliation is needed at this point, especially one 
> that does NOT involve re-coding/re-building the PEP but
> rather extending it so that all required attributes become available. 
> There may also need to be a certain amount of coordination between
> the deployment manager and the policy administrator.
>
> SUMMARIZING: I have described a use-case that we have found quite 
> significant and which was one of the two scenarios
> demonstrated at the interop. I would be interested in feedback on the 
> use-cases and any comments on standards and frameworks available to 
> solve these cases.
>