New IdPs in Metadata

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 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 functional backup administrator, multiple Site Administrators has security advantages as well. Like password changes, metadata updates generate email notifications to all designated Site Administrators, which helps prevent 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 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.

Key Generation

A secure web server 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 private keys on the IdP in the first place. Strictly control access to the IdP system. Keep the IdP software and the underlying operating system software patched and up to date.

Primary Domain

1. Choose your entityID carefully
   1. a simple, generic name is best
      1. example: https://sso.example.edu/idp
   2. hostname must be rooted in your primary domain (e.g., example.edu)
   3. hostname need not match endpoint locations
2. Choose your Scope carefully
   1. usually equal to your primary domain
   2. used to construct eduPersonPrincipalName
   3. avoid multiple Scopes in metadata

Protocol Support

The following optimizations force all traffic over the front channel, which is easier to troubleshoot, manage, and maintain:

1. Do not support the SAML1 protocol
2. Do not support attribute query
3. Do not support SOAP-based endpoints

Read more about recommended Protocol Support for New IdPs...