Re: [higgins-dev] Question about mapping attributes to claims

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

(b) as claims are only a guide line

-----------------
Yet another BlackBerry 8700c User.


----- Original Message -----
From: Michael McIntosh
Sent: 12/07/2006 04:54 PM
To: <higgins-dev@xxxxxxxxxxx>
Subject: [higgins-dev] Question about mapping attributes to claims



I wanted to bring to the mailing list a debate/discussion we've recently
started over on the #higgins IRC channel in order to get a broader opinion
on how to deal with this situation "correctly". Some questions that we've
been discussing include:

What should the STS do when an RST is received which requires a claim in
the returned token, but the IDigitalSubject.getAttribute(uriClaim) returns
null?
a) Return a token with an empty claim?
b) Return a token without the claim?
c) Generate a SOAP Fault?

According to the Draft CardSpace Guide: "A relying party can ask for one
or more claims in the token issued by an identity provider. If any
required claims are missing in the token submitted, it can accept or
reject that token at its own discretion."

The specific claim type that caused this debate was "group membership".
The group membership attribute is multi-valued and can therefore result in
a claim that looks like:
<saml:Attribute
  AttributeName="groupmembership"

AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims";>
  <saml:AttributeValue>user</saml:AttributeValue>
  <saml:AttributeValue>admin</saml:AttributeValue>
</saml:Attribute>

When IDigitalSubject.getAttribute(uriClaim) returns null the current
Higgins STS implementation does "a" resulting in a claim that looks like:
<saml:Attribute
  AttributeName="groupmembership"

AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims";>
</saml:Attribute>

In order to accomplish this the current implementation creates the
Attribute element, then calls IAttribute.getValues and iterates thru the
returned IPropertyValue objects, adding an AttributeValue element for
each.

There are essentially two code paths that could result in an empty claim,
a) IDigitalSubject.getAttribute(uriClaim) returns null, and b) the
iterator returned from IAttribute.getValues provides no values.

Conceptually there is a subtle difference between a claim that is present,
but contains no values, and one that is absent. In the group membership
example, a claim that is present but has no values makes the explicit
statement that the subject is not a member of any group, whereas a missing
group membership claim says nothing about whether the subject belongs to
any group.

Presumably the distinction should be made between a missing attribute and
one with no values. One way to differential between the two cases would be
for IDigitalSubject.getAttribute(uriClaim) returns null to result in no
claim, and IAttribute.getValues provides no values to result in an empty
claim.

The problem is that in the case of the LDAP, when the last value for a
multi-valued attribute is removed, the attribute itself is removed.
Therefore, when using the LDAP CP, it is not currently possible to
differentiate between when a claim should be present but empty, or not
present (IDigitalSubject.getAttribute(uriClaim) ALWAYS returns null - when
there are no values or when the attribute is not present).

I am trying to think of ways we can work around this. One way would be for
some sort of metadata to be associated with attributes to help context
providers do the right thing.

Would anyone else like to join the discussion?

Thanks,
Mike
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev