While Shibboleth is designed to be as strictly standards-conforming as possible, all standards have rough spots and limitations and SAML is no exception. As a rule, SAML 2.0 is more interoperable than SAML 1.1, and there are numerous Shibboleth extensions to SAML 1.1 that are difficult or impossible to get commercial support for. But there are still aspects of implementing SAML 2.0 that go beyond the scope of the standard and can cause problems, nor does Shibboleth implement every single feature in the standard.

Where possible, we will identify and document steps that deployers can take to improve the odds of successful interoperability or note problem areas. When we get assistance from vendors in the details of their own software, we may be able to provide additional resources or links.

SAML 2.0 Interoperability

TBD...

SAML 1.1 Interoperability

The scope of the SAML 1.1 standard is such that a number of important features in Shibboleth will not generally interoperate with commercial SAML implementations. This list includes, but is not limited to:

SP-initiated SSO rather than a portal/push model from IdP to SP
Use of attribute query rather than "pushing" attributes during SSO
Use of complex/non-string SAML Attribute values, including "scoped" eduPerson values
Use of metadata (pretty much at all)
Flexible evaluation of keys and certificates

These issues, and workarounds, are discussed below.

SSO Flow

The typical Shibboleth flow for SSO is for a user to visit an SP and be redirected to their IdP (subject to discovery of the IdP using some mechanism), and then sent back with an assertion. This is not part of the SAML 1.1 standard, which defines only an artificially contrived "portal"-oriented model in which the IdP pushes the user to the SP seemingly without a request.

As a result, it can be difficult or impossible to explicitly configure a commercial SP to initiate SSO to a Shibboleth IdP. Instead, the application or a link on a web site must usually be created to simulate this request using the simple redirection protocol defined by the legacy Shibboleth profile.

The link will have to contain a providerId parameter with the entityID of the SP, a target parameter with the URL of the resource to access, and a shire parameter with the location of the SP's "assertion consumer service".

Pushing Attributes

Because SAML 1.1 does not allow for encryption of XML as it passes through the browser, the typical Shibboleth exchange is of an empty authentication assertion during SSO, followed by a SOAP query (also part of SAML) to the IdP over a confidential channel. Most commercial products will not allow for this mode of operation, and require the IdP to include attributes in the SSO assertion.

This is not the default behavior, so must generally be changed by adding a RelyingParty definition to relying-party.xml with a specially crafted ShibbolethSSOProfile configuration with the includeAttributeStatement flag.

Example RelyingParty configuration for attribute push with SAML 1.1

<RelyingParty id="https://sp.example.org/samlentity"
  provider="https://idp.example.org/idp/shibboleth"
  defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
   <ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" includeAttributeStatement="true"/>
</RelyingParty>

Attribute Value Syntax

For reasons that do not bear discussion here, the older SAML 1.1 profile defined by MACE-Dir for encoding eduPerson attributes into SAML results in XML for some attributes that will generally not work with commercial products. To correct for this, the profile was updated to define additional attribute names that correspond to more simply encoded string values.

The profile was developed to simplify the task of a Shibboleth deployer in supporting both interoperability with Shibboleth SPs and commercial interoperability at the same time without conflicts. Essentially, the same attribute information is mapped into two alternate SAML attributes, one for each case.

A common example is the "eduPersonPrincipalName" attribute. Ordinarily, the SAML name of this attribute is "urn:mace:dir:attribute-def:eduPersonPrincipalName", but the name of the simpler formulation (which is ironically more complex) is "urn:oid:1.3.6.1.4.1.5923.1.1.1.6".

Example Attribute Definition for eduPersonPrincipalName

<resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
    scope="example.org" sourceAttributeID="uid">
    <resolver:Dependency ref="myLDAP" />

    <resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        name="urn:mace:dir:attribute-def:eduPersonPrincipalName" />

    <!-- additional definition for use with commercial SAML 1.1 SPs -->
    <resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" scopeType="inline" />

    <resolver:AttributeEncoder xsi:type="SAML2ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />

</resolver:AttributeDefinition>

Metadata

While Shibboleth includes support for a profile of SAML 2.0 Metadata that applies to SAML 1.1, and this profile is an OASIS standard, we are unaware of any commercial support for it. Products should not be expected to support metadata in any way, and you will most likely be forced to either supply the information that would ordinarily be in metadata in a manual fashion, or the commercial deployer will be forced to extract the information from metadata on their own.

Since there is no practical method of supplying this information in a fashion other than metadata that will ensure it remains up to date, deployers are urged to insist that commercial deployers take responsibility for dealing with this limitation.

Keys and Certificates

Related to the previous issue, there is essentially no interoperability with respect to the handling of keys and certificates. Configuration of partner keys is largely manual, rather than relying on metadata as Shibboleth does, and the manner of evaluation of certificates tends to vary between signing operations and TLS/SSL connections.

As a practical matter, because of other limitations, there is generally no requirement for TLS/SSL evaluation if the POST Profile is used, which leaves the problem of verifying IdP signatures. But this is generally more flexible than their handling of TLS/SSL, and usually products will allow for direct importation of the partner's signing key.

Note that Shibboleth does not encourage reliance on PKIX/X.509 as an evaluation mechanism at runtime, and most federations cannot be expected to require all participants to use certificates from a single, or even any, CA. There is little to be gained from doing so in any event, as this does not significantly improve the manageability of the commercial products anyway.

Browser not supported