Re: [xacml-dev] remote PDP

["Fernando Vazquez" <fernando.vazquez@jerichosystems.com>]

 Hey folks, I am new to this thread, however, I have been monitoring it for 
the last few days.  I will start off by saying that we (the company I work 
with) have been trying to tackle the same issues that you all have been 
discussing for the last few days. Here is what we have come up with:

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

 Please take a look at our product description at 
http://www.jerichosystems.com/Software_Tools/Security/index.jsp. This is not 
meant to be a shameless plug for the company I work for, however, we have 
been dealing with the government as well as commercial entities quite a bit 
and can do just about everything discussed in the last few days. We would 
like to contribute any knowledge that we may have gained to the open 
community as well as hopefully learn, participate, and influence. I won't 
mention our product again, unless requested in the thread.

 Fernando Vazquez
Senior Development Engineer



>> -----Original Message-----
>> From: Seth Proctor [mailto:Seth.Proctor@Sun.COM]
>> Sent: Friday, October 08, 2004 12:15 PM
>> To: Kuketayev, Argyn
>> Cc: xacml-dev@lists.oasis-open.org
>> Subject: RE: [xacml-dev] remote PDP
>>
>>
>> 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
>>
>