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