The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

This document contains DRAFT material intended for discussion and comment by the InCommon participant community.  Comments and questions should be sent to the InCommon participants mailing list.

Endpoints in IdP Metadata

This topic outlines requirements and recommendations regarding endpoints in IdP metadata registered by InCommon.

An endpoint in metadata signals support for a specific profile of SAML. In particular, all IdPs in InCommon metadata MUST support SAML2 Web Browser SSO by including certain browser-facing SSO endpoints in metadata. Support for any other profile is strictly OPTIONAL.

Keep it simple!

InCommon recommends that site administrators publish IdP metadata with as few endpoints as possible. It is sufficient for IdP metadata to advertise support for SAML2 Web Browser SSO on the front channel only. Advertised support for other protocols, especially back-channel protocols, should be avoided in published metadata.

Endpoint Requirements

The requirements and recommendations outlined in this section apply to both new and existing IdP metadata.

All IdPs MUST have at least one SingleSignOnService endpoint in metadata. That endpoint MUST support either the SAML2 HTTP-Redirect binding or the SAML2 HTTP-POST binding. Support for both bindings is strongly RECOMMENDED.

Browser-facing SSO endpoints

IdPs SHOULD include both of the following endpoints in metadata:

  • A SingleSignOnService endpoint that supports the SAML2 HTTP-Redirect binding
  • A SingleSignOnService endpoint that supports the SAML2 HTTP-POST binding

At least one of the above endpoints is REQUIRED in IdP metadata.

A SingleSignOnService endpoint that supports the SAML2 HTTP-POST-SimpleSign binding MAY be included in IdP metadata but that is usually not necessary since that binding is seldom used by SAML2 SPs. (If you advertise a SAML2 HTTP-POST-SimpleSign endpoint in metadata, check your logs. You may find that this endpoint is unused.)

Single logout endpoints

A single topic covering Single Logout Endpoints in both IdP and SP metadata is found elsewhere in this wiki.

 A SAML2 AttributeService endpoint SHOULD NOT be included in IdP metadata. If an IdP routinely pushes attributes on the front channel (which is typical), attribute query is redundant and in some cases known to cause errors, usually at the SP.

Avoid SAML2 attribute query endpoints

If your IdP is configured to always push attributes during SAML V2.0 Web Browser SSO, you can safely remove the SAML V2.0 <md:AttributeService> endpoint from your metadata. Failure to do so will cause redundant attribute queries to occur, and in some cases spurious errors at the SP have been reported.

Recommendations for New IdPs

A new IdP MUST support SAML2 Web Browser SSO. Endpoints that advertise support for other SAML profiles SHOULD NOT be included in new IdP metadata registered by InCommon.

Endpoints in new IdP metadata

It is strongly RECOMMENDED that new IdP metadata contain these two endpoints (and no others):

  • A SingleSignOnService endpoint that supports the SAML2 HTTP-Redirect binding
  • A SingleSignOnService endpoint that supports the SAML2 HTTP-POST binding

These browser-facing SSO endpoints are relatively easy to test and maintain.

The following endpoints are especially NOT RECOMMENDED in new IdP metadata:

  • SAML1 endpoints of any kind
  • SAML2 SingleLogoutService endpoints
  • Any endpoint that supports a SOAP binding, including:
    • Any ArtifactResolutionService endpoint
    • Any AttributeService endpoint

Your IdP software may support some or all of the above (which may turn out to be useful) but publishing those endpoints in metadata is a commitment that should be delayed until your IdP deployment has sufficiently matured. In the future, if you actually need to publish one of those endpoints (which is unlikely), you can always add it to your metadata at a later time.

Technical Details

All IdPs SHOULD include both of the following endpoints in metadata. It is strongly RECOMMENDED that new IdP metadata contain only these two endpoints, at least initially.

SAML endpoints in IdP metadata
<!-- SAML V2.0 browser-facing SSO endpoints -->
<md:SingleSignOnService xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
    Location="https://idp.example.org/idp/profile/SAML2/Redirect/SSO"/>
<md:SingleSignOnService xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    Location="https://idp.example.org/idp/profile/SAML2/POST/SSO"/>

Note that the browser-facing <md:SingleSignOnService> endpoints run on the default SSL/TLS port (443).

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels