InteropWithOnedotOne

There were significant changes in the ShibbolethSpecifications between the time that early versions like 1.0 and 1.1 were developed and 1.2 was released. As a result, there are compatibility issues to be considered when operating an IdP or SP that must interact with 1.1 implementations.

New SP, old IdP

This is generally not the difficult case. New releases of the C++ ServiceProvider, including ShibOnedotThree, have compatibility code that accomodates some of the differences present in the assertions issued by the old IdP. The metadata you supply an SP about the old IdP is essentially the same as with any other IdP.

The only thing to keep in mind is that the SAML assertions issued by a 1.1 IdP will typically include a saml:Audience condition element that contains a somewhat arbitrary string intended to represent the federation in use. In order to successfully process those assertions, the newer SP will need to configure itself with a saml:Audience element inside the Applications element of its ShibbolethXml file that matches the value sent by the IdP. This is why you will see urn:mace:inqueue in the example file that comes with the software.

Failure to do this will usually result in a "policy mismatch" or an "unacceptable AudienceRestrictionCondition" error when creating the user session.

New IdP, old SP

Most of the compatibility issues center around dealing with an older SP from a newer IdP. There are a few to consider.

Attribute Schema Changes

Early versions of the Shibboleth SP rely on an XML parser that had significant bugs when validating XML against a schema. As a result, work-arounds were designed that are no longer necessary if the SP is using a Xerces-C version 2.6 or newer. The version of Shibboleth is actually not the determining factor, but newer versions will only build against a Xerces-C that contains the fixes.

Prior to ShibOnedotThree, all versions of the IdP accomodated this bug directly. As of ShibOnedotThree, deployers must specifically enable this behavior if they expect to be issuing attributes to older SP versions by adding the XML attribute schemaHack="true" to a RelyingParty element in their IdPXml file. Adding it to the defaultRelyingParty will enable the fix for all partner sites or you can be more specific if you like.

Failure to do this will cause older SP software to reject the attributes it receives with an XML parsing error.

Authenticating Attribute Queries

The primary protocol change made after 1.1 was the use of an XML attribute in the SAML 1.1 spec named Resource to identify the providerId of the SP that is making a query. Older versions of Shibboleth prior to 1.2 populated this attribute with an arbitrary URL that typically was a web resource being accessed. Commercial SAML products typically don't use the attribute at all. Along with this change, the way the requesting SP was identified to the IdP software was changed from the subject name of the SP's client certificate to its providerId. MetaData was used to secure this association.

With Shibboleth 1.2, an unfortunate decision was made to use a custom HTTP header named Shibboleth in the SOAP request message to signify that a newer, more compliant SP was making the query, allowing the IdP to properly match the Resource attribute against the MetaData to identify the SP.

As of ShibOnedotThree, a more comprehensive approach to dealing with these issues has been implemented. As a result, the software first attempts to locate a matching entity in MetaData based on the value of the Resource attribute, which is consistent with the ShibbolethSpecifications. Failing that, the CN and any subjectAltName inside the client certificate is used to search the MetaData again.

Thus, both older and newer SPs are identified in MetaData in a consistent way, along with any non-Shibboleth SPs. To identify a 1.1 SP to your ShibOnedotThree IdP, you simply create (or obtain) MetaData for it as with any other SP, but the entityID used to name the SP is the certificate CN (or subjectAltName).

For example, if a 1.1 SP is using a certificate with a subject such as "CN=sp.legacy.com, O=Legacy Co, C=US", you would create MetaData for it similar to the following (example abbreviated for brevity):

<EntityDescriptor entityID="sp.legacy.com">
	<!-- ...usual SP content here... -->
</EntityDescriptor>

With this approach, you can consistently know what to place in your ARP in the Requester element because it will always be the value in the corresponding entityID.