Metadata Changeover Questions

[Peter Schober]

* McKean, Brandon Scott - mckeanbs <mckeanbs at jmu.edu> [2015-07-22 14:40]:
> I've been looking at adding new SPs to our existing IDP, but also
> transitioning away from SAML 1 in favor of SAML 2 as best we can. To
> this end, I'm suspecting I could give new SPs a copy of our metadata
> that has SAML1 elements removed in order to achieve a transition.

(Don't forget about the protocolSupportEnumeration attribute on the
IDPSSODescriptor element.)

Giving SPs metadata w/o any traces of SAML1 in it is certainly
possible. Whether that's /advisable/ in any given deployment is a very
different question. I'd at least look at the logs (as far back as you
care) whether all services you need to support are actively being used
over SAML2. (Presence of SAML2 support in SP's metadata does not mean
you can be certain it's also used.)
The IDP log analyzer I wrote ages ago might be of help for this:
https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+Audit+Log+Analysis+Tool
Option "--msgprofiles".

> Am I on the right track with this? What I'd want to do is supply the
> modified metadata to new SPs so that we have one less thing to worry
> about transitioning, and supply it to InCommon so that we could, in
> theory at least, have a fairly seamless transition since the IDP still
> technically supports SAML1, but would only be advertising SAML2 in
> metadata.

Ignoring broken SPs that will unconditionally send
"Shibboleth"-protocol SAML1 requests, even if you don't announce any
suppport/endpoints for SAML1 in metadata (something to consider -- you
may not be able to actually ignore those!), that would break all SPs
that need SAML1 to work.
With the proposed strategy you'd only keep those SAML1-only systems
working that do /not/ use SAML metadata to determine run-time
behaviour, breaking others.

It will certainly be interesting to see what breaks if you remove
SAML1 support from metadata, though. That's not a safe deployment
stagegy, of course.
-peter