Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> > SAML 1.1 allows signing either at the level of the Response, and 
> > independently at the level of the Assertion.  In the Shibboleth 
> > Browser/POST profile, we have two messages from the IdP to the SP, and 
> > at least in principle there are therefore four things that might be 
> > signed (auth response, auth assertion, attr response, attr assertion).
>
> This depends on whether attributes are present in the original response, but
> you know that.

I hadn't noticed that before, but I can see that the schema insists on 
at least one Attribute in an AttributeStatement, so now I do.  Thanks.

> Others seem to think this is false, that lack of peer authentication doesn't
> negate the confidentiality. I think this is only true in the strictest
> sense, but not in an application sense of the word. Feedback on this would
> be welcome.

I think I'm with you on this one.  Knowing that you are confidentially 
passing information to "someone" but without knowing who that someone 
is, surely means that you're vulnerable to a man in the middle attack 
where the confidential channel confidentially goes to the wrong person.

I guess we get away without mutual authentication at the TLS level in 
browser applications because the user authenticates to the server inside 
the channel (by logging in, say).  But in general the server cares less 
about who it is talking to than the user does in those cases.

> > As well as the RelyingParty configuration at the IdP, the 1.3 IdP will 
> > sign assertions if the SPSSODescriptor in the metadata has a 
> > @WantAssertionsSigned attribute set to "true", but again this applies to 
> > both assertions.
>
> Wow. Didn't know Walter had implemented that.

I just happened on this while reading the code yesterday.  It's nice 
because it lets me change IdP behaviour by lying in the metadata, which 
takes effect right away rather than having to reconfigure the IdP and 
restart it.

> > Now, the signed attribute assertion does not go so well. My log results 
> > for the attribute response are incomplete: I can see the start of the 
> > response, at <soap:Envelope> but the log info ends after 5725 chars 
> > round about the time the signature is about to start (there are lots of 
> > attributes in there, the Content-Length is 7990).  I guess the log line 
> > must be limited in some way (not a big surprise if so, although 5725 
> > seems a bit arbitrary).
>
> I think you're seeing libcurl output, not mine.

The trace line starts with a timestamp then "DEBUG SAML.libcurl [1] 
sessionGet:", so that seems likely.

> I don't dump the SOAP
> myself, I don't think. libcurl probably truncates the trace, or perhaps it's
> caused by the code I added to deal with libcurl sending me binary trace
> data. Could be the linefeed, I'll check that.

The trace line finishes with this:

</Attribute></AttributeStatement><ds:Signature 
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>

(no line break after ds:Signature in the original)

It ends exactly after the '>', so maybe there is something interesting 
happening there, as that seems like a bit of a coincidence.

> > Any ideas as to why this signature is failing to verify, or whether that 
> > is actually what I'm seeing?
>
> Sounds like it. I just turned on WantAssertionsSigned for wayf, and tested
> it. It worked fine once I added a KeyDescriptor to the AttributeAuthority
> role. Did you do that?

Yes, I had duplicated the one I had on the IDPSSO role.  I notice there 
is a newline just there in the equivalent place in the decoded SAML 
response you put out when the auth response comes in.

If you managed to get this to work, I guess it is likely to be finger 
trouble on my part somewhere.  I will go back to square one and try 
again, very carefully.

        -- Ian