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

Version 1 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.

Protocol Endpoints in IdP Metadata

The most important endpoint at the IdP is the <md:SingleSignOnService> endpoint. Every IdP has at least one such endpoint. IdPs that support both SAML V2.0 and legacy Shibboleth use of SAML V1.1 have at least two such endpoints.

In the InCommon Federation, every IdP that supports SAML V2.0 MUST include an SSL/TLS-protected <md:SingleSignOnService> endpoint that supports the SAML V2.0 HTTP-Redirect binding. (Other SAML V2.0 HTTP bindings MAY be supported.) Likewise every IdP that supports the legacy Shibboleth profile of SAML V1.1 MUST include an SSL/TLS-protected <md:SingleSignOnService> endpoint that supports the Shibboleth 1.x AuthnRequest protocol.

An IdP that supports the SAML V2.0 HTTP-Artifact binding (or the SAML V1.1 Browser/Artifact profile) MUST include one or more <md:ArtifactResolutionService> endpoints in metadata (at least one per-protocol). Support for HTTP Artifact is optional, but some kinds of services and content don't function well with a POST-based model. IdPs that can support the Artifact approach should do so.

Finally, IdPs that support attribute query will have one or more <md:AttributeService> endpoints in metadata. This is typically a SAML V1.1 consideration (to support older Shibboleth SPs); generally SAML V2.0 queries SHOULD NOT be supported to avoid unnecessary queries from SPs in certain cases.

Recommended Practice

  • IdPs support authentication requests via the SAML V2.0 HTTP-Redirect binding and the legacy Shibboleth 1.x request protocol.
  • IdPs capable of supporting Basic Authentication or TLS Client Authentication support ECP authentication requests via the SAML V2.0 SOAP binding.
  • IdPs support SAML V1.1 attribute queries, but do not advertise support for SAML V2.0 queries unless explicitly necessary.
  • TLS/SSL is used on all user-facing endpoints.

Technical Details

Protocol Endpoints in IdP Metadata
<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:mace:shibboleth:1.0:profiles:AuthnRequest" 
    Location="https://idp.example.org/idp/profile/Shibboleth/SSO"/>

Technical Requirements

Support for SAML V1.1 Web Browser SSO is optional:

  • IdPs MUST include an SSL/TLS-protected <md:SingleSignOnService> endpoint that supports the Shibboleth 1.x AuthnRequest protocol (assuming their software supports this feature)
  • IdPs SHOULD support the urn:mace:shibboleth:1.0:nameIdentifier transient name identifier format

Support for SAML V2.0 Web Browser SSO is recommended:

  • IdPs MUST include an SSL/TLS-protected <md:SingleSignOnService> endpoint that supports the SAML V2.0 HTTP-Redirect binding
  • IdPs SHOULD support the urn:oasis:names:tc:SAML:2.0:nameid-format:transient and urn:oasis:names:tc:SAML:2.0:nameid-format:persistent name identifier formats

Support for SAML V2.0 Enhanced Client or Proxy is recommended:

  • IdPs MUST include an SSL/TLS-protected endpoint that supports the SAML V2.0 SOAP binding with either HTTP Basic Authentication or TLS Client Authentication
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels