Community Review in progress!
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
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:
Designated Site Administrators
One of the first things a prospective Federation participant should do is designate at least two Site Administrators to manage metadata. Beyond the obvious advantages of having a trained administrator for backup purposes, multiple Site Administrators has security advantages as well. Like password changes, metadata updates generate email notifications to all designated Site Administrators, which helps prevent both honest mistakes and malicious activity.
Metadata Refresh
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 is done using a technique called HTTP Conditional GET.
Read more about Metadata Consumption...
Key Generation
A secure web server typically protects its 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: 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. 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: IdP Key Handling
Develop a strategy for securing your private keys before you generate them. Avoid moving them around 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
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 entityID in a namespace you own. Thus the host part of the chosen URL must be rooted in a DNS name you own (as indicated in the whois database). 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/idp
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...
Scope
A Scope is a suffix appended to so-called scoped attributes (such as eduPersonPrincipalName) that indicates the asserting IdP. Since these 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.
Avoid multiple Scopes in metadata.
Read more about Scope in Metadata...
Endpoint Locations
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 a logical hostname that makes sense to the user. This hostname need not agree with your entityID (which is a name) 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...
Protocol Support
The following deployment strategy forces all protocol traffic over the front channel, which is easier to troubleshoot, manage, and maintain.
Recommended Protocol Support for New IdPs
- DO support SAML2 Web Browser SSO on the front channel
- DON’T support back-channel SAML protocols
Read more about recommended Protocol Support for New IdPs...