Enterprise Shibboleth News – Migration Project

Background

Shibboleth is an open software system implemented based on a federated identity solution, which shares people’s electronic identities and attributes securely among multiple organizations and applications. Service Providers that are typically hosted externally are not required to handle Single Sign On (SSO); instead this is delegated to the Shibboleth Identity Provider which interacts with the authentication services and retrieves the necessary attributes and pass them electronically to the service providers.

Some Service Providers are members of InCommon, which is an education and research identity federation whose vetted and trusted members (which includes Rutgers) have agreed to collaborate and securely share information.  Other Service Providers which do not belong to InCommon may also integrate with Rutgers Shibboleth, assuming they have met certain criteria.

The Rutgers OIT-Enterprise Application Services department has undertaken an initiative to design and create an enterprise-wide Shibboleth system.  This new environment features modern robust technology, a separate dedicated testing platform, and improved network resilience to more effectively handle our institution’s increasing needs for federated login services.

What is changing?

• New hardware and networking environment:

• New 64-bit scalable virtual servers.  At minimum, there are two nodes for each tier in the data centers.
• Two data centers .  Primary data center is hosted on the cloud (new) and secondary data center is hosted on-premises .
• New network infrastructure, Global load balancing, and improved support of High Availability and failover.
• Monitoring software to send timely notifications of any outages to key OIT staff, leading to quicker response times for resolution.

• Dedicated development, testing, and production tiers:

  • The new enterprise Shibboleth environment will offer a streamlined way for Service Providers to easily test their configuration before production.
    

    Tier	Address	Notes
    Development	https://dev-idps.rutgers.edu	Development (internal use only)
    Test	https://test-idps.rutgers.edu	Open to all Service Providers
    Production	https://idps.rutgers.edu	Open to all Service Providers

  • With the establishment of these three dedicated tiers, it is envisioned that testing and integration will be streamlined for future federation requests.

• Identity Provider version 3:

  • The current (legacy) Shibboleth system is running version 2 of the Identity Provider software. The new environment will be running version 3, which offers additional features such as user consent for attribute release, enhanced clustering support, Single Log Out (see below for more information), and more flexible configuration options.

• Identity Provider Metadata:

  • Because of the new hardware environment and updated network configurations, certain components of the Rutgers Identity Provider metadata will change and will need to be manually updated, tested, and deployed by each individual Service Provider (which is not a member of the InCommon federation). Service Providers belonging to the InCommon federation will automatically receive the updated Rutgers Identity Provider metadata and will have little to no changes to make to their systems.  Specifically, the signing certificate and the SSO endpoints will all be updated to reflect the new environment (idps.rutgers.edu).

• URL references to shib.oirt.rutgers.edu (if applicable):

  • Some Service Providers may have explicit references to the current (legacy) Shibboleth URL of https://shib.oirt.rutgers.edu embedded within their configuration files or web pages.  These references may include, for example, Identity Provider-initiated URLs or logout pages. These will need to be changed to reflect the new Shibboleth environment’s URLs and endpoints.  OIT can assist with providing the appropriate information for updating these legacy references.

• Single Log Out (optional):

  • The new Shibboleth environment supports Single Log Out (SLO), which provides a more user-friendly method of allowing users to log out of the Service Provider’s application, if desired. After logging out from the Service Provider, the user will be redirected to an informational page which will allow them to decide whether to also delete the existing CAS cookie to achieve true single sign-off. It’s important to note from a security perspective that unless the CAS cookie is also explicitly deleted, the user can log back into the Service Provider’s application without needing to enter in their NetID and password.
  • This article gives further insight into the inherent limitations of SLO.
  • With these limitations in mind, if Service Providers still wish to take advantage of this new capability, they will need to make the necessary configuration changes on their systems. If this new capability is not desired, the Service Provider can simply comment out the SLO declaration in the Identity Provider metadata and/or replace it with its own logout URL. In this case, logout from the vendor’s application is then typically handled by instructing the end-users to close their web browser tab/window.

What is not changing?

• Any existing attribute release rules or special configurations:
  The Service Providers will continue to receive the same attributes in the same format as they were under the existing (legacy) system.

• EntityID:
  The EntityID, which is a globally unique identifier for the Rutgers Identity Provider system within the InCommon federation, will remain the same (urn:mace:incommon:rutgers.edu). This is to ensure business continuity with our InCommon partners.

Migration Strategy

The migration from the existing legacy to the new environment will be done in two phases:

• For non-InCommon Service Providers: Since some Service Providers are not InCommon members, it will be necessary to manually provide them with the new Rutgers Identity Provider metadata. Depending on their particular software configuration, the Service Providers may need to provide us with their updated metadata which would then be loaded into our new test and production environments.  We anticipate this migration phase to potentially last for weeks or even months, as we may have to work with each Service Provider individually to ensure that SSO is functioning for them exactly as it does in the existing (legacy) system.  Please follow these instructions to initiate your migration.

• For InCommon Service Providers: InCommon members typically utilize the federation metadata (which is an aggregate of every single InCommon member’s metadata) that is automatically refreshed and distributed to all members usually once every day.  After the non-InCommon Service Providers have been fully tested and integrated with the new Shibboleth environment, Rutgers will upload the new Identity Provider metadata to InCommon.  Our information will then be automatically distributed to the rest of the federation.  This step will help ensure a seamless transition from the existing (legacy) environment to the new one for InCommon members.  Please see Latest on this effort 

Testing

As mentioned above, the migration will be carried out in two phases.  The first phase will be a manual migration involving all identified non-InCommon Service Providers who have existing integration with the Rutgers Shibboleth system.  Since the new environment will have a dedicated testing tier, we will strongly recommend that the Service Providers first integrate with our new test Identity Provider server to allow for suitable testing, if feasible.  Once both Rutgers and the Service Providers agree that the correct attributes are being released and received in the test environment, the necessary configurations can then be copied to the production environment.

Once most or all of the non-InCommon Service Providers have been migrated over to using our new Shibboleth environment, Rutgers will upload our new production Identity Provider metadata to the InCommon federation.  The aggregated InCommon metadata, which will now contain our new Identity Provider information, will be automatically distributed to all the other members in a short period of time.  Once distributed, all InCommon Service Providers will be able to continue receiving information from Rutgers via the new Shibboleth environment just as they did via the existing (legacy) environment.

Timelines. (This work is completed)

• The new production Shibboleth environment was deployed in production as a soft-launch on August 8, 2016.
• All new non-InCommon federation requests received by August 8, 2016 have already been applied on the new production Shibboleth environment.
• Manual migration of all non-InCommon Service Providers began on September 15, 2016.
• The existing (legacy) Shibboleth environment is tentatively expected to be decommissioned by October, 2017.
• Even though we are allocating several months for ample testing and changeover during the manual migration, we nevertheless strongly recommend that Service Providers adopt a proactive approach with regards to testing and updating their configuration well in advance of the legacy decommissioning date to avoid or minimize any potential impact to their clientele.
• OIT staff will be available during the entirety of the manual migration phase to assist with any questions or concerns. Questions specifically pertaining to Shibboleth can be addressed to OIT staff at idp_operations@email.rutgers.edu.