<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>We are currently running Shibboleth 2.x IDP as an upgrade from a 1.x version. When we upgraded we didn't deploy the SAML 2 endpoints to InCommon as part of the upgrade process. So, we're in the situation that our IDP supports and is configured for SAML2, but they just haven't been utilized by our SPs to this point. Now we're finding a lot of SPs want to use only SAML2 so we want to get those endpoints published and move into the SAML2 era.</div><div><br></div><div>To complicate matters, almost all of our SPs use InCommon Metadata. So, in order to update them we have to publish the endpoints and then wait for them to take hold and see if anyone has any problems.</div><div><br></div><div><b>I was wondering if anyone has any advice how to approach this transition and if anyone had dealt with this specific issue in the past. </b></div><div><br></div><div>I found this page on UnsolicitiedSSO <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO</a>, and I can't find it anymore but there was a page suggesting using it as a method to ease the transition.</div><div><br></div><div>The technique described there was to deploy the non-SSO endpoints, and then test the operability by crafting an UnsolicitedSSO url for each SP. This would test most of the transaction, but not allow any SP to directly trigger the use of SAML2 communication. This seems like a good plan, though it still eventually results in us having to deploy the SSO endpoints cold turkey and hoping they work--though I can't really fathom what could go wrong at that point.</div><div><br></div><div>Anyway, I just would like to gather any advice I can on the subject and any links to information on this subject would be appreciated as well.</div><div><br></div><div>Thanks,</div><div><br></div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Chris Peters</div><div>Middleware Services Developer</div><div>Office of Information Technology - NSP</div><div>(949) 824-6845</div><div><a href="mailto:cjpeters@uci.edu">cjpeters@uci.edu</a></div><div><br></div></div></span></div></span></span>
</div>
<br></body></html>