[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] remote PDP
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 >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]