v2->v3 upgrade, idp-metadata.xml

Peter Schober peter.schober at univie.ac.at
Thu Jul 7 09:15:06 EDT 2016


* Cantor, Scott <cantor.2 at osu.edu> [2016-07-07 03:08]:
> Not changing the entityID ever is much more important than any other
> consideration but you also don't buy very much by leaving the
> entityID and changing the endpoints or keys either. If you change
> any of them, you're turning a relatively simple process into a huge
> undertaking that is basically impossible to test effectively. You've
> created a new IdP, basically, and you have to now touch potentially
> every non-Shibboleth/SSP SP you deal with.

Assuming I knew there were no weird (as in: configured via other
methods than just SAML Metadata) peerings for a given IDP, keeping the
entityID the same and replacing anything else in metadata (as a fresh
IDP install would create, incl new keys, and possibly a new hostname
in protocol endpoints) does look like a possible (though more risky)
way forward to me -- /if/ you wanted to change the IDP server name
anyway and move to a v3 IDP at the same time?

SPs still having cached the old metadata will continue talking to the
v2 IDP (using the old hostname in protocol endpoints, accepting signed
messages with the old keys).
SPs having already updated metadata for the IDP would use the new v3
IDP, with protocol endpoints at the new server, but wouldn't be
affected by changed targeted identifiers or hard-coded session
initiators etc., due to the entityID having remained the same?

Of course testing becomes more involved then.
-peter


More information about the users mailing list