RE: [xacml-dev] remote PDP

[Seth Proctor <Seth.Proctor@Sun.COM>]

On Fri, 2004-10-08 at 09:48, Kuketayev, Argyn wrote:
> > 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.

Ok. Is it possible that the application could export those attributes,
or make them available through some kind of query mechanism? Just trying
to understand the constraints..

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

Right, but even if you embed the PDP in your application, you've got the
same case. At some point, the PDP will need to retrieve these
app-specific attributes. It's certainly easier to do so if the PDP is
part of your application, but if it can be done by an embedded PDP,
can't that be extended to an external service?

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

I don't think it will help in this case, though maybe it will make it
easier to express (for instance) some way to talk with the app.

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

Oh, ok. Then no, you can't share these with any PDPs. But by retrieving
only the specific attributes you need from an app, you're telling that
application some information about what's in those "secret" policies.
The only way to keep the policy completely secret is to have the app
send all possibly useful attributes up front. Unless you're not really
worried about leaking a little detail (which is true for many people).

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

I don't think I understand what this means. Doesn't this imply that the
attributes are in distributed locations, and not locked away in an
application?

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

Yes. Indeed. But, it _could_ get you some of the separation you're
looking for. Given that you don't want to expose any policy, however, I
think it's a problem.

I think I have a fundimental question about this. Does it really make
sense to have a system where an application can't see the policies used
to make decisions, but the attributes used in the decision-making are
supplied by the application? I mean, it seems to me (without knowing
more about your system) like there's something strange about that trust
model. Maybe it's clear when you can see all the pieces involved?


seth