OpenSAML user discussion

[Tom Scavo <>]

On 1/13/06, Scott Cantor 
<>
 wrote:
> >
> > public boolean stronglyMatches(Object o);
>
> Another might be:
>
> public boolean stronglyMatches(SAMLSubject s1, SAMLSubject s2);

I presume you mean for this to be a static method, otherwise I'm not
understanding what you mean.  A static method is an alternative, I
suppose, but an instance method seems more natural.

> > How would you implement such a method without a corresponding equals
> > method for SAMLNameIdentifier?
>
> If there's a need for a matching method that has specific semantics, then
> you can argue SAMLNameIdentifier should have one.

I am. :-)

> I would argue that using
> equals() for that is not only not necessary, but in fact a really horrible
> idea.

Sorry, I don't see why an equivalence relation on SAMLNameIdentifier
objects (and SAMLObjects in general) is such a bad idea.  In fact, I
think I've given ample reasons to show the opposite is true.

> If everything I've said in this thread doesn't make that self-evident,
> we're just talking past each other about the very notion of equality.

Perhaps the confusion stems from the Java distinction between equality
(==) and equivalence (equals).  It's unfortunate that Java chose to
implement equivalence with a method called equals, but that's the way
it is.

AFAIK, equality (==) is not used in OpenSAML or Shibboleth to compare
SAML objects.  On the other hand, equivalence (equals) is needed in
SAMLNameIdentifier to handle the default format, 'unspecified'. 
Without it, the following unit test fails:

    public void testUnspecifiedFormatWithToString() throws Exception {
        String name = "any name";
        String nameQualifier = "any name qualifier";

        SAMLNameIdentifier nameid1, nameid2;
        nameid1 = new SAMLNameIdentifier(name, nameQualifier, null);
        nameid2 = new SAMLNameIdentifier(name, nameQualifier,
FORMAT_UNSPECIFIED);

        assertEquals("NameIdentifiers not equal",
                     nameid1.toString(), nameid1.toString());
        assertEquals("NameIdentifiers not equal",
                     nameid1.toString(), nameid2.toString());
        assertEquals("NameIdentifiers not equal",
                     nameid2.toString(), nameid1.toString());
        assertEquals("NameIdentifiers not equal",
                     nameid2.toString(), nameid2.toString());
    }

This fails because String equivalence is inappropriate in this case. 
An equivalence relation on NameIdentifiers is needed, which is
precisely what the equals method is supposed to implement.

> But you can also just define a function:
>
> public boolean stronglyMatches(SAMLNameIdentifier n1, SAMLNameIdentifier
> n2);

(Again, I presume you mean a static method.)  AFAIK, SAML has no
notion of "strongly matches" with respect to NameIdentifiers.  The
spec says the NameIdentifiers of two strongly matching SAMLSubjects
must be "identical".  IMO, that coincides with the Java notion of
'equals', which is another argument in favor of an equals method on
SAMLNameIdentifier instances.

> I don't see any particular reason why it would need intimate access to the
> implementation classes

I tried to explain this in another thread.  The spec says that the
absence of a specific format URI implies the 'unspecified' format, so
this must be taken into account when equating formats.  This should be
done in the SAMLNameIdentifier class itself.

Tom