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
