Transitioning IdPs

[Aaron Howell]

For DNS - drop the TTL on the record now in preparation - and reduce the propagation time - not too low though otherwise DNS cachers may chose to ignore it and use one of the SOA values instead (I think a minimum of 5 minutes is safe). I mean unfortunately I have found some browsers can ignore TTLs and do their own thing completely - but it is a low percentage

I used to run separate IdPs for HA in an active/passive setup - when failing over two situations happened:

  *   People coming in fresh from an SP with an SSO session on the old IdP had to log in again
  *   People part way through the login process already may get an error because the new IdP doesn’t know about them - would have to start the SSO process at the SP again

The first is a little annoying at worst, the second was rare (and in your case if you leave both running for a period of time - should be even rarer if not non-existent).

If you want to also change keys, you can publish multiple in the metadata now in preparation - so that SPs have the new certs. That’s more difficult with one of the keys than the other - I didn’t bother when moving IdPs last time - and kept the same keys.

Cheers,
Aaron

On 14 Feb 2019, at 6:29 am, Warren Anderson <warren.anderson at ligo.org<mailto:warren.anderson at ligo.org>> wrote:

Hi All,

I'm writing to ask if anyone has experience transitioning to a new IdP implementation. The background is that LIGO has has used the same IdP instance (upgraded and patched as necessary) since we adopted Shibboleth, but now we are trying to transition to an IdP hosted on a cloud service. We have our own metadata feed that is used internally by all our SPs (which are distributed around the world and run by people with widely differing skill sets) that is also served from our IdP, and we also have some vendors who we have a point-to-point metadata sharing arrangement with. We would like to incur as little downtime as possible in the transition as we are ramping up for our next observational run soon.

One idea that has been proposed is that we simply cut over entityID, certs/keys, DNS, etc to the new cloud IdP, but that could take a day or more for the metadata and DNS to propagate. It has been suggested that we could leave the current IdP running at the same time, so that wherever metadata queries and DNS resolve to there is an answer, but that seems very scary - when a browser that has a session with one version of the IdP tries to negotiate a new session that only knows about the other IdP, what would happen? (rhetorical question, BTW, unless the answer is "nothing bad')

I think we cannot be the only enterprise in the world who has had to solve this problem, so if anyone has done this, and especially if anyone has documented options and then selected one in particular, we would very much appreciate pointers. We'd also be open to just hearing thoughts from people with much more experience and/or expertise in this space than we have.

Thanks,
Warren
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>


Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.

Deakin University does not warrant that this email and any attachments are error or virus free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190213/d2e87e1f/attachment.html>