Effective federation depends on IdPs that are both interoperable and trustworthy. To this end, a new IdP is expected to satisfy certain requirements. Some of these requirements are operational while other requirements pertain to the IdP's entity descriptor in metadata. IdP metadata will not be approved before these requirements are met.
As a matter of policy, each organization is allowed one IdP entity descriptor in metadata. By request, a second IdP in metadata may be purchased for an extra $1,000 per year.
The first IdP an organization introduces into metadata is assumed to be a production IdP. Do not submit temporary IdP metadata with the intention of changing it later on. IdP metadata that is obviously temporary (e.g., that contains the substring "test" in names and locations) will not be approved.
An optional second IdP may be introduced into metadata. This second IdP may be a test IdP.
Test IdPs in Metadata
Test IdPs in metadata serve little or no purpose. Since test IdPs are difficult to distinguish from production IdPs, the use of test IdPs in metadata is discouraged.
The following are true of all IdP entity descriptors in metadata:
- The entity ID for an IdP in metadata is permanent and once established can not be changed. (Although the Federation Manager currently allows the entity ID to be changed, such an update request will not be automatically approved by the RA.)
- By default, the display name for a production IdP is the name of the organization that signed the Participation Agreement. The display name for a test IdP is usually some variation on the production display name. In both cases, the RA is authoritative for display names in IdP metadata since the names of IdPs appear on the discovery interface.
- Choose your IdP endpoints carefully. The endpoint locations in IdP metadata are permanent in the sense that changing them will break interoperability with partner SPs. To restore interoperability with your IdP, each SP must refresh metadata.
All new IdPs in metadata are subject to the following requirements:
- The IdP MUST support the SAML V2.0 HTTP-Redirect binding, one of numerous endpoints in metadata.
- The IdP SHOULD provide a Logo and an Information URL, two important user interface elements in metadata.
- The IdP MUST provide technical and administrative contacts in metadata.
- The IdP SHOULD provide an error handling URL in metadata.
The following operational requirements help to ensure the trustworthiness of your IdP:
- The IdP MUST refresh and verify metadata at least daily.
- The IdP MUST ensure that its private signing key is safe and secure.
- All IdP endpoints MUST be protected by SSL/TLS.
Safeguarding the IdP's private key protects all Federation participants from the disastrous consequences of a key compromise.