Re: [xacml-dev] remote PDP

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

Hi Fernando.

On Fri, 2004-10-08 at 16:47, Fernando Vazquez wrote:
> [...]
>  1) Remote PDP's continue to be a source of contention since, at least for 
> the enterprise, there is no way to ensure that the policies managed by a 
> centralized repository can be evaluated in a consistent way across the 
> enterprise since remote PDP's will/may be maintained and possibly coded by a 
> disperse community.

Right. When you have many PDPs that are managed separately, there's
always the chance that these PDPs are configured differently. In that
case, they may have different notions of who to query for attributes,
different capabilities, etc. As I'm sure you know all too well, this is
a general problem when you're dealing with distributed enterprise
environments. :)

>  2) We are in agreement that there might be specific attributes that an 
> application may have to supply that will be required for a policy 
> evaluation, however, the PDP must have the ability to include additional 
> attributes such as environmental attributes (e.g. time of day, threat level, 
> force condition, etc) from a disperse set of datasources. This aspect is 
> difficult to implement in remote PDP's at the very least.

I think what you're saying here is similar to your first point: it's
hard to be certain that different PDPs will provide the same values for
given attributes, and this is especially true for location-sensitive
things like time. Is that about right? I think the difficulty you
discuss here varies from system to system. For instance, you suggest
that "a disperse set of datasources" could be used. In that case, it's
probably just as hard to use the right source for one PDP as for
multiple PDPs. It's all about how well you can manage your system, and
how coordinated you are with your components (again, I suspect I'm
preaching to the choir <g>).

>  3) A far better approach to remote PDP's,  in our humble opinion, is to 
> have the application be a PEP outright and request a decision from a 
> centralized PDP based on the resource and action attempted (as well as 
> attributes, etc). This approach negates the need to have shared policies and 
> eliminates the need for remote PDP's, thus reducing the code/maintenance 
> enterprise wide.

I think that's pretty much where the discussion on this thread has been
focused. We're all talking about having a single PDP service available
to the applications. I'm not sure, however, that this means you can't
use shared policies. In fact, I think there are still good reasons for
having policies that share common components, if only for easy re-use
and authoring.

One note: when you say "remote PDPs" I think what you mean is "many,
distributed PDPs that can be used" rather than "a single PDP service
that is globally available." The PDP is still a "remote" service, it's
just the only one available.

>  4) Using a centralized PDP, the enterprise now has the ability to use an 
> open standard protocol such as SAML, so that as the enterprise grows, it is 
> not "stuck" with one vendor. SAML gives you the ability to request an 
> Authorization Decision based on resource/action, identified principal, as
>  well as any additional attributes you may wish to present to the service.

I don't see how using a single PDP makes it easier to use SAML. I could
have multiple PDPs in my environment (to do load ballancing, to support
specific features, etc) and still talk to all of them using SAML. for
that matter, I could have a single PDP that internally makes some
decisions based on other PDPs, and again they could communicate using
SAML. Am I missing something here?

>  5) With a centralized PDP, disperse datasources can now be normalized and 
> introduced into the decisioning process in addition to any attributes from 
> the requesting PEP.

Sure. I don't think this is changed by having one or many services, but
it certainly makes it easier to manage things. THanks for your input on
all of this!


seth