Shibboleth/SAML SSO Integration

Introduction

Goal

Integrate Hippo CMS with the Sibboleth single sign-on solution.

Background

Shibboleth is a single sign-on (SSO) solution for computer networks and the internet. It allows people to sign in, using just one 'identity', to various systems run by 'federations' of different organizations or institutions.

This page describes how Hippo CMS can be integrated with Shibboleth and how internal components interact with each other.

Deployment View

The following deployment diagram shows a possible system architecture in which Hippo integrates with Shibboleth SSO:

• Browser Client attempts to access the WCMS system through the web URLs served by the frontend Web Server (typically Apache httpd).

• Web Server has authentication configuration for secured resources (e.g., /cms, /site/secured/articles/, etc.) with Shibboleth authentication option. For the Shibboleth authentication option, the Web Server invokes mod_shib2 module which is deployed onto the server.

• The mod_shib2 module communicates with Shibboleth Daemon to request authentication through either Unix socket or TCP socket based on configuration.

• Shibboleth Daemon may initiate user sessions, manage the sessions for the specified time duration, let Browser Client be redirected to the Shibboleth Identity Provider, and provide authentication information environment variables or http headers. Shibboleth Identity Provider is normally deployed centrally in the enterprise, and so WCMS system should normally be configured to access remote Shibboleth Identity Provider through Shibboleth Damon.

• Shibboleth Daemon is configured by shibboleth2.xml. Because the authentication information should be used in Java Applications connected through either mod_proxy or mod_jk2, Shibboleth Daemon should be configured to leave the authentication information as HTTP Headers.

• For authenticated user session, Web Server will serve Java Web Applications (e.g., Authoring and Delivery applications) hosted by the Application Server (typically Tomcat) which is connected by either mod_proxy or mod_jk2.

• The Authoring and Delivery applications can be configured with Spring Security Framework enabled. Spring Security Framework can read the pre-authenticated HTTP Header, which is provided by Shibboleth Daemon, and it can build a user principal based on the pre-authenticated HTTP Header. The Authoring and Delivery applications should be configured to use the user principal provided by the Spring Security, instead of trying to authenticate the user by themselves.

• The Authoring application should be configured to synchronize the user data from the LDAP Server.

Components and Connectors View

On the core components and connectors:

• The web server httpd authenticates the secured resources by mod_shib2 module, which invokes Shibboleth Daemon. Shibboleth Daemon may communicate with Enterprise Shibboleth Identity Provider via SAML/HTTPS.

• If the user is successfully authenticated by the handshakes between Client Browser and Shibboleth Identity Provider, then httpd will do a reverse proxy to the application server Tomcat.

• If the user is authenticated at the httpd level by mod_shib2 module and Shibboleth Daemon, then it is regarded as “pre-authenticated” state from the viewpoint of Java Web Applications on Tomcat.

• Spring Security Framework Filter initializes proper user principal based on the pre-authenticated user information, which should be provided by HTTP Header. The components initializing the pre-authenticated user detail can be easily customized. See Shibboleth Integration With Spring Security - AAF Mini Grants for an example.

• Now the Delivery Application can use the initialized user principal on serving secured page resources.

• Also the Authoring Application can create a user JCR session based on the initialized user principal.