ShibIdPUpgrade

IdP software upgrade

If you are running IdP v1.3 consider the following before upgrading the software. IdP v2.x is substantially different from 1.3 code base.

Customization

Did you customize IdP 1.3 in any way? Most installers have customized to some degree. If you did, do the same in 2.x

Authn response post

IdP v1.3 used a jsp (IdP.jsp?) to post Authn assertion back to SP's, where as v2 uses velocity templates. If you customized the jsp, you may want to customize the velocity templates as well.

Velocity templates are bundled as part of the jar.
Customize and copy them to $IDP_WEBAPP/WEB-INF/classes/templates. This will override the default templates that is bundled in the jar.

Authentication

Integrating IdP with campus Auhectication may be different at each campus.
UCLA uses custom authentication service hosted by a different group in the campus. We used RemoteUSerAuthetication handler. If you are using LDAP or some other authn, consult Shibboleth wiki/forum.

handler.xml

..
..
<LoginHandler xsi:type="PreviousSession" authenticationDuration="PT15M">
        <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</AuthenticationMethod>
    </LoginHandler>

    <LoginHandler xsi:type="RemoteUser" authenticationDuration="PT15M">
        <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthenticationMethod>
    </LoginHandler>

web.xml

<!-- UCLA custom  -->
<filter>
	  <filter-name>authnrequest</filter-name>
	  <filter-class>edu.ucla.iamucla.tsunami.custom.AuthnRequestFilter</filter-class>
	</filter>
	<filter-mapping>
		<filter-name>authnrequest</filter-name>
		<url-pattern>/Authn/RemoteUser</url-pattern>
	</filter-mapping>

..
..
..

<!-- Servlet protected by container user for RemoteUser authentication -->
    <servlet>
        <servlet-name>RemoteUserAuthHandler</servlet-name>
        <servlet-class>edu.internet2.middleware.shibboleth.idp.authn.provider.RemoteUserAuthServlet</servlet-class>
        <load-on-startup>3</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>RemoteUserAuthHandler</servlet-name>
        <url-pattern>/Authn/RemoteUser</url-pattern>
    </servlet-mapping>

Convert ARP

AFP replaces ARP. Schema is completely different. Handcoding/converting ARP to AFP is an arduous tasks if you have many AFPs. UCLA had 200+ custom release policies.
We developed a script to convert the ARP to AFP. Available on request.

Metadata

1.3 Metadata should be reusable.
SPs will continue to use SAML 1.1 protocol. Do not advertise new features (for ex, SAML 2 end points). Get the new version working for few days and then start rolling out new features of 2.x software.

ePTID

Is any of your relying party dependent on ePTID? Implementation may be different in 2.x. Make sure same algorithm is used to generate ePTID.
At UCLA we took a chance and implemented new. Our 1.3 implementation was buggy. No one complained so far.

ePTID may be stored in a database. You don't need to generate on the fly. WE thought it is an additional dependency. We chose to generate on the fly, at the expense of run time performance (which is negligible now a days)

Will this upgrade cause service interruption?

There will be a brief interruption to UCLA SSO services during this period, while we transition to the new software.

Please note upgrade activity takes 2-3 hours as we take each server offline, upgrade the software, reintroduce to the mix and move on to the next server. However we expect actual outage to be under 2 minutes at around 11:00am.

Impact on users

SSO service may not be available during rollout/deployment.
Users will lose their SSO session. When users move from one application to the next, they may be asked to sign in again. SSO does not work across two versions of the software.

Inform the users early.

Impact on Shibboleth Service Provider(SP)/applications

Upgrade should be transparent to SP's. No configuration change is mandated on the SP side.
Do you have SP specific customization, specially login page, logout page, help etc.?

Keep the SP's informed.

Session clustering and Terracotta

Do you need to cluster the sessions for load balancing and failover? You may have to use Terracotta to do the same.

There is a steep learning curve to configuring and using terracotta.

Due to the complexity, IdP designers decided to discontinue Terracotta and use a new clustering solution in v3.0. Is it worth investing the time and effort in Terracotta now, knowing that it will go away in a year?
On the other hand how important is it to provide smooth failover? These are the trade offs you have to think about.

It is possible to run 2.x without clustering. See notes.

Testing

If you are using Terracotta, set up test environment that mimics production ACTIVE ad STANDBY instances. Test terracotta fail over scenarios.

Backout

DO you have a backout plan if the unexpected happens? How quickly can you restore 1.3?

Apache/Tomcat

Are you fronting tomcat/IdP with Apache? Are you hosting the IdP at the same location/URL?
To minimize the disruption it is advised not to change IdP SSO & AA endpoints (in the metadata) that is distributed to SPs.