...
| Tip | ||
|---|---|---|
| ||
When first starting out, the IdP generates an initial metadata file during the installation process and copies it to metadata/idp-metadata.xml. It will contain the entityID and credentials generated by the installation process. Whether that file is ever used is a very deployment-dependent question because it depends on whether you are participating in a "federation" or not, and how that federation handles the collection of metadata from the participants. As a general rule, it's a good idea to have an accurate metadata file available that describes your deployment accurately. You should take the time to understand the metadata structure and content, and change or add to it as required as you make changes to your system. |
...
- 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.
| Tip | ||
|---|---|---|
| ||
The Shibboleth IdP software does not currently support this feature, though newer versions do include a partial implementation that happens to respond to standard messages on front-channel bindings and that can be advertised with such endpoints. |
Documenting Identifiers
An IdP can identify specific "formats" of SAML name identifiers that it supports by listing each supported Format URI inside a <md:NameIDFormat> element.
| Tip | ||
|---|---|---|
| ||
This isn't used at all by the Shibboleth SP software, and does not impact the IdP's own processing. |
Single Sign-On Services
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.
...
| title | Shibboleth-Specific Tip |
|---|
...
.
...
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 |
|---|
...
.
...
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.
| Tip | ||
|---|---|---|
| ||
This isn't used at all by the Shibboleth SP software, and does not impact the IdP's own processing. |
Examples
These examples are written to reflect the typical default configuration of a Shibboleth IdP, but obviously specifics can vary. Note that it's very important that what you support match what you advertise. For example, if you don't support artifact resolution (perhaps because of IdPStatelessClustering), then don't advertise it.
...