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

[Michael McIntosh <mikemci@xxxxxxxxxx>]

Tony,

For a claim like group membership - can you see a possibility that an 
empty (0 valued) claim would be potentially useful?
Wouldn't a token with an explicit claim that a subject is known to not be 
a member of any groups be treated differently than a token with no group 
membership claim?

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 12/07/2006 07:01:47 PM:

> (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
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev