On the conference call this morning I mentioned I had to set
MellonSPentityId and Simo said "that sounds wrong, lasso should load it
from the metadata". During the conference I couldn't remember the exact
issue so I went back and investigated. Simo was right, lasso does load
it from the metadata but you can override it in the Mellon config, so
why did I need to do this?
I discovered the hard way it's very easy to get mellon to screw up your
SP metadata if you allow mellon to generate it. Here's the issue, when
mellon generates the metadata it does so on first request, it takes the
URL of the request and uses the first part of the URL (the mellon
endpoint) as the entityID and the prefix for all the binding URL's in
the metadata. If the server is configured to allow both http and https
schemes mellon will happily set your entityID and binding URL's to
include either http or https depending on the first request it sees. If
Ipsilon loaded metadata from http but you're using https everything
get's screwed up because the entityID's and binding URL's don't match.
I suppose in a real deployment one would have an Apache rewrite rule
that redirected any mellon http endpoints to https. But if you've just
set things up to test you may not have forced only https for mellon.
So this is just a head's up warning, metadata resolution can fail
leading to confusing failures if at any point you were not rigorous over
uniformly using http vs. https. FWIW I always test SAML using https but
at times had grabbed the SP metadata using http, if you then load that
into Ipsilon bad things happen, or if you had loaded metadata into
Ipsilon that had been generated with https but the first request to
mellon was http, things just won't resolve. If like me you're restarting
mellon many times a day the opportunity for a finger fumble is great,
something that worked last invocation now fails mysteriously ;-). Just a
heads up so you don't get burned.
--
John