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

> -----Original Message-----
> From: Seth.Proctor@Sun.COM [mailto:Seth.Proctor@Sun.COM] 
> Sent: Friday, October 08, 2004 12:03 AM
> To: argyn@cox.net
> Cc: xacml-dev@lists.oasis-open.org
> Subject: Re: [xacml-dev] remote PDP

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

No, no. the whole idea is to have ONE pdp if possible, not distributed.
Mainframe :)

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

Yes. Some attributes may be specific to an application. Some attrs could
be centralized, such as most Subject attributes are in LDAP. However,
most Resource attributes are stored locally in the 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?

That's what I'm thinking about: how to get these attributes into remote
PDP. I don't know in advance what's required for evaluation of policies.
I can guess and supply many attributes in Request, but if something's
missing it should be retrieved somehow.

I'm not sure about SAML profile's usefullness in this case. Maybe I've
to look at it now.

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

Nope, that's not good. The idea is that there could be "secret"
policies. Nobody should see them, but it doesn't mean that they are not
evaluated. They are in place, it's just you shouldn't know them.

> Another option, unless I don't understand your app, is to make the 
> attributes you need available to the rest of the system. 

Impossible. Resources are in hundreds of databases.

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

This sounds complicated to me.

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

This helps. I didn't think of SAML as an option until now.


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