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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

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

Subject: Re: [xacml-dev] remote PDP

On Oct 7, 2004, at 10:22 PM, argyn@cox.net wrote:
> I was thinking about remote PDPs. I thought that maybe there could be 
> a authorization service in the enterprise. You go there and ask 
> permission to do something. So, every app will have PEP, then PEP 
> talks to a central PDP, which in turn evaluates the request and makes 
> a decision.

Sounds good to me. In fact, I know of several people who are doing just 
that. You could even take it a step further and have a distributed PDP 
model, but I think we've covered that in  previous email thread. :)

> The problem is that is there's not enough information in the Request, 
> PDP will need to find missing attributes. These attributes are local 
> to the application. What to do?

I'm not sure I understand the problem. Are you saying that you need to 
make access decisions based on attributes known only to a specific 
application? In that case, it will need to pass those values in the 
Request, or will need to provide a mechanism for the PDP to query the 
application. Even if your PDP is in the app, that's true. Either way, I 
don't know why the Request doesn't provide enough functionality. What 
about using the SAML profile? Does that help you at all?

> One solution is to centrally store policies in the registry, but 
> evaluate them locally, i.e. PDP is local, not remote. I don't like 
> this, because maybe it's not a good idea to have all policies open for 
> retrieval. Maybe certain policies are confidential or secretm but they 
> exist.

That's certainly one option. In fact, you can take it a step further 
and protect the policies so they're only available to the PDPs that are 
supposed to use them.

Another option, unless I don't understand your app, is to make the 
attributes you need available to the rest of the system. A third option 
is to provide a PDP service to do all the processing that involves 
generally available attributes, and then include an Obligation in the 
Response that the app needs to check local policies that fold in local 
attributes. This could get quite complicated, but it might solve your 

Does any of this help? Or did I just confuse the issue further? :)


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