CDSV3

Centralized Discovery Service V3

The consortium board has voted to allow the V2 CDS to reach EOL and freeze any further work on it. The EDS remains supported.

Introduction

The currently shipping CDS is getting very old and cumbersome and currently requires several libraries which are end of life or will be by mid-2016.

There are currently active discussions as to whether we will offer anything in replacement or point customers at any of the other discovery implementations that have become available. If anyone wish to make input to this process they should do so sooner rather than later.

If we are to develop a CDS then we need to start reasonably soon, and with that in mind below is some collated documentation (part requirements document, part top level design document, part project plan).

Requirements

The CDS MUST

  • Handle both the Discovery Protocol and the Shibboleth IdP Initiated SSO (WAYF) protocol
  • Be deployable in in ways which do not require the use of JavaScript in the browser
  • Be trivially clusterable (no server state)

The CDS SHOULD

  • Be easily customizable for other “skins” (the touch point will be integration with the UK CDS)
  • Allow easy and changes to the "skinning". (e.g. without rebuilding the war file if possible).

The CDS need not offer the following (which are available to CDS V2)

  • Offer any configuration compatibility to V2 of the CDS
  • Support WAYF and DS protocols on the same end point (the current CDS does)
  • Any concept of Federation. Metadata is Just a bunch of data.

Technical Considerations

We want:

  • To leverage the Shibboleth EDS
  • To leverage OpenSAML3 and (if possible) code for Shibboleth IdP V3 (for instance Metadata ProviderParsers?), ReloadingServices

Technology:

  • Spring MVC
  • Spring Beans
  • OpenSAML and the implementations of org.opensaml.saml.metadata.resolver.BatchMetadatResolver
  • (probably) The IdP impplemerntation of net.shibboleth.idp.saml.metadata.impl.ReloadingRelyingPartyMetadataProvider (and all the supporting infrastructure)
  • A pair of protocol bridges to allow WAYF to be handled by the common DS code (possibly using local profile of the DS protocol to encapsulate the WAYF parameters)
  • Velocity Template to render the putative IdP List
  • Design document for the protocol bridges
  • Design notes for the CriteriaSets used to generate the data
  • Learn Spring MVC
  • Design items list above
  • Extra Design items resulting from MVC code learn.

Design Items

Work Items