| Re: [higgins-dev] Question about mapping attributes to claims |
|
I'm not sure why, after many years of people using the X.500/LDAP data model this has never surfaced as a problem. Mike's correct, in that data model, once an attribute of an object no longer contains any values, the attribute itself is not returned with the object -- meaning, there's no such thing as an empty attribute. Note that there is the allowance for an attribute holding an empty value (not a null value, rather a value having zero octets).
I can see the potential utility in the differentiation (lack of an attribute may mean you have no rights to view it, while empty means you have rights and it is indeed empty). Due to a lack of standardization in access control, the LDAP CP could never make this determination without being special-coded for each vendor's server (even then it may be impossible).
There are other attribute data model issues we should get around to discussing as well. For example: In Higgins, is it allowed for two attribute values to be equal? I mean, can I have preferredBreakfast={spam, spam, spam, eggs, spam}? This is not allowed in X.500/LDAP
Jim
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 12/8/06 6:59 AM >>> 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 _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |