6. Integration to applications

SAML module can be directly embedded into new or existing Spring applications. In this case application itself includes the SAML library in WEB-INF/lib directory of the war archive and processes all SAML interactions. The other option of using the SAML library is deploying it as a stand-alone module which transfers information about the authenticated user to the target application using a custom mechanism. This chapter only discusses the first option.

6.1 Maven dependency

In order to include the library and all its dependencies add the following dependency to your pom.xml file:


The current version of SAML Extension has been tested to work with Spring 3.1.2, Spring Security 3.1.2 and OpenSAML 2.6.1. Later versions of these libraries are likely to be compatible without need for modifications.

6.2 Bean definitions

Configuration of the SAML library requires beans definitions included in the sample/src/main/webapp/WEB-INF/securityContext.xml configuration file. Include copy of the file in your own Spring application, either directly or with an inclusion. Configuration steps in the following chapters will be customizing beans included in the default context.

Beans of the SAML library are using auto-wiring and annotation-based configuration by default. Make sure that your Spring configuration contains e.g. the following settings in order to enable support for these features:

<context:component-scan base-package="org.springframework.security.saml"/>

6.3 Java-based configuration

Spring SAML will include configuration classes for Spring Java-based configuration in future versions.

For an example of securityContext.xml translated into Java configuration in a Spring Boot application see project by Vincenzo De Notaris at https://github.com/vdenotaris/spring-boot-security-saml-sample.

6.4 Spring Security integration

Filters of the SAML module need to be enabled as part of the Spring Security settings. In case SAML authentication should be the default authentication mechanism of the application set bean samlEntryPoint as the default entry point. Make sure that filter samlFilter is included as one of the custom filters. In case SP metadata should be generated automatically during first request to the application include also filter metadataGeneratorFilter. The configuration directive may for example look as follows:

<security:http entry-point-ref="samlEntryPoint">
	<security:custom-filter before="FIRST" ref="metadataGeneratorFilter"/>
	<security:custom-filter after="BASIC_AUTH_FILTER" ref="samlFilter"/>

6.5 Error handling

Critical errors raised during processing of SAML messages are generally propagated as ServletExceptions to the Java container. In order to configure a custom error handling update your web.xml and provide a general handler for ServletExceptions:


ServletException contains original reason for the failure as a cause. It is recommended that content of the exceptions is not displayed to end users, both for security and user experience reasons.

Errors produced during processing of the SAML AuthenticationResponse can be handled by plugging a custom implementation of the org.springframework.security.web.authentication.AuthenticationFailureHandler interface to the samlWebSSOProcessingFilter bean.

6.6 Logging

SAML Extension uses SLF4J framework for logging. The same applies to the underlaying OpenSAML library. The sample application by default uses log4j version 1.2 binding for SLF4J, configured with the following dependency:


In case you are using another logging library, make sure to change the dependency accordingly.

You can enable debug logging by modifying file sample/src/main/resources/log4j.properties and adding:


For details about using other logging frameworks please consult the SLF4J manual.