...
Most of the actual text and examples in this template should not appear in the final documents, but please keep the headings and the tip/warning boxes.
| Table of Contents |
|---|
Identity Provider Metadata
Use this section to describe how/whether the service handles provisioning of IdP technical details and trust to the service/application.
...
If they use made-up terminology for referring to things that would be in metadata, define that terminology.
Service Provider Metadata
Use this section to describe how/whether the service handles provisioning of SP technical details and trust to the IdP.
...
If they use made-up terminology for referring to things that would be in metadata, define that terminology.
Profile Requirements
Use this section to describe any specific requirements known about the service's basic interoperation of SAML SSO, including but not limited to:
...
In general, anything (excepting perhaps NameID Format(s)) that you have to configure in relying-party.xml should get a mention here unless it's a local-only need.
Example Shibboleth Configuration
| Tip |
|---|
Refer to the RelyingPartyConfiguration topic and be cognizant that creating overrides for every service is generally an inefficient use of the software. Consider identifying common requirements across services and create overrides tied to multiple services that share those requirements, or that reference profile configuration beans containing common settings. |
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<!-- Container for any overrides you want to add. --> <util:list id="shibboleth.RelyingPartyOverrides"> <!-- other overrides... --> <!-- SPs that required signed assertions but don't indicate that in their metadata. --> <bean p:id="example.SignAssertionsOnly" parent="RelyingPartyByName"> <constructor-arg name="relyingPartyIds"> <list> <value>https://sp.example.org/shibboleth</value> </list> </constructor-arg> <property name="profileConfigurations"> <list> <bean parent="SAML2.SSO" p:signAssertions="true" p:signResponses="false" /> <bean parent="SAML2.Logout" /> </list> </property> </bean> </util:list> |
Account Provisioning
Use this section to outline in general terms (or link to specific documentation) on account provisioning. Details optional, but a general description of assumptions: batch? just-in-time? kind of data generally supplied? limitations on account identifiers?
This is usually needed to motivate/guide the decisions around the data required to pass in SAML.
NameID Requirements
Most commercial applications are oblivious or at least very limited in the use of SAML Attributes, and will expect to receive the "key" to lookup a user account in the NameID element. Describe any known requirements or limitations:
...
Highlight any errors by the vendor (e.g., requiring a particular Format but misusing it such that the data required can't comply with the Format's requirements, causing problems for other integrations).
Example Shibboleth Configuration
| Tip |
|---|
Refer to the NameIDGenerationConfiguration topic for a full treatment of NameID features. |
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<!-- mail only -->
<AttributeFilterPolicy id="mailOnly">
<PolicyRequirementRule xsi:type="Requester" value="https://sp.example.org/shibboleth" />
<AttributeRule attributeID="mail" permitAny="true" />
</AttributeFilterPolicy> |
Attribute Requirements
In cases where SAML Attributes are required or supported, document those requirements here. Important details per-attribute include:
...
Another detail to capture, if known, is whether the SP supports (or not) the use of xsi:type within the <AttributeValue> element. V3 defaults to omitting it through an explicit setting, but most legacy resolver configurations omit the setting and will emit the declaration. Testing by an IdP would reveal whether an SP supports omitting this, and most will.
Example Shibboleth Configuration
Most resolver examples are superfluous, as they illustrate local attribute requirements more than anything to do with SPs, but in cases where an SP requires non-standard attributes, it's acceptable to include examples that might demonstrate how to attach conditions to <AttributeEncoder> plugins to limit their use to an SP.
...