<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
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
<div class=""><br class="">
</div>
<div class="">I used to run separate IdPs for HA in an active/passive setup - when failing over two situations happened:</div>
<div class="">
<ul class="MailOutline">
<li class="">People coming in fresh from an SP with an SSO session on the old IdP had to log in again</li><li class="">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</li></ul>
<div class=""><br class="">
</div>
<div class="">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). </div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Aaron</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 14 Feb 2019, at 6:29 am, Warren Anderson <<a href="mailto:warren.anderson@ligo.org" class="">warren.anderson@ligo.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hi All,
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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')</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Warren</div>
</div>
-- <br class="">
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" class="">
https://wiki.shibboleth.net/confluence/x/coFAAg</a><br class="">
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="">
users-unsubscribe@shibboleth.net</a></div>
</blockquote>
</div>
<br class="">
</div>
<span style="font-size: 9.0pt; font-family: 'Calibri'; "><em><strong><br>
Important Notice:</strong> 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.<br>
<br>
Deakin University does not warrant that this email and any attachments are error or virus free.</em></span>
</body>
</html>