[sunxacml-discuss] Re: [xacml-dev] XACML X.509 support

[Seth P. <Set...@Su...>]

Hello Mine.

On Feb 22, 2005, at 2:22 PM, Mine Altunay wrote:
> How does a PDP verifies the validity/legitimacy of claimed attributes 
> in a
> given request. For example, a subject attribute may claim that the 
> user is
> a member of a developer group. Then, PDP would evaluate this 
> information
> and decides the appropriate access decision for the "developers". 
> However,
> how does the PDP verify that the said subject does indeed a member of 
> the
> claimed group? What I see from PDP and request examples is that a 
> request
> does not carry such proofs such as Attribute credentials or identity
> credentials.

The short answer is that this generally isn't the responsibility of the 
PDP. The PDP is supposed to answer questions like "for the given set of 
attributes, what is the right decision?". The PEP, which queries the 
PDP and ultimately enforces access, is responsible for the information 
it supplies to the PDP. Well, that and the context handler, which makes 
the answer a little longer.

Tehcnically, in the XACML model, the attributes used by the PDP don't 
come from the Request, but from the Context Handler, an abstract entity 
responsible for providing all attribute values. A simple Context 
Handler may only know about values from a Request, or may find 
attributes elsewhere. It may trust the validity of these attributes, or 
it may do its own validation. For instance, in my implementation 
(SunXACML), there is a way to add code that can do any kind of 
validation you like, but the assumption is that by default the values 
provided by the PEP are valid. If you think about it, this makes some 
sense, since...

> However,lack of such a support makes the authz process very naive,
> vulnerable against malicious users.

...Remember that the PDP doesn't actually allow access to anything. All 
it does is tell you what the right decision should be. Depending on the 
secrecy of your policies, you might have a general PDP service that 
anyone can query, providing any attributes they want (think about 
testing environments, where this can be very useful). The decision 
rendered by the PDP doesn't usually get you anything more than a 
statement that a given set of attributes leads to the given decision.

It's the PEP that actually enforces access. You need to convince it 
that the attributes you're asserting are valid. In most scenarios, the 
PEP is some application-specific entity that knows how to handle this 
validation. So, you're not really in any danger by having a PDP that 
doesn't validate the attributes. Like I said above, however, you can 
always add this behavior if you really need it. You cite at least one 
god reason below, however, for why you wouldn't want to do this.

> Additionally, I am working with an identity-based authz system that 
> relies
> on x.509 credentials. Therefore, for my PDP it is important not only to
> get an access decision, but also to verify that the subject does indeed
> have a valid certificate (or ACs or whatever the policy calls). Right 
> now,
> I am using the xacml X500NameAttribute, however, it does not really 
> prove
> that this subject indeed has an issued certificate.(I am naively 
> passing
> the DN and hoping that the user is honest with it)

Based on what I've described, think about this and let us know what you 
need. If you validate the certificate before making the request, then 
this isn't a problem. If you really need to validate the certificate 
during policy processing there are ways to do it, but it will be 
implementaion-specific, so you'll want to take this to the appropriate 
mailing list. If you need the contents of the certificate, but aren't 
worried about the PDP doing validation, then that may lead to a 
different solution.

> Also, do you see this verification problem as out of the xacml scope 
> or is
> there already support in existing xacml framework that perhaps I am
> missing

I think generally it's out of scope. There are lots of elements in a 
secure environment, and XACML tries to provide just one core component 
(making authorization decisions). In theory, this makes it easier to 
work with any arbitrary kind of attribute, certificate, or other token 
without re-implementing validation and revocation support in the PDP. 
It also makes sense when you think about another issue you raise...

> PS: I also thought about external means to send the certificate after 
> the
> authz process but it is costly and redundant.

The whole idea here is to split up labor and not repeat costly actions 
like validation. So, you're right, what you describe would be 
expensive. It would also be expensive to have your app (PEP) verify an 
attribute and then have the PDP do the same, especially if you're 
working in a distributed environment with more than one PDP. So, 
another reason that XACML doesn't try to handle validation is because 
this is something that other components already do and do well, and it 
would be extra work to do it again.

Does all this make sesne? Does it help? Please let me/us know if you've 
got more questions!


seth