Page History

...

Later, if an SP partner requires the use of a back-channel SAML protocol, a new endpoint is easily added to metadata. However, since all new SPs registered in the Federation today are required to support SAML2 Web Browser SSO on the front channel, you may never need these extra SAML features.

An IdP should avoid SAML1 altogether if possible, but in any case note the following:

• An IdP can support IdP-initiated SAML1 flows without advertising any SAML1 endpoints in metadata. (The same is true of SAML2 of course.)
• An IdP supports SP-initiated SAML1 flows by advertising a SingleSignOnService endpoint that supports the proprietary Shibboleth AuthnRequest binding/protocol.
• If an IdP must support SAML1, try to avoid SAML1 attribute query if at all possible. An IdP should seriously consider pushing attributes via unencrypted SAML1 assertions on the front channel in lieu of attribute query.

All new IdPs MUST support SAML2 Web Browser SSO. Note the following recommendations:

• An IdP supports SP-initiated SAML2 flows by advertising a SingleSignOnService endpoint that supports the SAML2 HTTP-Redirect binding. Support for other bindings is optional and new deployments are encouraged to be conservative in this respect.
• An IdP should avoid SAML2 attribute query altogether. (I've never known an IdP deployment that actually needed a SAML2 AttributeService endpoint in metadata.)
• An IdP should push attributes via encrypted SAML2 assertions when it can. In practice, expecting all SP software to fully support XML Encryption is unreasonable, especially for non-Shibboleth SP software, so IdP operators should be prepared to make exceptions. That said, end-to-end encryption is certainly a goal.

To illustrate the above recommendations in terms of metadata, here is a sample entity descriptor for an IdP that supports SAML2 Web Browser SSO on the front channel only:

...