OpenSAML user discussion

["Scott Cantor" <>]

> One issue that came up is with the change to SAMLSubject wrt the
> use of SAMLNameIdentifier. I changed the code to use the
> SAMLNameIdentifier class but now a an equals operation on
> two SAMLSubjects failed (verification if the subject
> in an authorization decision stmt equals the subject 
> provided in the query).

Your implication is that it worked before? If so, by accident. But I would
assume the default version of the method is not gonna work. It probably
compares members on at least some kind of level (that's how C++ works), and
since some of the members are DOM-related, it doesn't make any sense to do
this.

Note that C++ has no such method. And I didn't define the equality operator
(I probably should have defined it private). Therefore it's nonsense to
compare two SAML objects directly in C++, and so by implication it's
nonsense in Java too.

> So the next step was to look at three values of the SAMLNameIdentifier
> (Name, Qualifier, Format) by printing them to screen. I found
> that in the request the qualifier was set to "null" where as it
> was an empty string in the received response. (is this a bug
> in the parser?)

Probably my bug. That definitely shouldn't be happening.

> I thought that this may have made the equals 
> method fail. I thus created the subject for the request
> with an empty string "" as the qualifier. Now the name, qualifier, format
> strings of the sent out request subject and the received response subject
> look exactly the same on the screen but the equals method still fails.  

Probably because the root DOM pointer inside doesn't match. Which isn't
surprising, it shouldn't.

> So now I compared the name, qualifier and format value individually
> via a couple of if statements and .... they are equal, however the
> equals method on the whole SAMLNAmeIdentifier object still fails.

Yep, I would expect so.

> Should a specialized equals method be provided by the object to 
> deal with this case.

Well, that depends on what equals() means. ;-) That's a hard question to
answer. Does it mean the same object, or logically a match? And if so, in
what context? Probably, a member compare is a reasonable definition, but I
didn't address it.

> In any case is there a set of rules on how a subject has to be
> matched to be considered equal? (i.e. i may have the same subject
> that in the AuthorizationDecisionQuery provides only the name and format,
> while in an embedded evidence element provides elaborate confirmation data

Correct. Subject matching in SAML 1.1 is only defined based on the profile.
For queries, matching rules are very strict (too strict, in fact, they
require that the confirmation matches). SAML 2.0 has slightly different
rules, but the rules still vary based on the context.

So I don't think there's any way to have a single equals() method except by
just making it up.

> - I am arguing that the subjects, even though their confirmation data
> differs, are the same entity.

If you read the query text in 1.1, you'll see that that's actually not
legal. I changed the rules in 2.0 because I thought that was wrong. OTOH, it
now makes the new rules very gray, because evaluating subject confirmation
can be <ahem> subjective.

But in regards to your use case, I think you need to probably abstract what
equality means from anything the raw library does. We could add SAMLSubject
methods that apply spec-supplied rules for subject matching, though.

-- Scott