| Re: [higgins-dev] Question about mapping attributes to claims |
|
As I mentioned before, it's likely that some CPs are unable to distinguish between combinations of 2, 3, and 4. I suspect 4 will be especially tricky -- to the point of being useless. Actually, I'm not sure what the semantics are. Does #4 mean that there is a claim but it cannot be read due to lack of rights? Or does it mean that there's a lack of rights, thus no determination can be made as to whether or not the claim is present, populated, or not?
I suspect it means the former. Why? Because access control is often used not only to prevent one from reading values, but also to obscure/hide the possibility or presence of an attribute. Remember Mike's drug dealer example from earlier this year. If I ask for Mike's "favoriteDrugDealer" attribute and receive an answer like "it's present, but you can read it", it has been disclosed to me that Mike has favorite drug dealers.
The real problem I see with #4 is that some deployment scenarios (including the demo) use the AuthZ of the subject being read. I think there will be a wide array of access control behaviors across the different back-end IdP's. Some will not disclose to a user the permissions for attributes. They may even go as far as excluding the attribute definition during schema queries -- making the reader believe something like #3 is reality.
Here are some other cases (I think we're talking about attributes at the IdAS layer, so I'm calling them attributes):
5) Attribute is not part of the ontology (schema)
6) Attribute exists in the ontology, but is not allowed on the specified subject
7) Access controls allow knowledge of the attribute's presence, but disallows reading any values
Anecdotally, the X.500/LDAP model is such that one can only distinguish between 1 and 3 while reading an object, and 5 and 6 when reading schema.
Jim
>>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 12/8/06 9:34 AM >>> There are actually four cases (maybe more):
1) Claim is present and has a value
2) Claim is present, but empty
3) Claim is missing
4) Claim cannot be read because the authenticated user the STS is acting on behalf of does not have sufficient rights to read the claim.
I believe that if an STS receives a request for a claim, it should return information on the claim no matter what - one of the above four pieces of information should be returned. Then it should be left up to the RP what to do.
The RP states what it needs, and can request claims as either "required" or "optional." Required implies to me that the RP must have information about that claim no matter what - any of the above four pieces of information would satisfy that request. It should be left to the discretion of the RP what to do about the information returned.
If a claim is designated as optional by the RP, that is of no consequence to the STS. The designation of "optional" merely gives the user a chance to determine whether the claim should be returned. The fact is, when the list of requested claims is received by the STS in the RST, the user has, in one way or another, authorized releasing information about those claims. They have selected a card based on the required claims, and may have also authorized releasing some additional optional claims. To the STS, all requested claims should therefore be treated the same - as having been authorized for release by the user. Hence, it should return information on all claims that are requested and make no distinction between those that are labeled "required" versus "optional." Information returned could be any of the four I listed above.
That is my 2 cents. -- This represents a change of opinion for me. This would require us to change some things in the way our MediaWiki site (Woof) currently works. We need to be prepared to handle security tokens where claims come back as missing, empty, or "insufficient rights to read".
As a side note, as I experienced what a user had to do in CardSpace to authorize sending an optional claim, the thought occurred to me that the card selector should allow the user to specify more flexible policy about what to do with optional claims - autoauthorize, require user to explicitly authorize, autoauthorizeif RP == someURL, autoauthorizeif timeofday before 5:00 pm, etc. I hope that whoever implements the Higgins card selector will keep this in mind.
Daniel Sanders
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 12/8/2006 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 |