Note: The information on this page has been copied to ​http://www.clarin.eu/node/3481 (for public access). Please also change it there if a significant change is made.

CLARIN Central Discovery Service

The CLARIN central discovery service is based on DiscoJuice (version 1.0), see: ​http://discojuice.org/.

The goal is to provide an easy to use discovery service for all CLARIN service providers. By using the same discovery service users do not have to re-login or re-select their IDP when switching between service providers. A drawback of the central discovery service is the fact that it introduce a single point of failure (SPOF). Currently we are looking into ways to make this central discovery service high availability.

Status

The CLARIN central discojuice "Where Are You From" (WAYF) service is currently operating as a beta service.

Currently used at the catalog.clarin.eu SPs, like the component registry: ​http://catalog.clarin.eu/ds/ComponentRegistry/ (click on login)

Roadmap

• We plan to release version 1 of the CLARIN central discojuice WAYF service around Christmas 2011.
• Look into high availability options.
• Upgrade to DiscoJuice 2.0

Configuration

How to use discojuice as your shibboleth WAYF?

1. Get access to a discojuice WAYF:
   1. Host discojuice yourself (see ​http://discojuice.org for installation instructions).
   2. Use an external hosted discojuice WAYF service (​http://catalog.clarin.eu/discojuice/idp.html provided by CLARIN).
2. Configure a login endpoint in your SP configuration to use the discojuice WAYF service ( either 1a or 1b ), see the next section for more details.
3. Use this new login endpoint

DiscoJuice login endpoint

In order to use discojuice as the WAYF service, a session initiator needs to be configured in the SPs 'shibboleth2.xml' configuration file. The 'Location' attribute specifies the login endpoint you can use to append to your handler url (/Shibboleth.sso by default) to start a shibboleth session. The 'URL' attribute of the session initiator of type 'SAMLDS' should point to the discojuice installation you want to use.

A restart of the SP is required after changing the 'shibboleth2.xml' configuration file.

Example using the CLARIN provided discojuice WAYF:

<SessionInitiator type="Chaining" Location="/DiscoJuice" id="DiscoJuice" relayState="cookie">
     <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
     <SessionInitiator type="Shib1" defaultACSIndex="5"/>
     <SessionInitiator type="SAMLDS" URL="http://catalog.clarin.eu/discojuice/idp.html"/>
 </SessionInitiator>

If you're using Shibboleth 2.4.x you can use the following, less verbose, snippet:

  <!-- use CLARIN central discovery service (DiscoJuice) -->
  <SSO discoveryProtocol="SAMLDS" discoveryURL="http://catalog.clarin.eu/discojuice/idp.html">
    SAML2 SAML1
  </SSO>

Make sure to restart shibd and the Apache webserver for changes to come into effect!

Availability

Old situation

In the old situation the tomcat-clarin was running as a single instance behind apache. The path /mw/* is mounted in apache by mod_jk and all requests here are forwarded to the tomcat-clarin via the AJP13 protocol. The idp location “/discojuice/idp.html” is rewritten to “/mw/…” to provide a stable entry point for users of the service and remain flexible in the backend. This setup does not provide any redundancy and maintenance has to be performed in the running production service.

New situation

To overcome the effects of maintenance on the running production service we propose the following setup (with options for more enhancements in the future).

In this setup two tomcat instances (tomcat-clarin1 and tomcat-clarin2) are mounted in apache with mod_jk as /mw1/* and /mw2/*. With the apache rewrite rule we can choose which of the two instance is active and this allows us to perform maintenance and testing on the other instance without disruption of the live instance. When maintenance is completed the rewrite rule is changed to point to the updated instance which then becomes live and we can easily update the other instance.

Future possibilities

The proposed setup can easily be improved by a number of steps:

• Split the apache in tomcat instances over different (virtual) machines. Providing a working service if one of the tomcat machines would crash.
• Make the apache instance redundant and configure a H/A solution (e.g. heartbeat + virtual IP) where the backup instance can take over if the live instance crashes.
• Configure load balancing from apache to the tomcat-instances.
• Configure load balancing in front of the apache instances (e.g. use ultramonkey ).

Although these steps will increasingly provide high availability of the service we want to start simple and discuss what options are necessary to provide later on. Maintenance Policy

Next to the technical changes we would like to propose two policies to improve communication about maintenance.

1. Maintenance on the WAYF and IDP services will be announced 1 week in advance on the (dev)mailing list.

2. We will plan maintenance in such a way that the day after a system administrator is available (unless something unexpected happens, e.g. breaking a leg or something).

3. Moreover in the case of a failure of the discojuice service we want to test the possibility to provide a rewrite of the production login endpoint to a backup (old-style) WAYF we host as well.