Shibboleth/SAML SSO Integration

Overview

This page explains how to integrate Bloomreach Content with Shibboleth for single sign-on (SSO) using SAML. It describes the system architecture, component interactions, and integration points between Bloomreach Content and Shibboleth.

Note: Refer to the Shibboleth documentation for additional details about Shibboleth configuration and operation.

Architecture

System Deployment

The following deployment diagram illustrates how Bloomreach Content connects with Shibboleth SSO in a typical environment:

Diagram Description:
The diagram shows a Browser Client accessing a WCMS environment over HTTP/S. The WCMS environment includes a Web Server, Application Server, and Shibboleth Daemon.

• The Web Server deploys the mod_shib2 module.
• The Shibboleth Daemon uses the shibboleth2.xml configuration.
• The Application Server hosts two WAR modules: Authoring and Delivery.
• Both WAR modules are integrated with Spring Security.
• An external Enterprise Federated Security Resources area contains a Shibboleth Identity Provider and an LDAP Server.
• SAML/HTTPS is used for communication between the WCMS and the Identity Provider.

Key interactions in this architecture:

• The Browser Client requests access to the WCMS through URLs served by the Web Server (typically Apache httpd).
• The Web Server is configured to secure resources (such as /cms or /site/secured/articles/) using Shibboleth authentication. It invokes the mod_shib2 module for this purpose.
• The mod_shib2 module communicates with the Shibboleth Daemon over a Unix or TCP socket, depending on configuration.
• The Shibboleth Daemon manages user sessions, redirects the browser to the Shibboleth Identity Provider for authentication, and provides authentication data via environment variables or HTTP headers. The Identity Provider is usually managed centrally within the enterprise.
• The Shibboleth Daemon is configured using shibboleth2.xml. To allow Java applications to access authentication data, configure the daemon to expose this information as HTTP headers.
• For authenticated sessions, the Web Server proxies requests to Java web applications (Authoring and Delivery) hosted on the Application Server (typically Tomcat) using either mod_proxy or mod_jk2.
• The Authoring and Delivery applications use the Spring Security Framework. Spring Security reads the pre-authenticated HTTP headers set by the Shibboleth Daemon and creates a user principal based on this data. These applications must rely on the user principal provided by Spring Security and should not implement their own authentication logic.
• The Authoring application should synchronize user data with the LDAP Server.

Component and Connector Details

Diagram Description:
The diagram outlines the main components in a Shibboleth/SAML SSO setup:

• The httpd web server uses mod_shib2 for authentication, which connects to the Shibboleth Daemon and then to the Shibboleth Identity Provider over SAML/HTTPS.
• The httpd server also uses mod_proxy to reverse proxy requests to Tomcat.
• Tomcat is protected by a Spring Security Filter, which connects to a PreAuthenticatedAuthenticationProvider and to the Delivery and Authoring Applications.

Component interactions:

• The httpd web server secures resources using the mod_shib2 module, which delegates authentication to the Shibboleth Daemon. The daemon communicates with the enterprise Shibboleth Identity Provider using SAML over HTTPS.
• When authentication succeeds between the Browser Client and the Shibboleth Identity Provider, httpd proxies the request to the Tomcat application server.
• Once authenticated at the httpd level, the user is considered "pre-authenticated" from the perspective of Java web applications on Tomcat.
• The Spring Security Filter in the application server initializes a user principal based on the pre-authenticated user information provided in HTTP headers. You can customize the components that process this pre-authenticated data. For implementation examples, see Shibboleth Integration With Spring Security - AAF Mini Grants.
• The Delivery Application uses the initialized user principal to serve secured resources.
• The Authoring Application uses the user principal to create a JCR session for the authenticated user.

Summary

Integrating Bloomreach Content with Shibboleth SSO enables centralized authentication using SAML. The integration relies on the web server, Shibboleth Daemon, and Spring Security to propagate authentication state from the Identity Provider to the Bloomreach applications. Configuration focuses on passing authentication data via HTTP headers and ensuring the Java applications use the provided user principal for authorization and session management.