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 9, 2004, at 2:26 PM, Argyn wrote:
> On Fri, 08 Oct 2004 14:13:57 -0400, Seth Proctor 
> <Seth.Proctor@Sun.COM> wrote:
>> Well, my comments are based on the original use case. I asked about
>> securing the policies but making them available to PDPs embedded in 
>> the
>> applications, and was told that the applications (ie, the PEPs) are 
>> not
>> allowed to see the policies. They are kept completely secret, 
>> available
>> only to the author and the evaluating PDP.
> Well, I don't have a requirement like that in my current system :)

Ok, but when I asked about sharing the policies only with embedded 
PDPs, and keeping them secret from other parties, you said that wasn't 
acceptable. You said your system has secret policies that no 
application, except a single, central PDP, is allowed to access. If 
that's not actually what you meant, or if that's not in fact what your 
system looks like, maybe you could post details? I'm just trying to go 
on what you originally posted...

> I started to think about remote PDP. Sort of a service for enterprise 
> apps, so they don't maintain their own PDPs. They'd publish their 
> policies to a central PDP. I thought that there could be global 
> policies combined with local application policies. I thought some of 
> these global policies could be "secret". It's not that local PEPs are 
> "untrustworthy", strickly speaking.

That makes sense to me. And yes, you can have global policies that are 
secret. From your original description, however, you weren't willing to 
share some policies with any parties except the global PDP. This is 
where I was defining a trust model. The PEPs are inherently untrusted, 
to some degree, if you're unwilling to share some policies with them.

> The analogy is that you are "trustworthy" as a user of your PC. 
> However, it dowesn't mean that you know everyone in the company who 
> can get into your hard drive. There are all sorts of folks who can do 
> it. You don't necessarily know who are they, system admin guys.

Ah. That's very different than "secret" policies. Now you're getting at 
a model where I don't know about all cases simply because I don't know, 
not because we're trying to hide the cases. This also makes a lot of 
sense. There are many models where this happens.

> Anyway, "secret" policies may be not worth to think about at this 
> moment. It seems that it's not possible to build central PDP service 
> without much effort. Maybe we only can have centralized policy 
> registry service + PDP code library. Applications would download PDP 
> code, and install in their classpath. This PDP will retrieve all 
> required global policies + load local application specifi policies. 
> It's the simplest I can think of at this moment.

I think it's perfectly easy to build a centralized PDP service. The 
requirement you expressed that makes this complicated, however, is that 
there are attributes in the PEP/application that somehow can't be 
easily shared with the PDP. That makes things hard. If you're willing 
to pass those attributes in a Request, have them available through some 
interface, or do a multi-phased exchange, then you've got no problems.


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