...
- the public key(s) used by the IdP for authentication and encryption
- endpoints of various types for communicating with it
- explicitly supported identifier formats, if any
- explicitly supported attributes, if any
The order of all this information is significant, which you can refer to the schema for, but the most common elements included would be present in the following order.
...
| Tip | ||
|---|---|---|
| ||
The keys you identify in the metadata MUST match the keys you configure into the IdP as credentials (see V2 or V3 documentation). If they don't match, SPs will generally be unable to accept assertions from or make queries to the IdP. |
...
SAML includes the ability to rely on redirects containing small strings called "artifacts" that the consuming site uses to pull the complete message. This is much more commonly used in the IdP->SP direction, so some IdPs may need to support an inbound SOAP endpoint to perform artifact->message resolution.
...
| title | Shibboleth-Specific Tip |
|---|
The Location attribute of these endpoints is derived from the <ProfileHandler> elements defined in the IdP's handler.xml file. As with all IdP profile handlers that rely on SOAP, the locations will typically be of the form https://hostname:8443 + servlet context + "/profile" + path, where path is determined from the <RequestPath> child element in the profile handler configuration.
...
.
Logout
If your IdP supports SAML 2.0 Single Logout, you will need to include one or more <md:SingleLogoutService> endpoint elements in the metadata.
...
IdPs support SSO protocols by including one or more <md:SingleSignOnService> endpoint elements in their metadata. These are the locations to which the SP (or some other web site acting on its behalf) will send the user to the IdP with a protocol-specific request of some kind.
...
...
The Location attribute of these endpoints is derived from the <ProfileHandler> elements defined in the IdP's handler.xml file. As with all front-channel IdP profile handlers, the locations will typically be of the form https://hostname + servlet context + "/profile" + path, where path is determined from the <RequestPath> child element in the profile handler configuration.
The elements must also include a Binding attribute, which can be copied directly from the profile handler's inboundBinding attribute.
Attribute Services
IdPs that support attribute queries document this by including the additional <md:AttributeAuthorityDescriptor> role in their metadata containing one or more <md:AttributeService> endpoint elements. These are the SOAP endpoints to which SPs or other software may send SAML attribute queries.
...
| title | Shibboleth-Specific Tip |
|---|
The Location attribute of these endpoints is derived from the <ProfileHandler> elements defined in the IdP's handler.xml file. As with all IdP profile handlers that rely on SOAP, the locations will typically be of the form https://hostname:8443 + servlet context + "/profile" + path, where path is determined from the <RequestPath> child element in the profile handler configuration.
...
.
Documenting Attributes
An IdP can enumerate the SAML attributes that it can supply (subject to policy) to SPs. This is essentially informational in most cases.
...