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.

NativeSPManageNameIDService

Owned by Scott Cantor
Last updated: Jun 30, 2012Version comment
2 min read

The <md:ManageNameIDService> element is used to configure handlers that are responsible for processing name identifier management messages from an IdP. These are protocol specific, but generally fall into two classes: requests, which inform the SP of a change, and responses, which conclude a change event initiated by the SP.

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

As a multi-protocol system, the SP itself is oblivious to specific management protocols; each handler provides the implementation of a particular protocol.

Common Attributes

  • Location (relative path)
    • The location of the handler (when combined with the base handlerURL). This is the location to which an IdP sends messages using whatever protocol and binding it shares with the SP. Each combination of protocol and binding is installed at a unique location to improve efficiency.
  • Binding (URI)
    • Identifies the protocol binding supported by the handler. Bindings describe how the message is packaged by the IdP (or by the browser in some cases) for consumption by the handler.

SAML 2.0 ManageNameIDService

The SAML 2.0 NameID management handler implements the SAML 2.0 Browser NameID management profile. The incoming message must be a <samlp:ManageNameIDRequest>. SP-initiated management is not currently supported.

If the message is a request via a front-channel binding, then the following steps are performed. If an error occurs at any point, an effort is made to respond to the requesting IdP with a <samlp:ManageNameIDResponse> containing the error.

  1. Verification of the information in the request against the active session is done.
  2. The back-channel application notification loop is executed.
  3. A <samlp:ManageNameIDResponse> is returned to the requesting IdP.

If the message is a request via a back-channel binding, then the following steps are performed:

  1. The back-channel application notification loop is executed.
  2. A <samlp:ManageNameIDResponse> is returned to the requesting IdP.

The following Binding values are supported:

  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
  • 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:SOAP