This manual describes Spring Security SAML Extension component, its uses, installation, configuration, design and integartion possibilities.

The extension enables both new and existing applications to act as a Service Provider in federations based on Web Single Sign-On and Single Logout profiles of SAML 2.0 protocol. The extension allows seamless combination of SAML 2.0 and other authentication and federation mechanisms in a single application. All products supporting SAML 2.0 in Identity Provider mode (e.g. ADFS 2.0, Shibboleth, OpenAM/OpenSSO, RM5 IdM or Ping Federate) can be used with the extension.

The extension can also be used in applications which are not primarily secured using Spring Security. It can be adapted for both single and multi-tenant environments.

The extension can be either embedded inside your application and work along other authentication or single sign-on mechanisms, or it can be deployed separately and convey authentication information to applications using a custom mechanism.

The extension is probably the most complete open-source SAML 2.0 SP implementation with the widest feature-set and configuration possibilities. Other Java open-source alternatives are e.g. native SAML service providers integrating with IIS or Apache from Shibboleth (SAML processing is done on the web server and not on the application level) or OpenAM Fedlet.

Current implementation should be conformant to SAML SP Lite and SAML eGovernment profile. The following profiles, bindings and features are supported as part of the product:

You can use the following supported standards as a reference:

SAML 2.0 basic profiles

SAML 2.0 additional profiles

eGovernment profile

Spring Security SAML Extension requires as a minimum Java 1.6 and is known to work with most Java containers and application servers.

Source code for the project is maintained on Github.

Snapshot builds of the project are available in the SpringSource repository. We use Bamboo for continuous integration.

Source code of the module is licensed under the Apache License, Version 2.0. You may obtain copy of the license at http://www.apache.org/licenses/LICENSE-2.0.

Please use Spring Security Extensions Jira for submitting of bugs and feature requests. Patches can be sent directly to GitHub as pull requests, but preferably open a Jira issue as well.

Please send your pull requests directly to GitHub and preferably also open issue in Jira.

For commercial support and consulting services please contact [email protected]

For community support please use Stack Overflow. The Spring Security forums contain some previously answered questions, but are now in read-only mode.

Internal processing of SAML messages, marshalling and unmarshalling is handled by OpenSAML.

Spring SAML has a transitive dependency to library not-yet-commons-ssl. Inside Spring SAML this library is only used for hostname verifications and will be removed in case OpenSAML removes the dependency.

Below is an overview of major changes since Spring SAML 1.0 RC2.

Below is an overview of major code and structure changes since Spring SAML 1.0 RC2 with possible effect on backwards compatibility.

Module names

Descriptor securityContext.xml

ArtifactResolutionProfileBase

HttpSessionStorage

MetadataDisplayFilter

MetadataGenerator

SAMLAuthenticationProvider

SAMLCredential

SAMLDiscovery

SAMLLogoutProcessingFilter

SAMLUtil

SingleLogoutProfileImpl

WebSSOProfileImpl

WebSSOProfileConsumerImpl

Please make sure the following items are available before starting the installation:

SAML Extension relies on XML processing capabilities of JAXP. Some older versions of JRE might require updating of the embedded JAXP libraries. In case you encounter XML processing exceptions please create folder jdk/jre/lib/endorsed in your JDK installation and include files in lib/endorsed from the latest OpenSAML archive available at http://shibboleth.net/downloads/java-opensaml/. The location of the endorsed folder may differ based on your application server or container.

Due to US export limitations Java JDK comes with a limited set of cryptography capabilities. Usage of the SAML Extension might require installation of the Unlimited Strength Jurisdiction Policy Files which removes these limitations.

Open the front page of your SP application, select http://idp.ssocircle.com IDP and press login. The system will generate a new authentication request using SAML 2.0 protocol, digitally sign it and send it to the IDP. After authentication at IDP with your account you will be redirected back to your application and automatically signed-in.

Pressing local logout will destroy local session and logout the user. While a session is still active at the IDP an attempt to reauthenticate will proceed without need to enter credentials.

Pressing global logout will destroy both local session and the session at IDP.

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

<dependency>
	<groupId>org.springframework.security.extensions</groupId>
	<artifactId>spring-security-saml2-core</artifactId>
	<version>${version}</version>
</dependency>

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.

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:annotation-config/>
<context:component-scan base-package="org.springframework.security.saml"/>

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.

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"/>
</security:http>

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:

<error-page>
	<exception-type>javax.servlet.ServletException</exception-type>
	<location>/error.jsp</location>
</error-page>

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.

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:

<dependency>
	<groupId>org.slf4j</groupId>
	<artifactId>slf4j-log4j12</artifactId>
	<version>1.6.3</version>
	<scope>compile</scope>
</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:

log4j.logger.org.springframework.security.saml=DEBUG
log4j.logger.org.opensaml=DEBUG
log4j.logger.PROTOCOL_MESSAGE=DEBUG

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

Service provider metadata contains keys, services and URLs defining SAML endpoints of your application. Metadata can be either generated automatically upon first request to the service, or it can be pre-created (see Chapter 11, Sample application). Once created metadata needs to be provided to the identity providers with whom we want to establish trust.

<security:custom-filter before="FIRST" ref="metadataGeneratorFilter"/>

<bean class="org.springframework.security.saml.metadata.MetadataGenerator">
	<property name="bindingsSSO"><list><value>artifact</value></list></property>
	<property name="bindingsSLO"><list><value>redirect</value></list></property>
	<property name="bindingsHoKSSO"><list/></property>
</bean>

https://www.server.com:8080/context/saml/metadata

https://www.server.com:8080/context/saml/login/alias/defaultAlias

Metadata for identity providers is imported to the metadataManager in a similar way as pre-configured SP metadata. Metadata containing one or many identity providers can be added by providing an URL or a file. Processing of metadata and processing of SAML messages can be customized using properties of ExtendedMetadataDelegate and ExtendedMetadata.

<bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
	<constructor-arg>
		<bean class="org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider">
			<constructor-arg>
				<value type="java.io.File">classpath:security/idp.xml</value>
			</constructor-arg>
			<property name="parserPool" ref="parserPool"/>
		</bean>
	</constructor-arg>
	<constructor-arg>
		<bean class="org.springframework.security.saml.metadata.ExtendedMetadata"/>
	</constructor-arg>
</bean>

<bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
	<constructor-arg>
		<bean class="org.opensaml.saml2.metadata.provider.HTTPMetadataProvider">
			<constructor-arg>
				<value type="java.lang.String">http://idp.ssocircle.com/idp-meta.xml</value>
			</constructor-arg>
			<constructor-arg>
				<!-- Timeout for metadata loading in ms -->
				<value type="int">5000</value>
			</constructor-arg>
			<property name="parserPool" ref="parserPool"/>
		</bean>
	</constructor-arg>
	<constructor-arg>
		<bean class="org.springframework.security.saml.metadata.ExtendedMetadata"/>
	</constructor-arg>
</bean>

<bean class="org.springframework.security.saml.trust.httpclient.TLSProtocolConfigurer"/>

Extended metadata provides additional settings for customization of SAML exchanges between SP and IDP which are not supported in the standard SAML 2.0 metadata documents. Examples of such settings are requirements for message signing, IDP discovery and security profiles.

Extended metadata is defined using org.springframework.security.saml.metadata.ExtendedMetadata beans embedded inside ExtendedMetadataDelegate for each SP or IDP metadata definition. In case a single metadata document contains multiple identity providers (in multiple EntityDescriptor elements), extended metadata can be set separately for each of them using a map with entity IDs as keys, e.g.:

<bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
	<constructor-arg>
		metadata provider bean
	</constructor-arg>
	<constructor-arg>
		<!-- Default extended metadata for entities not specified in the map -->
		<bean class="org.springframework.security.saml.metadata.ExtendedMetadata"/>
	</constructor-arg>
	<constructor-arg>
		<!-- Extended metadata for specific IDPs -->
		<map>
			<entry key="http://idp.ssocircle.com">
				<bean class="org.springframework.security.saml.metadata.ExtendedMetadata"/>
			</entry>
		</map>
	</constructor-arg>
</bean>

The following table summarizes settings available in the extended metadata. The same class is used for both local service providers and remote identity providers; each value contains information about the entities it's valid for.

For additional examples on setting up metadata and extended metadata see Section 7.1, “Service provider metadata” for local SP, and Section 7.2, “Identity provider metadata” for remote IDPs.

Spring SAML contains limited support for multi-tenancy. It is possible to define configuration for multiple instances of local service providers, where each can have different URLs and security settings. System is differentiating between the service provider instances using entity alias which is a unique identifier within deployment of Spring SAML.

Entity alias is appended to URLs of SAML endpoints and used by Spring SAML to identify the correct instance. For example for local service provider with entity alias customer123 the standard URL scheme://server:port/contextPath/saml/login becomes scheme://server:port/contextPath/saml/login/alias/customer123.

The entity alias functionality can only be used together with pre-configured metadata (see Section 7.1.2, “Pre-configured metadata”). The entity alias is specified in the extended metadata of each of the configured service providers.

Spring SAML doesn't enforce any limitations on which Identity Provider can be deliver messages to which of the local Service Providers. In case your application requires similar rules (for example only certain tenants can authenticate using a specific IDP), make sure to implement them for example in your SAMLUserDetailsService (for single sign-on).

Selection of the correct Service Provider instance based on URL is performed inside SAMLContextProviderImpl class.

SAML exchanges involve usage of cryptography for signing and encryption of data. All interaction with cryptographic keys is done through interface org.springframework.security.saml.key.KeyManager. The default implementation relies on a single JKS key store which contains all private and public keys. KeyManager must contain at least one private key which should be marked as default by using the alias of the private key as part of the KeyManager constructor.

Make sure that your configuration of SAML module contains bean keyManager with your custom key store and passwords.

<bean id="keyManager" class="org.springframework.security.saml.key.JKSKeyManager">
	<constructor-arg value="classpath:security/samlKeystore.jks"/>
	<constructor-arg type="java.lang.String" value="nalle123"/>
	<constructor-arg>
	<map>
		<entry key="apollo" value="nalle123"/>
	</map>
	</constructor-arg>
	<constructor-arg type="java.lang.String" value="apollo"/>
</bean>

keytool -genkeypair -alias some-alias -keypass changeit -keystore samlKeystore.jks

keytool -importkeystore -srckeystore key.p12 -srcstoretype PKCS12 -srcstorepass password \
	-alias some-alias -destkeystore samlKeystore.jks -destalias some-alias \
	-destkeypass changeit

keytool -list -keystore key.p12 -storetype pkcs12

keytool -importcert -alias some-alias -file key.cer -keystore samlKeystore.jks

java -jar sslextractor-0.9.jar www.google.com 443

Exchanges of messages between identity providers and service providers with SAML protocol involves usage of digital signatures. Signatures are typically constructed using means of asymetric cryptography and public key infrastructure with public and private keys signed by trusted certification authorities. Signatures are either applied directly to parts of XML representation of SAML messages using XML Signature or are part of the transport layer used to deliver the message like SSL/TLS.

Verification of signatures is executed in two phases. Signature is first checked for validity by comparing digital hash included as part of the signature with value calculated from the content. Subsequently it is verified whether party who created the signature is trusted by the recipient. Spring Security SAML provides two mechanisms for defining which signatures should be accepted - metadata interoperability mode and PKIX mode.

Security profiles are defined in Extended Metadata of your local SP. Profile can be defined separately for XML Signatures using property securityProfile and for SSL/TLS Signatures using propertysslSecurityProfile. Value of both properties can be either metaiop or pkix. For details about using Extended Metadata see Chapter 7, Metadata configuration, for reference of allowed values see Section 7.3, “Extended metadata”.

<bean id="contextProvider" class="org.springframework.security.saml.context.SAMLContextProviderImpl">
	<property name="metadataResolver">
		<bean class="org.springframework.security.saml.trust.MetadataCredentialResolver">
			<constructor-arg index="0" ref="metadata"/>
			<constructor-arg index="1" ref="keyManager"/>
			<property name="useXmlMetadata" value="false"/>
		</bean>
	</property>
</bean>

<bean id="contextProvider" class="org.springframework.security.saml.context.SAMLContextProviderImpl">
	<property name="pkixTrustEvaluator">
		<bean class="org.springframework.security.saml.trust.CertPathPKIXTrustEvaluator">
			<property name="PKIXValidationOptions">
				<bean class="org.opensaml.xml.security.x509.CertPathPKIXValidationOptions">
					<property name="forceRevocationEnabled" value="true"/>
					<property name="revocationEnabled" value="true"/>
				</bean>
			</property>
			<property name="validateCertPath" value="true"/>
			<property name="securityProvider" value="SUN"/>
		</bean>
	</property>
</bean>

Connections to HTTPS services (e.g. during Artifact resolution) require verification that the connected hostname corresponds with the hostname defined in the service's public certificate. Hostname verification is enabled by default.

Verification can be disabled by setting ExtendedMetadata property sslHostnameVerification of the local SP entity to allowAll. For details on using the ExtendedMetadata see Section 7.3, “Extended metadata”.

All supported values can be found in the ExtendedMetadata reference Section 7.3, “Extended metadata”.

Discovery helps your Service Provider determine which Identity Provider should be used for authentication of the current user. It is automatically initialized during calls to single sign-on endpoint at scheme://server:port/contextPath/saml/login. SAML Extension supports multiple modes of discovery including the Identity Provider Discovery Service Protocol and Profile.

IDP discovery modes can always be skipped during SSO initialization by specifying HTTP request parameter idp with the entityId of the required IDP, e.g. scheme://server:port/contextPath/saml/login?idp=mySelectedIDP.

The URL where local SP expects discovery response can be included in the SP metadata as one of the extensions. The feature can be enabled by setting property includeDiscoveryExtension to true on bean MetadataGenerator inside MetadataGeneratorFilter, e.g.:

<bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
	<constructor-arg>
		<bean class="org.springframework.security.saml.metadata.MetadataGenerator">
			<property name="includeDiscoveryExtension" value="true"/>
		</bean>
	</constructor-arg>
</bean>

Spring SAML Extension supports both SP-initialized and IDP-initialized single sign-on.

<bean id="samlEntryPoint" class="org.springframework.security.saml.SAMLEntryPoint">
	<property name="defaultProfileOptions">
		<bean class="org.springframework.security.saml.websso.WebSSOProfileOptions">
			<property name="binding" value="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
			<property name="includeScoping" value="false"/>
		</bean>
	</property>
</bean>

Spring SAML Extension supports both Local Logout and Single Logout mechanisms.

<security:http>
	<security:logout logout-url="/j_logout" logout-success-url="/logout.jsp"/>
</security:http>

Successful authentication using SAML token results in creation of an Authentication object by the SAMLAuthenticationProvider. By default instance of org.springframework.security.providers.ExpiringUsernameAuthenticationToken is created. Content of the resulting object can be customized by setting properties of the samlAuthenticationProvider bean in the securityContext.xml. An instance of org.springframework.security.saml.userdetails.SAMLUserDetailsService can be provided to supply application-specific information about the authenticated user.

The Authentication object will by default include string version of the NameID included in the SAML Assertion as itsprincipal. Property forcePrincipalAsString can be used to change this to include the raw NameID element.

The Authentication object is available in pages secured with Spring Security using SecurityContextHolder.getContext().getAuthentication() and is populated with the following values:

Custom implementation of the SAMLUserDetailsService can be provided as property userDetails of the SAMLAuthenticationProvider. Implementation can perform operation such as parsing of attributes present in the SAML Assertion, e.g.:

package fi.schafer.test.saml;

import org.opensaml.saml2.core.Attribute;
import org.opensaml.xml.XMLObject;
import org.springframework.security.core.userdetails.UsernameNotFoundException;
import org.springframework.security.saml.SAMLCredential;
import org.springframework.security.saml.userdetails.SAMLUserDetailsService;

public class TestUserDetails implements SAMLUserDetailsService {
	@Override
	public Object loadUserBySAML(SAMLCredential cred) throws UsernameNotFoundException {
		return cred.getAttributeAsString("accountID");
	}
}

Population of the authentication object can be further customized by overriding of the getUserDetails, getPrincipal, getEntitlements and getExpirationDate methods in the SAMLAuthenticationProvider.

Key events such as single sign-on and single logout initialization, success or failure can be logged for creation of an audit trail. A custom logger can be created by implementing interface org.springframework.security.saml.log.SAMLLogger and including its bean in the securityContext.xml, e.g.:

<bean id="samlLogger" class="org.springframework.security.saml.log.SAMLDefaultLogger"/>

Two basic implementations are provided by default:

The logger is only called for messages which can be correctly received and parsed. For errors which occur before correct parsing see Section 6.5, “Error handling”.

SAML Extension can be deployed in scenarios where mutliple back-end servers process SAML requests forwarded by a reverse-proxy or a load balancer. SSL termination proxies which communicate using an unencrypted channel between the proxy and back-end servers are also supported. In order to configure SAML Extension for deployment behind a load balancer or a reverse-proxy please follow these steps:

Context provider populates information about the local service provider (your application) such as entityId, role, metadata, security keys, SSL credentials and trust engines for verification of signatures and SSL/TLS connections. Once populated context is made available to all components participating in processing of the incoming or outgoing SAML messages. ContextProvider can customized to alter behavior of the SAML Extension. The default implementation org.springframework.security.saml.context.SAMLContextProviderImpl relies on information available in the ExtendedMetadata and performs the following steps for creation of the context:

During initialization of SSO ContextProvider is also requested to provide metadata of the peer IDP. System performs these steps to locate peer IDP to use:

For security reasons system limits the time window enabling processing of SAML messages and assertions. The time window parameters can be customized with the following settings.

Validity of assertions processed during the signle sign-on process is limited to 3000 seconds. Value can be customized with property maxAssertionTime of the WebSSOProfileConsumerImpl bean.

System allows users to single sign-on for up to 7200 seconds since their initial authentication with the IDP (based on value AuthInstance of the Authentication statement). Some IDPs allow users to stay authenticated for longer periods than this and you might need to change the default value by setting maxAuthenticationAge of the WebSSOProfileConsumerImpl bean.

As clocks between IDP and SP machines may not be perfectly synchronized a tolerance of 60 seconds is applied for time comparisons. The tolerance value (time skew) can be customized by settings property responseSkew in beans WebSSOProfileConsumerImpl and SingleLogoutProfileImpl.

The following tables summarize all checks for time validity during processing of incoming SAML messages. Response skew refers to property responseSkew set on profile beans. Past indicates that validity window for checking of the value will be extended by responseSkew seconds to the past and correspondingly with the future value. Nullable values can be missing from the incoming messages.

Support for enhanced client/proxy can be configured using property ecpEnabled of the service provider's extended metadata. Once enabled, ECP profile is automatically activated with requests containing HTTP headers Accept: application/vnd.paos+xml and PAOS: ver='urn:liberty:paos:2003-08'; 'urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp'. Binding used to server ECP profile is always automatically set to PAOS.

ECP can be enabled in combination with the automatic metadata generation using the following settings:

<bean class="org.springframework.security.saml.metadata.MetadataGenerator">
	<property name="extendedMetadata">
		<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
			<property name="ecpEnabled" value="true"/>
		</bean>
	</property>
</bean>

By default Spring SAML uses the following endpoints, which can optionally also contain information about entity alias of the local Service Provider:

The default URLs can be altered with these steps:

Endpoints of filters samlEntryPoint, samlLogoutFilter and metadataDisplayFilter can be changed using the same process and without need to re-generate the metadata.

Usage of HTTP-Artifact binding requires Spring SAML to make a direct SOAP call to the Identity Provider. Sometimes it's necessary to configure correct HTTP proxy for the call. This can be achieved by setting property hostConfiguration on HttpClient plugged to the artifactBinding bean. The following configuration demonstrates creation of the bean for the hostConfiguration:

<bean id="hostConfiguration" class="org.apache.commons.httpclient.HostConfiguration"/>
<bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
	<property name="targetObject" ref="hostConfiguration"/>
	<property name="targetMethod" value="setProxy"/>
	<property name="arguments">
		<list>
			<value>testHost</value>
			<value>8080</value>
		</list>
	</property>
</bean>

Another common use-case is situation when artifact resolution endpoint at IDP is secured using HTTP-Basic authentication. Authentication can be configured by setting HTTPClient's property state with the following bean:

<bean id="state" class="org.apache.commons.httpclient.HttpState"/>
<bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
	<property name="targetObject" ref="state"/>
	<property name="targetMethod" value="setCredentials"/>
	<property name="arguments">
		<list>
			<util:constant static-field="org.apache.commons.httpclient.auth.AuthScope.ANY"/>
			<bean class="org.apache.commons.httpclient.UsernamePasswordCredentials">
				<constructor-arg value="username"/>
				<constructor-arg value="password"/>
			</bean>
		</list>
	</property>
</bean>

Sample application demonstrates usage of IDP discovery which is automatically invoked on access to the application root. Discovery presents selection of all available Identity Providers and initiates SAML 2.0 single sign-on with the selected IDP after clicking on the "Start single sign-on" button.

After authentication at IDP, sample application displays information about the received and validated assertion, or displays errors encountered during validation.

Clicking buttons "Global Logout" and "Local Logout" initializes the logout process as described in Section 9.3, “Logout process”.

Sample application contains an administration UI which enables simple monitoring and administrative use-cases. You can access the UI by clicking on "Metadata Administration" button.

Administration part is secured with role ROLE_ADMIN and uses local authentication with default username admin and password admin. As Spring Security allows only one authentication to be currently active, authenticating to administration UI will remove any previous SAML authentication from the security context.

Metadata administration enables the following operations:

Metadata generator allows dynamic creation of service provider metadata based on values provided in the UI. Metadata can be immediately applied to the currently running instance by setting "Store for current session" option to "Yes".

Options available in the interface are discussed in Section 7.1.1, “Automatic metadata generation” and Section 7.3, “Extended metadata”. The generated values can be used as input for pre-configured metadata described in Section 7.1.2, “Pre-configured metadata”.

Open the sample at e.g. https://localhost:8443/spring-security-saml2-sample, select your AD FS server and press login. In case Artifact binding is used and SSL/TLS certificate of your AD FS is not already trusted, import it to your samlKeystore.jks by following instructions in the error report.