NativeSPApplication

Overview

The <ApplicationDefaults> element (and any nested <ApplicationOverride> elements) define most of the runtime behavior of the software when it processes SAML assertions and protocol messages. The usual pattern is to define most of this information once, in the outer element, and then supply a limited set of overridden information for each application you define that needs exceptional behavior.

Every request to the web server is associated with an application by the request mapper component. An application represents distinct collections of resources within the server's document tree that share the same general configuration requirements, although access control can be enforced on a finer-grained basis.

These application boundaries may or may not align with the notion of an application as understood in other contexts, but usually do. A very common strategy is for each virtual host on a server to map to its own application.

The majority of the SP's more advanced functionality is defined on a per-application basis. Supported protocol endpoints and handlers, security policies, credentials for signing, encryption, and TLS, attribute extraction/resolution/filtering, and the entityID to use are just some of the options handled here.

When a resource protected by the SP needs distinct behavior in these kinds of areas, a new application needs to be defined here and referenced by the request mapper using the applicationId property.

The <ApplicationDefaults> element both specifies default behavior and acts as a container for any other <ApplicationOverride> elements. <ApplicationOverride> elements inherit all the settings of the <ApplicationDefaults> element but can override them (see NativeSPApplicationOverride for details on how this works).

Basic Configuration (Version 2.4 and Above)

The default configuration of the <ApplicationDefaults> element and most of its subelements will work for most circumstances with a few modifications.

• The entityID attribute on the <ApplicationDefaults> element needs to be changed to the SAML entityID you'd like to use for your deployment. This must be the value your federations and partners are expecting.

• Configure SSO to an IdP or with a Discovery Service

  • To use a specific IdP, change the entityID setting in the <SSO> element to match the value in that IdP's metadata.

  • To use a discovery service, remove the entityID setting in the <SSO> element, and set the discoveryProtocol and discoveryURL settings appropriately.

• The <CredentialResolver> element's content must point to the key and certificate to use for signing, decryption, and authenticating the SP to other systems. By default it matches the filenames used for the keypair generated by the installation process.

• Typically, each federation, or IdP partner if you're dealing with sites directly, will supply you with a metadata file describing itself. One <MetadataProvider> element needs to be added for every metadata file you'd like to point to, or you can combine them in one file yourself.

• REMOTE_USER is a special server or CGI variable used to pass the primary identifier of a browser user. An attribute ID or alias defined in the attribute-map.xml file can be designated as the source for REMOTE_USER. Multiple attributes may be listed in order of precedence.

If specialized behavior for another application needs to be defined, use an <ApplicationOverride> child element.

Basic Configuration (Older Versions)

The default configuration of the <ApplicationDefaults> element and most of its subelements will work for most circumstances with a few modifications.

• The entityID attribute on the <ApplicationDefaults> element needs to be changed to the SAML entityID you'd like to use for your deployment. This must be the value your federations and partners are expecting.

• homeURL is where the SP redirects the client to when there is nothing else that can be done with a request and can be set to a standard home page or index page.

• You'll need to configure a default <SessionInitiator> handler as designated by the isDefault="true" attribute. The choice of which example in shibboleth2.xmlto use as a default depends on how you'll be using the software.

  • The Intranet example demonstrates how to send users directly to a particular IdP to authenticate. Change the entityID to match the value in that IdP's metadata.

  • The WAYF example allows for Shibboleth 1.x-style IdP selection. If your deployment or federation supplies only a legacy WAYF service, this example can be made the default. Change the URL attribute to match the WAYF service's location.

  • The DS example supports the more modern 2.0 SAML IdP discovery protocol. The URL attribute should again be changed to match the appropriate location.

• The <CredentialResolver> element's content must point to the key and certificate to use for signing, decryption, and authenticating the SP to other systems. By default it matches the filenames used for the keypair generated by the installation process.

• Typically, each federation, or IdP partner if you're dealing with sites directly, will supply you with a metadata file describing itself. One <MetadataProvider> element needs to be added for every metadata file you'd like to point to. Each one lives inside the outer-most "Chaining" plugin.

• REMOTE_USER is a special server or CGI variable used to pass the primary identifier of a browser user. An attribute ID or alias defined in the attribute-map.xml file can be designated as the source for REMOTE_USER. Multiple attributes may be listed in order of precedence.

If specialized behavior for another application needs to be defined, use an <ApplicationOverride> child element at the end of the outer element's set of children.

Attributes

• id(string)

  • Identifies the application using a unique key. On the outer-most element, the value MUST be "default" (or omitted on 2.4+).

• entityID (URI) (required for <ApplicationDefaults>, optional for <ApplicationOverride>)

  • An entityID is the SAML identifier that uniquely names an SP. Identity providers do not know about the internal application boundaries of an SP deployment. Any external distinctions must be noted by assigning a different entityID.

• policyId (string) (optional on 2.4+, else required for <ApplicationDefaults>, optional for <ApplicationOverride>)

  • References a policy defined in the <SecurityPolicies> element. When omitted on Version 2.4 and above, the default policy is assumed.

• requireAuthenticatedEncryption (boolean) (defaults to false) (Version 2.5 and Above)
  
  

  • When true, the SP will refuse to decrypt assertions that are unprotected by a signature or an authenticated transport (e.g., back-channel TLS) unless the data is encrypted with a special type of algorithm that includes built-in integrity protection to prevent chosen ciphertext attacks. At the present time, this will generally block use of encryption unless signed responses are enabled by an IdP.

• homeURL(URL)

  • A location to send the browser to when a resource URL is required but cannot be determined (for example, following SSO when no local state information can be found). As of Version 2.2.1, this can be omitted and it will calculate the root of the site. In prior versions, leaving this out usually results in errors, but was defaulted to the literal value of "/".

• REMOTE_USER(space-delimited list of strings)

  • Specifies a list of attribute IDs/aliases to look for in a session's cache of attributes. The first one found with a value is set as REMOTE_USER (or in the case of IIS, HTTP_REMOTE_USER).

• unsetHeaders(space-delimited list of strings)

  • Normally, the set of possible headers that might be used to carry attributes is determined by querying the configured attribute extractor(s). This allows the list to be overridden. Not typically used.

• attributePrefix(string)

  • Applies a fixed prefix to the IDs and aliases of any attributes stored in user sessions. Used for special situations such as passing environment variables across the AJP connector protocol.

• metadataAttributePrefix(string)

  • If set, attributes extracted from metadata have their IDs and aliases prefixed with this value. Allows applications to distinguish between attributes about the user and attributes about the user's identity provider.

Relying Party Attributes

The following supported attributes are grouped because they can be overridden per-partner using a <RelyingParty> element:

Child Elements

On Version 2.4 and above, all but the first two elements may appear in any order. On older versions, the order MUST be as listed.

Also on Version 2.4 and above, elements that could not appear more than once unless explicitly "chained" may now appear multiple times and will be chained automatically. This includes <MetadataProvider>, <TrustEngine>, <AttributeExtractor>, <AttributeResolver>, and <AttributeFilter>.

• <Sessions> (required for <ApplicationDefaults>, optional for <ApplicationOverride>)

  • Configures the session handling behavior for the application, as well as all of the supported processing handlers and their locations.

• <Errors>(optional)

  • Configures error-handling behavior and a few logout-related responses.

• <RelyingParty>(zero or more)

  • Overrides some communication-related settings for specific identity providers or groups of providers.

• <Notify>(zero or more)

  • Configures application notification of logout or name identifier management messages.

• <MetadataProvider> (zero or more on 2.4+, else required for <ApplicationDefaults>, optional for <ApplicationOverride>)

  • Supplies metadata about identity providers.

• <TrustEngine> (zero or more on 2.4+, else required for <ApplicationDefaults>, optional for <ApplicationOverride>)

  • Controls how trust processing is performed to determine whether authentication of messages from identity providers succeeds or fails, including XML and simple signing, and SSL/TLS. In later versions, the default configuration used when none are specified is to chain the ExplicitKey and PKIX engines together.

• <AttributeExtractor>(zero or more on 2.4+, else zero or one)

  • Controls how SAML attributes are decoded and exposed to applications.

• <AttributeResolver>(zero or more on 2.4+, else zero or one)

  • Controls access to other data sources for attribute information. Primary use is for support of SAML queries to an identity provider for attributes if none are received in the initial assertion. When absent, the SP will not query for attributes.

• <AttributeFilter>(zero or more on 2.4+, else zero or one)

  • Applies rules that filter out unacceptable attribute information.

• <CredentialResolver>(zero or more on 2.4+, else zero or one)

  • Configures the private keys and certificates used by the SP to identify itself to identity providers. This is NOT related to the normal SSL/TLS server support provided by web servers.

• <ApplicationOverride>(zero or more)

  • Overrides default behavior by nesting exceptional configuration elements. Cannot themselves appear inside other <ApplicationOverride> elements.

Examples

The following shibboleth2.xml excerpt contains an example in which a second application with its own entityID is created on a second virtual host. This is one of the most common cases.

This excerpt is an example where the additional application is on the same virtual host. Notice the overriden handlerURL that also has to map to the overridden applicationId.