This is a draft.Please do not follow this (yet)
IdP software upgrade
If you are running IdP v1.3 or lower consider the following before upgrading to IdP 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 i 2.x
Post jsp, Error pages
IdP 1.3 used idppost.jsp to post authn assertion to SP's, where as 2.x uses velocity templates. If you customized the post jsp, you will have to customize the velocity templates as well.
You will find the templates at ...
Customize and copy them to $IDP/webapps/WEB-INF/classes/templates. This will override the default templates that is bundled in the jar.
Authentication
It s different for each school. 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
h3 Convert ARP
in 2.x 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 tool to convert the ARP to AFP.
h3 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.
h3 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 implem,entation was buggy. No one complained so far.
ePTID may be stored in a database. You don't eed to generate on the fly. WE thought it is an additioanl dependency. We chose to generate on the fly, at the expense of run time performace (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.