添加链接
link之家
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
相关文章推荐
伤情的匕首  ·  mysql 表名 ...·  10 月前    · 

Spring Security SAML Extension

Authors

Vladimír Schäfer

This chapter provides essential information needed to enable your application to act as a service provider and interact with identity providers using SAML 2.0 protocol. Later in this guide you can find information about detailed configuration options and additional use-cases enabled by this component.

This manual describes Spring Security SAML Extension component, its uses, installation, configuration, design and integration 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, Okta, Shibboleth, OpenAM, Efecte EIM 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:

Web single sign-on profile

Web single sign-on holder-of-key profile

IDP and SP initialized single sign-on

Single logout profile

Enhanced client/proxy profile

Identity provider discovery profile and IDP selection

Metadata interoperability and PKIX trust management

Automatic service provider metadata generation

Metadata loading from files, URLs, file-backed URLs

Processing and automatic reloading of metadata with many identity providers

Support for authentication contexts

Logging for authentication events

Customization of both SP and IDP metadata

Processing of SAML attributes and user data using UserDetails interface

Support for HTTP-POST, HTTP-Redirect, SOAP, PAOS and Artifact bindings

Easy integration with applications using Spring Security

Sample application with an user interface for quick configuration

You can use the following supported standards as a reference:

SAML 2.0 basic profiles

https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf

https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

https://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf

SAML 2.0 additional profiles

https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-holder-of-key-browser-sso.pdf

https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf

https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key.pdf

https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop.pdf

eGovernment profile https://kantarainitiative.org/confluence/download/attachments/42139782/kantara-egov-saml2-profile-2.0.pdf

Spring Security SAML Extension requires as a minimum Java 1.6 and is known to work with most Java containers and application servers. It can also be used with PaaS providers, such as Google App Engine, please see https://github.com/vschafer/spring-security-saml-gae for details.

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 https://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-Going-To-Be-Commons-SSL . Inside Spring SAML this library is only used for hostname verifications and will be removed in case OpenSAML removes the dependency.

2. What's new

This section contains overview of important changes for released versions of Spring SAML.

Version 1.0.1.FINAL is fully backwards compatible with 1.0.0.FINAL and contains the following changes:

  • Added support for Spring Security 4.0

  • Added integration guide with Okta

  • MaxAuthenticationAge time supports longer expiration times than 21 days

  • Deployment without JKS keystore is now supported

  • Service provider can now define multiple assertion consumer endpoints with same binding

  • Minor fixes and documentation improvements

Final release is not directly compatible with the previous RC versions, please make sure to migrate your code based on guidelines and changes below:

  • Metadata signing now supports custom keyInfoGenerator and signingAlgorithm, signing can be enable per-entity

  • SAMLContextProvider has new customization possibilities for PKIXTrustEvaluator, PKIXInformationResolver and MetadataResolver

  • CertPathPKIXTrustEvaluator supports customization of security provider and explicit validation of certification path

  • MetadataCredentialResolver can be configured to load data from XML metadata and/or ExtendedMetadata

  • PKIXInformationResolver has an extension point for population of CRLs

  • Improvements to logging and error handling, profile implementations now throw exceptions which are logged inside filter objects and fail with ServletExceptions, sample application newly shows handling of these errors

  • Used OpenSAML version was updated to 2.6.1

  • SAMLDefaultLogger now logs additional information such as NameID

  • Enabled propagation of defaults (e.g. ProxySettings) set in the HttpClient object for ArtifactResolution

  • JKSKeyManager now supports keystores without password

  • SAMLContextProviderLB now supports empty contextPath and includes pathInfo data for requests

  • Entity ID and EntityDescriptor ID can now be set separately in MetadataGenerator

  • ECP now takes precedence over discovery in SAMLEntryPoint

  • Signing of local metadata is now done before displaying, this enables manual modifications to metadata in local files

  • ArtifactResolutionProfileImpl now support customization of used SocketFactory through extensions

  • ID in generated metadata is now automatically created when null, ID is based on entityID cleaned in order to conform to xsd:ID (and xsd:NCName) type, EntityID is cleaned by replacing all illegal characters by underscores

  • Support for hostname verification in artifact resolution

  • Completed documentation

  • Possibility to exclude the SAML Credential from the Authentication object

  • Disabled deferred node expansion for ParserPool which improves performance in parsing of small XML documents

  • HttpSessionStorage is now cleared after successful reception of a message in order to save memory

  • Possibility to include attributes from only the authenticated Assertion, or from all

  • New socket factory for trust verification during loading of metadata from HTTPS

  • Possibility to disable support for IDP-initialized SSO

  • Usage of metadata alias is now optional

  • New look and feel of the sample application

  • Cleanup of duplicate values in MetadataGenerator and ExtendedMetadata

  • SAMLCredential now contains facility methods for handling of String SAML attributes

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

Module names

  • module saml2-core was renamed to core, jar and maven artifact names stay the same

  • module saml2-sample was renamed to sample, jar and maven artifact names stay the same

  • module src was renamed to docs, jar and maven artifact names stay the same

Descriptor securityContext.xml

  • file saml2-sample/src/main/resources/security/securityContext.xml was moved to sample/src/main/webapp/WEB-INF/securityContext.xml

  • administration part of the UI is now secured with username/password

  • updated initialization of ParserPool to disable defer node expansion

  • HttpClient in ArtifactResolution was made thread safe

  • added new failure handler (failureRedirectHandler)

  • MetadataGenerator bean now demonstrates usage of ExtendedMetadata

  • FilesystemMetadataProvider was replaced with ResourceBackedMetadataProvider

  • file sample/src/main/resources/security/idp.xml was moved to sample/src/main/resources/metadata/idp.xml

ArtifactResolutionProfileBase

  • throws SAMLException instead of CredentialExpiredException on check of artifact response issue instant

HttpSessionStorage

  • storage is now cleared on successful message reception

MetadataDisplayFilter

  • new mandatory property KeyManager (autowired)

MetadataGenerator

  • generated metadata is no longer signed by default (enable in ExtendedMetadata.signMetadata) and has disabled IDP discovery (enable in ExtendedMetadata.includeDiscovery)

  • the following fields were moved from MetadataGenerator to ExtendedMetadata:

    • entityAlias -> alias

    • signMetadata -> signMetadata

    • signingKey -> signingKey

    • encryptionKey -> encryptionKey

    • tlsKey -> tlsKey

    • includeDiscovery -> idpDiscoveryEnabled

    • customDiscoveryURL -> idpDiscoveryURL

    • customDiscoveryResponseURL -> idpDiscoveryResponseURL

  • removed methods signSAMLObject (moved to SAMLUtil) and getKeyInfoGeneratorName (moved to ExtendedMetadata)

  • by default the first binding is now HTTP-POST instead of HTTP-Artifact, endpoint for Web SSO no longer includes PAOS binding, set property bindingsSSO with values "artifact", "post", "paos" for backwards compatibility

  • by default endpoints for Web SSO holder of key are no longer included, set property bindingsHoKSSO with values "artifact" and "post" for backwards compatibility

  • by default MetadataGeneratorFilter no longer sets property entityAlias to value defaultAlias , set the value manually for backwards compatibility

SAMLAuthenticationProvider

  • property forcePrincipalAsString is now set to true by default

SAMLCredential

  • method getAttributeByName was renamed to getAttribute

SAMLDiscovery

  • fails with ServletException instead of SAMLRuntimeException

SAMLLogoutProcessingFilter

  • throws ServletException on errors during acceptance of LogoutRequest instead of SAMLRuntimeException

SAMLUtil

  • removed unused getDefaultBinding method

SingleLogoutProfileImpl

  • sendLogoutResponse signature changed

  • changed error handling, throws SAMLStatusException which is handled by Filter, logged and sends a SAML Response

WebSSOProfileImpl

  • throws SAMLException instead of SAMLRuntimeException on missing data in context

WebSSOProfileConsumerImpl

  • new property includeAllAttributes, set to true for original behavior

  • throws SAMLException instead of CredentialExpiredException on check of response issue instant and assertion issue instant

Table 3.1. Definitions of terms used within this manual

Term Definition
Assertion A part of SAML message (an XML document) which provides facts about subject of the assertion (typically about the authenticated user). Assertions can contain information about authentication, associated attributes or authorization decisions.
Artifact Identifier which can be used to retrieve a complete SAML message from identity or service provider using a back-channel binding.
Binding Mechanism used to deliver SAML message. Bindings are divided to front-channel bindings which use web-browser of the user for message delivery (e.g. HTTP-POST or HTTP-Redirect) and back-channel bindings where identity provider and service provider communicate directly (e.g. using SOAP calls in Artifact binding).
Discovery Mechanism used to determine which identity provider should be used to authenticate user currently interacting with the service provider.
Metadata Document describing one or multiple identity and service providers. Metadata typically includes entity identifier, public keys, endpoint URLs, supported bindings and profiles, and other capabilities or requirements. Exchange of metadata between identity and service providers is typically the first step for establishment of federation.
Profile Standardized combination of protocols, assertions, bindings and processing instructions used to achieve a particular use-case such as single sign-on, single logout, discovery, artifact resolution.
Protocol Definition of format (schema) for SAML messages used to achieve particular functionality such as requesting authentication from IDP, performing single logout or requesting attributes from IDP.
Identity provider (IDP) Entity which knows how to authenticate users and provides information about their identity to service providers/relaying parties using federation protocols.
Service provider (SP) Your application which communicates with the identity provider in order to obtain information about the user it interacts with. User information such as authentication state and user attributes is provided in form of security assertions.
Single Sign-On (SSO) Process enabling access to multiple web sites without need to repeatedly present credentials necessary for authentication. Various federation protocols such as SAML, WS-Federation, OpenID or OAuth can be used to achieve SSO use-cases. Information such as means of authentication, user attributes, authorization decisions or security tokens are typically provided to the service provider as part of single sign-on.
Single Logout (SLO) Process terminating authenticated sessions at all resources which were accessed using single sign-on. Techniques such as redirecting user to each of the SSO participants or sending a logout SOAP messages are typically used.
This chapter will guide you through steps required to easily integrate Spring Security SAML Extension with ssocircle.com's IDP service using SAML 2.0 protocol. When done you will have a working example of Web SSO against a single Identity Provider. The steps will guide you through deployment of the
sample application , configuration of IDP metadata (XML document describing how to connect to the IDP server using SAML 2.0 protocol) and SP metadata (XML document describing your own service) and testing of web single sign-on and single logout.

Public demo of the sample application is available at saml-federation.appspot.com

4.1 Pre-requisites

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

Java 1.6+ SDK

Apache Maven

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 https://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.

Download the Spring SAML Extension either from sources or from one of the releases .

The Spring SAML Sample application is included in sample directory. We will be customizing content of the sample application in the following steps.

Modify file sample/src/main/webapp/WEB-INF/securityContext.xml of the sample application and replace metadata bean as follows:

<bean id="metadata" class="org.springframework.security.saml.metadata.CachingMetadataManager">
	<constructor-arg>
			<bean class="org.opensaml.saml2.metadata.provider.HTTPMetadataProvider">
				<constructor-arg>
					<value type="java.lang.String">https://idp.ssocircle.com/idp-meta.xml</value>
				</constructor-arg>
				<constructor-arg>
					<value type="int">5000</value>
				</constructor-arg>
				<property name="parserPool" ref="parserPool"/>
			</bean>
		</list>
	</constructor-arg>
</bean>

The settings tell system to download IDP metadata from the given URL with timeout of 5 seconds. In production system metadata should be either stored as a local file or be downloaded from a source using SSL/TLS with configured trust or which provides digitally signed metadata.

Modify file sample/src/main/webapp/WEB-INF/securityContext.xml of the sample application, replace metadataGeneratorFilter bean as follows and make sure to replace the entityId value with a string which is unique within the SSO Circle service (e.g. urn:test:yourname:yourcity):

<bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
	<constructor-arg>
		<bean class="org.springframework.security.saml.metadata.MetadataGenerator">
			<property name="entityId" value="replaceWithUniqueIdentifier"/>
			<property name="extendedMetadata">
				<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
					<property name="signMetadata" value="false"/>
					<property name="idpDiscoveryEnabled" value="true"/>
				</bean>
			</property>
		</bean>
	</constructor-arg>
</bean>

When building from sources compile whole project and install artifacts into your local Maven repository using:

gradlew build install

When using the release zip compile the sample application available in the sample directory using:

mvn package

You can find the compiled war archive spring-security-saml2-sample.war in directory sample/build/libs/ (gradle) or sample/target/ (maven). Project files for your IDE can be created with gradlew eclipse or gradlew idea .

4.2.5 Deployment

You can start the application from the release sample directory using command:

mvn tomcat7:run

Same can be achieved using gradle with:

gradlew tomcatRun

After startup the Spring SAML sample application will be available at http://localhost:8080/spring-security-saml2-sample

Alternatively you can deploy the war archive to your application server or container.

Download current SP metadata: