A user wants to authenticate.

1. The user click on the "shibboleth login"
2. Authentication check:
   a. If the user is already authenticated at shibboleth level, it will be logged into GN without asking for the credentials and be redirected to the main page.
   b. If the user is not authenticated, it is redirected to the central auth service.
3. If proper credentials are given, the user is brought back to the GeoNetwork main page as an authenticated user.

User accesses a URL that needs authentication.

a. If the user is already authenticated at shibboleth level, it will be logged into GN and the resource at the given URL will be automatically opened.

b. If the user is not authenticated, it is redirected to the central auth service. Once authenticated, it is redirected to the requested URL.

1. The "shibboleth login" link points to the path /shib.user.login.

2. browser requests the /shib.user.login service

3. apache mod_shib intercepts the call, redirects the browser to the central auth page, and then:

   3a. if user is not yet authenticated, ask for credentials - if credentials are ok, proceed like 3b - if credentials are not ok, return to home page as a guest

   3b. if user is auth, call /shib.user.login service on GN, passing the proper headers

4. The /src/???/shib.user.login pattern is matched by Spring security, and the filter chain including the shibbolethPreAuthFilter filter is executed. This filter will check the headers, and will handle the user inside GN (user creation and GN session setup).

5. The service shib.user.login, which does nothing, is called, and then it's forwarded to the home service as per definition in jeeves. (? check this)

1. User requests a protected page.
2. Spring finds that this is a page that needs authentication. If the user is not authenticated yet, the original request is saved by the exceptionTranslationFilter.
3. Spring uses the shib overridden authenticationEntryPoint bean that redirects to /srv/ita/shib.user.login
4. Flow proceeds as in use case A)
5. the shibbolethPreAuthFilter creates the user session; it then checks if there is any original request saved. If there is, a REDIRECT is issued toward the original URL.
6. the user is now accessing the procted page with its authenticated session.

These are the involved files:

• web/src/main/java/org/fao/geonet/services/login/ShibLogin.java
  Old login service, now it does nothing.

• web/src/main/java/org/fao/geonet/kernel/security/shibboleth/ShibbolethPreAuthFilter.java
  A preauthorization filter that handles the shibboleth headers and GN login procedure. Also handles redirection to the originally requested page.

• web/src/main/webapp/WEB-INF/config-security.xml
  This file is used for including (optionally) the security config files needed for the specific deploy. Options (CAS, LDAL, etc) are included by decommenting some import directives.
  The same modality will be used for configuring the shibboleth authentication.

• web/src/main/webapp/WEB-INF/config-security-shibboleth.xml
  Instantiates the shibboleth preauth filter and related filter chain.

• WEB-INF/config-security-shibboleth-overrides.properties
  Optional file, needed to map the shibboleth IdP headers.
  Please note that at spring level the GeoNetwork own settings are not available, so the shibboleth header names will have to be set in this property file, and the values on the administration UI are no longer used.

• web/src/main/webapp/WEB-INF/config-security-core.xml
  Here are some of the beans that are overridden by Shibboleth-related ones.

You need to have your shibboleth IdP already deployed and configured.

What you need to do on your side is to protect the access of the /geonetwork/srv/[a-z]{2,3}/shib.user.login path using apache module mod_shib

   <Location ~ /geonetwork/srv/.../shib\.user\.login>
      AuthType shibboleth
      ShibRequireSession on
      require valid-user
   </Location>

In order to enable Shibboleth authentication on GN you will have to:

1. edit file web/src/main/webapp/WEB-INF/config-security.xml and uncomment the import for the file config-security-shibboleth.xml;
2. edit file config-security-shibboleth-overrides.properties and set the header names used in your configuration;
3. on the UI administration page, enable the "Shibboleth autentication" checkbox. This is used to make the client side aware that some control related to shibboleth auth should be visualized. You don't need to enter the shibboleth info such as "Path" and attribute mapping on the GUI.

The changes in the configuration files will:

1. replace the preAuthFIlter with the one which performs SHibboleth authentication.

• This current implementation needs to know about shibboleth HTTP header names using a property file. This means that the values set in the UI (administration/system configuration/shibboleth) will not be used.