| Note | ||
|---|---|---|
| ||
This document contains DRAFT material intended for discussion and comment by the InCommon participant community. Comments and questions should be sent to the InCommon participants mailing list (participants@incommon.org). |
Planning for a New IdP in Metadata
| Div | ||
|---|---|---|
| ||
|
Are you planning to register an IdP in the InCommon Federation? This document addresses a set of topics that are best considered in advance, before registering the actual IdP metadata.
Contents:
| Table of Contents | ||
|---|---|---|
|
Designated Site Administrators
...
The importance of a secure, automated metadata refresh process can not be over-emphasized. All participants are strongly encouraged to configure their software to refresh and verify metadata at least daily. An optimal process will attempt to refresh metadata every hour and will intelligently short-circuit that attempt if the metadata file has not changed on the server. This The latter is done accomplished using a technique called HTTP Conditional GET.
Read more about Metadata Consumption...
...
A secure web server typically protects its browser-facing resources with TLS. To obtain a trusted TLS certificate, an administrator issues a Certificate Signing Request (CSR) to a trusted CA. In doing so, a private TLS key is generated. This key must be generated securely and kept safe for the entirety of its lifetime. See: entire lifetime of the server.
Read more about TLS Server Certificates...
A SAML IdP is a secure web server that issues SAML assertions to SPs upon request. Assertions are signed by the IdP for authenticity and integrity. The IdP administrator generates a private signing key for this purpose. (The corresponding public key is bound to a long-lived, self-signed certificate published in SAML metadata.) Like the TLS key, the signing key must be generated securely and kept safe indefinitely. A compromised IdP signing key is the absolute worst thing that can happen in a federated context. See:
Read more about IdP Key Handling...
Develop a strategy for securing your private keys before you generate them. Avoid moving them around unnecessary exposure by generating the keys on the IdP in the first place. Strictly control access to the IdP system on which the keys are stored. Keep the IdP software and the underlying operating system software patched and up to date.
Use of Primary Domain
An organization's primary domain is a critical piece of information used repeatedly in metadata.
Read more about an organization's Primary DNS Domain...
Entity ID
The entityID is an identifier for your IdP. Although it is almost always a URL, an entityID is a name (not a location). One of your first (and perhaps most important) tasks is to choose an a permanent entityID in a namespace you owncontrol. Thus the host part of the chosen URL must be rooted in a DNS name you own control (as indicated in the whois database or via a Domain Control Validation process administered by the Registration Authority (InCommon)). Almost This is almost always this is the primary domain of your organization.
Example. Suppose your primary domain is example. edu. In this case, your IdP entityID might be: https://sso.example.edu/idpwhere the primary domain is example.edu
Choose your entityID carefully—you may not get a second chance. Once an entityID is released into the wild, it will be difficult to change, at least not without a lot of pain.
Read more about Entity IDs in metadata...
...
A Scope is a suffix appended to so-called scoped attributes (such as eduPersonPrincipalName) that . The attribute's Scope indicates the asserting IdP, which is why the best Scope value is the primary domain of the organization.. Since these scoped attributes are typically used for access control at the SP, they are likewise difficult to change once released into the wild. That's why the best Scope value is the primary domain of the organization. If that changes…well, let's hope that doesn't happen.
| Tip |
|---|
Avoid multiple Scopes in metadata. |
Read more about Scope in Metadata...
...
Each of the SAML endpoints published in metadata has a location. Some of these endpoints are browser-facing, so there are branding issues to consider. Choose and so you should choose a logical hostname that makes sense to the user. This hostname need not agree with your entityID (which is a name, not a location) but in any case, the chosen hostname should be rooted in your primary domain for security, usability, and stability.
Read more about IdP Endpoints in metadata...
...
| Tip | ||
|---|---|---|
| ||
|
Read more about recommended Protocol Support for New IdPs...