The Metadata topic covers the general structure of metadata for any entity. This topic will specifically cover the parts that describe an SP. This is an overview of how to create metadata about an SP, which you will give to an IdP. If you're looking for the reverse, that's here.
| Tip | ||
|---|---|---|
| ||
When first starting out, you can usually begin by relying on the SP software to generate an initial set of metadata about itself, once you've configured it, by accessing a URL like This will only help if you've already configured the SP's entityID and credentials, and properly established the web server's virtual hostname information. Even then, it may not be exactly what you need, but it should be helpful to look at and edit from. |
...
| Tip | ||
|---|---|---|
| ||
This isn't used all that often for Shibboleth SPs, which tend to be more attribute-centric in the use of SAML, but the Shibboleth IdP software can utilize this information in its format selection process. It cannot be generated for you by the SP's metadata generator. It would need to be manually added, or if you want it included in the generated metadata, a "template" metadata file containing the information has to be supplied to the generator with the |
Assertion Consumer Services
...
Each "service" is expressed using an <md:AttributeConsumingService> element that contains descriptive elements and a list of <md:RequestedAttribute> elements (based on type saml:AttributeType) that identify required or optional attributes and/or values.
...
| title | Shibboleth-Specific Tip |
|---|
...
.
Examples
These examples are written to reflect the typical default configuration of a Shibboleth SP, but obviously specifics may vary. Note that it's very important that what you support match what you advertise. For example, if you have not properly integrated single logout into your application and user interface, then don't claim to support it.
...