The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Current »

The <md:AssertionConsumerService> element is used to configure handlers that are responsible for consuming SAML assertions; that is, they process an assertion according to a profile, extract its contents, create a new user session, and typically produce a cookie to represent the session.

This is an advanced configuration feature. Most deployments can rely on the <SSO> shorthand element.

An ACS does most of the work of SSO for the SP and is the "receiving" half of the SSO message exchange started by a SessionInitiator. As a multi-protocol system, the SP itself is oblivious to specific SSO protocols; each ACS provides the implementation of a particular protocol. The "assertion" terminology is SAML-specific but is an abstraction at this level.

Common Attributes

  • Location (relative path)
    • The location of the ACS (when combined with the base handlerURL). This is the location to which an IdP sends assertions using whatever protocol and binding it shares with the SP. Each combination of SSO protocol and binding is usually installed at a unique location to improve efficiency.
  • Binding (URI)
    • Identifies the protocol binding supported by the ACS. Bindings describe how the assertion and any enclosing content are packaged by the IdP (or by the browser in some cases) for consumption by the ACS. As an example, the SAML 2.0 specification and subsequent documents describe as many as 4-5 different bindings that all underlie essentially the same SSO protocol.
  • index (unsigned integer)
    • A "tag" that identifies the ACS endpoint so that it can be referenced by other configuration elements or applications. It is strongly suggested that the values correspond to the values included in the SP's Metadata.
  • policyId (namespace-qualified by urn:mace:shibboleth:2.0:native:sp:config) (string)
    • References the id of a <Policy> element in the configuration and causes that security policy to be applied to messages sent to this endpoint. Not generally used because attackers can bypass special policies by choosing the most advantageous endpoint, but allows for more advanced extension features in the future.
  • signing (namespace-qualified by urn:mace:shibboleth:2.0:native:sp:config) (see NativeSPSigningEncryption) (Version 2.6 and Above)
    • Controls outbound signing of XML messages subject to applicability to the protocol involved. This has no effect with any existing supported protocols.
  • encryption (namespace-qualified by urn:mace:shibboleth:2.0:native:sp:config) (see NativeSPSigningEncryption) (Version 2.6 and Above)
    • Controls outbound encryption of XML messages and content subject to applicability to the protocol involved. This has no effect with any existing supported protocols.

SAML 1.x AssertionConsumerService

The SAML 1.x ACS implements the SAML 1.0 and 1.1 Browser SSO profile. In addition, the ACS performs attribute extraction, filtering, and resolution based on the data supplied by the IdP.

The following Binding values are supported, corresponding to the two SSO profiles:

  • urn:oasis:names:tc:SAML:1.0:profiles:browser-post
  • urn:oasis:names:tc:SAML:1.0:profiles:artifact-01

SAML 2.0 AssertionConsumerService

The SAML 2.0 ACS implements the SAML 2.0 Browser SSO and ECP profiles. In addition, the ACS performs attribute extraction, filtering, and resolution based on the data supplied by the IdP.

The following Binding values are supported:

  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact
  • urn:oasis:names:tc:SAML:2.0:bindings:PAOS

Attributes

Version 2.2 and Above

  • ignoreNoPassive (namespace-qualified by urn:mace:shibboleth:2.0:native:sp:config) (boolean) (defaults to "false")
    • If true, causes the SAML StatusCode of urn:oasis:names:tc:SAML:2.0:status:NoPassive to be ignored and treated as a silent condition resulting in redirection back to the original resource.

Example usage with the default namespace from the distributed shibboleth2.xml:

<md:AssertionConsumerService Location="/SAML2/POST" index="1"                                          
    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"                                           
    conf:ignoreNoPassive="true" />

ADFS AssertionConsumerService

The ADFS handler is only available if the adsfs.so extension library is loaded by the SP.

The ADFS ACS implements the Microsoft ADFS authentication protocol, a subset of the WS-Federation passive requester profile. In addition, the ACS performs attribute extraction, filtering, and resolution based on the data supplied by the IdP.

The following Binding values are supported:

  • http://schemas.xmlsoap.org/ws/2003/07/secext
  • No labels