AlternateProfiles

SAML Profiles & Shibboleth

Traditional Shibboleth utilizes SAML 1.1's Browser/POST profile to carry assertion information from the IdP to the SP. The authentication assertion is imbedded in a Javascript form and POSTed to the SP, which uses the information therein to authenticate the user and query the AA for further attribute information.

Shibboleth is also capable of using the Browser/Artifact profile. In this profile, the assertion is stored at a location in the IdP which is encoded into a URL of an HTTP GET request instead. When the browser hits the SAML/Artifact handler of the SP, the SP then accesses the encoded URL to retrieve the user's assertion. While it would be possible to then use an additional callback to retrieve additional attribute information, it makes far more sense and is the default to include the attributes in the original artifact.

The choice of which profile to use for a transaction is almost entirely dictated by the SP, which informs the IdP of which profile it would like to use. This affects how the IdP sends assertions to the SP, while the IdP still largely dictates the contents of those assertions.

Artifact Configuration

Two changes need to be made to a Shibboleth deployment to switch to artifacts from POST:

• In the SP's metadata, the isDefault="true" attribute may be present in a POST <AssertionConsumerService> element. This should be removed from the POST handler's element if there and added to the Artifact handler's element.
• In shibboleth.xml , the isDefault="true" attribute may be present in the POST <md:AssertionConsumerService> element. This should be removed from the POST handler's element if there and added to the Artifact handler's element.

While the provider remains capable of processing both profiles, it will now by default request and be issued Artifacts.

Attribute Push

Attribute push describes including a user's attributes along with the authentication assertion that's returned to the SP in the initial POST transaction.

This concerns some deployers when used with SAML 1.1, because SAML 1.1 doesn't support encrypted assertions. While the transactions will be protected in almost all cases with TLS/SSL, there is still a significantly greater chance the user's attributes can be viewed in transit than there is with the standard callback model. This will change in Shibboleth 2.0. Of course, the user can also see their own attributes, which may be either good or bad depending on one's point of view.

Attribute push is off by default in the Browser/POST profile, because of the above security concerns, and on by default in the Browser/Artifact profile, because it would be redundant if disabled. However, it is possible to force the IdP to either enable or disable PUSH for a given transaction.

• To force attribute push for a transaction, add a forceAttributePush="true" attribute to the appropriate <RelyingParty> element.
• To disable attribute push for a transaction, add a forceAttributeNoPush="true" attribute to the appropriate <RelyingParty> element.

 An additional setting that is often relevant when using attribute push concerns the number of assertions issued. For historical reasons, the Shibboleth IdP generally issues two assertions when pushing attributes, one for authentication and the other for attributes. This is legal, but we have found that few commercial products support this.

• To interoperate, you may need to add a singleAssertion="true" attribute to the appropriate <RelyingParty> element as well.