Versions Compared

Old Version 16

changes.mady.by.user trscavo@internet2.edu

Saved on

compared with

New Version 17

changes.mady.by.user trscavo@internet2.edu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

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:

No Format
<!-- The Example State University (example.edu) -->
<md:EntityDescriptor entityID="https://websso.example.edu/idp" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:IDPSSODescriptor errorURL="https://login.example.edu/support.html" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:Extensions>
      <shibmd:Scope xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" regexp="false">example.edu</shibmd:Scope>
      <mdui:UIInfo xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui">
        <mdui:DisplayName xml:lang="en">Example State University Secure Web Login</mdui:DisplayName>
        <mdui:InformationURL xml:lang="en">https://login.example.edu</mdui:InformationURL>
        <mdui:Logo height="128" width="128" xml:lang="en">https://login.example.edu/images/IdP_Logo.png</mdui:Logo>
      </mdui:UIInfo>
    </md:Extensions>
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>
MIIDyTCCArGgAwIBAgIJAKivSalalUbnMA0GCSqGSIb...
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.example.edu/idp/saml2/Redirect/SSO"/>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.example.edu/idp/saml2/POST/SSO"/>
  </md:IDPSSODescriptor>
  <md:Organization>
    <md:OrganizationName xml:lang="en">The Example State University</md:OrganizationName>
    <md:OrganizationDisplayName xml:lang="en">Example State University</md:OrganizationDisplayName>
    <md:OrganizationURL xml:lang="en">http://www.example.edu</md:OrganizationURL>
  </md:Organization>
  <md:ContactPerson contactType="technical">
    <md:GivenName>Technical Services</md:GivenName>
    <md:EmailAddress>tech-services@example.edu</md:EmailAddress>
  </md:ContactPerson>
  <md:ContactPerson contactType="administrative">
    <md:GivenName>Administrative Services</md:GivenName>
    <md:EmailAddress>admin-services@example.edu</md:EmailAddress>
  </md:ContactPerson>
</md:EntityDescriptor>

...

  • Most IdP entity descriptors include two role descriptors, given indicated by the <md:IDPSSODescriptor> and <md:AttributeAuthorityDescriptor> elements.
  • Each role descriptor contains its own key descriptor, and moreover, the two key descriptors are identical.
  • Most IdPs publish one or more back-channel, SOAP-based endpoints, including:
    • one or more ArtifactResolutionService endpoints
    • one or more AttributeService endpoints
  • Many IdPs support SAML1, and moreover, publish a SAML1 AttributeService endpoint

Clearly the metadata for an IdP that only supports SAML2 on the front channel is much simpler. That simplicity translates into an IdP that is easier to troubleshoot, manage, and maintain.