Changes between Version 12 and Version 13 of ServiceProviderFederation/Discovery


Ignore:
Timestamp:
11/19/15 11:57:56 (9 years ago)
Author:
Sander Maijers
Comment:

Overhaul

Legend:

Unmodified
Added
Removed
Modified

  • ServiceProviderFederation/Discovery

    v12 v13  
    33= CLARIN Central Discovery Service =
    44
    5 The CLARIN central discovery service is based on !DiscoJuice (version 1.0), see: http://discojuice.org/.
     5The CLARIN central Discovery Service (DS) is based on !DiscoJuice (version 1.0), see: http://discojuice.org/.
    66
    7 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.
     7The goal is to provide an easy to use entry point for all CLARIN Service Provider Federation (SPF) Service Providers (SPs), which allows users to select an institutional Identity Provider (IdP) to log in to. By using the same Discovery Service users do not have to re-login or re-select their IdP when switching between SPs. A drawback of the central DS is the fact that it is a single point of failure. We are still looking into the best way to make the central DS highly available.
    88
    99= Status =
    1010
    11 The CLARIN central discojuice "Where Are You From" (WAYF) service is currently operating as a beta service.
     11Currently used at the catalog.clarin.eu SP, see e.g. the Component Registry:
     12https://catalog.clarin.eu/ds/ComponentRegistry/ (click on login)
    1213
    13 Currently used at the catalog.clarin.eu SPs, like the component registry:
    14 http://catalog.clarin.eu/ds/ComponentRegistry/ (click on login)
     14= To configure
    1515
    16 = Roadmap =
     16=== For Shibboleth Service Provider
    1717
    18 * We plan to release version 1 of the CLARIN central discojuice WAYF service around Christmas 2011.
    19 * Look into high availability options.
    20 * Upgrade to !DiscoJuice 2.0
     18In order to use the central Discovery Service, your Shibboleth Service Provider's configuration must have the right session initiator configuration. You can change this in the `shibboleth2.xml` configuration file. The `Location` attribute specifies the login endpoint you can use to append to your handler URLs (`/Shibboleth.sso` by default) to start a SAML session. The `URL` attribute of the session initiator of type `SAMLDS` should point to the !DiscoJuice installation you want to use.
    2119
    22 = Configuration =
     20Please add to `shibboleth2.xml`:
    2321
    24 How to use discojuice as your shibboleth WAYF?
     22{{{
     23  <!-- Use CLARIN central Discovery Service -->
     24  <SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.clarin.eu/discojuice">
     25    SAML2
     26  </SSO>
     27}}}
     28'''(A restart of `shibd` and a reload of your web server and is required afterwards.)'''
    2529
    26  1. Get access to a discojuice WAYF:
    27   a. Host discojuice yourself (see http://discojuice.org for installation instructions).
    28   b. Use an external hosted discojuice WAYF service (http://catalog.clarin.eu/discojuice/idp.html provided by CLARIN).   
    29  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.
    30  3. Use this new login endpoint
    31 
    32 === !DiscoJuice login endpoint ===
    33 
    34 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.
    35 
    36 A restart of the SP is required after changing the 'shibboleth2.xml' configuration file.
    37 
    38 Example using the CLARIN provided discojuice WAYF:
     30If you're using Shibboleth SP < version 2.4.x you must use the following, more verbose, snippet:
    3931{{{
    4032<SessionInitiator type="Chaining" Location="/DiscoJuice" id="DiscoJuice" relayState="cookie">
    4133     <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
    4234     <SessionInitiator type="Shib1" defaultACSIndex="5"/>
    43      <SessionInitiator type="SAMLDS" URL="http://catalog.clarin.eu/discojuice/idp.html"/>
     35     <SessionInitiator type="SAMLDS" URL="https://discovery.clarin.eu/discojuice"/>
    4436 </SessionInitiator>
    4537}}}
    4638
    47 If you're using Shibboleth 2.4.x you can use the following, less verbose, snippet:
    48 {{{
    49   <!-- use CLARIN central discovery service (DiscoJuice) -->
    50   <SSO discoveryProtocol="SAMLDS" discoveryURL="http://catalog.clarin.eu/discojuice/idp.html">
    51     SAML2 SAML1
    52   </SSO>
    53 }}}
     39=== For other Service Provider implementations (technical details)
    5440
    55 Make sure to restart shibd and the Apache webserver for changes to come into effect!
     41The CLARIN central Discovery Service is not Shibboleth-specific, but complies with the [http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf SAML Identity Provider Discovery Service Protocol].
    5642
    57 = Availability =
     43Your Service Provider should also follow this protocol. This means simply that you HTTP-redirect the user to the central Discovery Service.
    5844
    59 == Old situation ==
     45In practice we use the following HTTP request parameters:
     461. `entityID`: The unique identifier of the SP the end user is (or will be) interacting with, following successful authentication by an IdP.
     472. `return`: The SAML endpoint to return the user to after selecting an IdP. Since the central Discovery Service is not yet using the `idpdisc:DiscoveryResponse` element you have to put in the SAML metadata about your SP you distribute to the CLARIN SPF, this parameter is required (as described in the [https://www.oasis-open.org/committees/download.php/28049/sstc-saml-idp-discovery-cs-01.pdf Identity Provider Discovery Service Protocol and Profile]).
    6048
    61 [[Image(http://trac.clarin.eu/raw-attachment/wiki/ServiceProviderFederation/Discovery/disco-old.png, 600px)]]
     49An example when login in to the Component Registry [2]:
     50https://discovery.clarin.eu/discojuice?entityID=https%3A%2F%2Fsp.catalog.clarin.eu&return=https%3A%2F%2Fcatalog.clarin.eu%2FShibboleth.sso%2FLogin%3FSAMLDS%3D1%26target%3Dss%253Amem%253A602dd8144643cda1b50b0c5998caca437dffc418c6d9b184c6538faa996f49e4
    6251
    63 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.
     52As you can see there are no SAML statements included in the requests to or responses from the discovery service, just plain HTTP redirects.
    6453
    65 == New situation ==
     54== Maintenance Policy
    6655
    67 
    68 [[Image(http://trac.clarin.eu/raw-attachment/wiki/ServiceProviderFederation/Discovery/disco-new.png, 600px)]]
    69 
    70 To overcome the effects of maintenance on the running production service we propose the following setup (with options for more enhancements in the future).
    71 
    72 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.
    73 
    74 == Future possibilities ==
    75 
    76 The proposed setup can easily be improved by a number of steps:
    77  * Split the apache in tomcat instances over different (virtual) machines. Providing a working service if one of the tomcat machines would crash.
    78  * 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.
    79  * Configure load balancing from apache to the tomcat-instances.
    80  * Configure load balancing in front of the apache instances (e.g. use ultramonkey ).
    81 
    82 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.
    83 Maintenance Policy
    84 
    85 Next to the technical changes we would like to propose two policies to improve communication about maintenance.
    86 
    87  1. Maintenance on the WAYF and IDP services will be announced 1 week in advance on the (dev)mailing list.
    88  
     56 1. Maintenance on the WAYF and IdP services will be announced 1 week in advance on the (dev)mailing list.
    8957 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).
    90  
    91  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.