InCommon Identity Provider Deployment Guide
Recommended server configurations for Identity Providers (IdPs):
The Shibboleth Identity Provider software has two services, the Handle Service (HS) and the Attribute Authority (AA). The HS is accessed by end users authenticating at the Identity Provider, and so generally uses a certificate issued by a CA chosen by the IdP organization, typically one of the public CAs whose root certificates are provided with common browsers. For InCommon, the AA must use a certificate issued by the InCommon CA. For this reason the HS and AA should not generally be run on the same web server. Note that the HS also needs a certificate issued by the InCommon CA that is used to sign SAML authentication assertions.
One approach is to configure different server names for the HS and AA services, such as "aa.it.example.edu" and "hs.it.example.edu". In this case the IdP would request a certificate from the InCommon CA for each of these names. The AA certificate is used for the SSL web server on the AA server, while the HS cert is used for assertion signing. Note that it is possible to operate two (or more) named services on a single physical server using virtual hosting.
Another approach is to configure the AA to operate on a different port than the HS (the HS must always be run on the standard https port, 443). If this is done, the AA must be run on port 8443 (this is to make firewall configuration easier for InCommon Service Providers). In this case the IdP organization only requests one certificate from the InCommon CA.
Another consideration is server redundancy. It is suggested that production IdP configurations use redundant physical servers (two or more) for each of the HS and AA services, so the services can be resistant to single-server failure. The recommended approach is to use standard redundancy methods such as DNS load-balancing or load-balancing network devices, which permit multiple servers to use one DNS name. In this case only one certificate is needed from the InCommon CA per service.
Another approach is to register multiple server names for the HS and AA services, such as "aa1.it.example.edu" and "aa2.it.example.edu". InCommon can register multiple names for a IdP's services. If multiple server names are used for the AA, an InCommon CA certificate would be requested for each name.
Organization Domain Name (e.g., example.edu):
The name used here is typically the top-level domain name used by the Identity Provider organization, such as "example.edu" or "regional-campus.example.edu". This name is used in the "scope" that appears in standard Shibboleth-provided attributes for the organization's users, such as "member@example.edu" or "someuser@regional-campus.example.edu". Since this name will be widely visible to other InCommon participants, it is important to choose it carefully. Contact incommon-admin@internet2.edu with questions.
In some cases it is useful for an InCommon IdP to register more than one organization name, in order to assert attributes with multiple scopes. For example, a central campus, example.edu, may also handle users for a branch campus, branch.example.edu, and so assert attributes such as "member@branch.example.edu" for some users. Contact incommon-admin@internet2.edu about setting this up.
For more information or questions about the technical requirements for InCommon please send mail to: incommon-admin@incommonfederation.org