...
| 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. |
...
If your IdP supports SAML 2.0 Single Logout, you will need to include one or more <md:SingleLogoutService> endpoint elements in the metadata.
...
...
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.
...
| 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.
...