Processing HTTP_Redirect from idp

Cantor, Scott cantor.2 at osu.edu
Fri Nov 2 14:19:46 EDT 2018


> To clarify for Scott as well: We want users who access their link (which is currently set as
> shibboleth.company.com/Shibboleth.sso/Login?entityID=idps_encoded_entityID)
> to start hitting the new SP on sso.company.com/Shibboleth.sso/Login?entityID=idps_encoded_entityID

Having those links to begin with isn't a good idea, and this is why, but they're simply redirects, so implementing a permanent (for some definition) redirect from old to new is workable *by itself*. That still assumes all the real mechanics of SAML interaction are handled through appropriate exchange of metadata and that the metadata contains the real endpoints when they have to be used, which is the issue you're trying to get to.

The intended model is to add the new server endpoints ahead of time so the metadata can get to all the consumers before any requests come in from the SP asking for a response to one of them. And we use federations to get that metadata from the producer to the consumer, and that's why the software supports automated refresh of the metadata. Static metadata doesn't work for the reason you're now facing (it's an oxymoron), and automated doesn't scale if every IdP and SP have to point at each other.

Unfortunately if you have people with static copies of your metadata, you are screwed, to some degree, but you can still update a canonical source of the metadata with the right information and set a date by which all IdPs have to be using that updated copy.

-- Scott




More information about the users mailing list