Registering Cirrus Bridge with InCommon

Registering Cirrus Bridge with InCommon

REV 2.0

Table of Contents

Requirements
Registering the IdP

Requirements

The Cirrus Bridge can be used with a number of commercial SSO/IdP providers such as Microsoft Azure AD, Okta, Google, or others. To register the Cirrus Bridge as an InCommon Identity Provider, you will need:

  1. Access to InCommon Federation Manager (https://service1.internet2.edu/siteadmin/) as a “Site Administrator” (SA)
  2. Some parameters specific to your organization’s Cirrus Bridge deployment
  3. Some contact, policy, and branding information for your organization

For those organizations that have previously registered with InCommon, it is generally recommended that you update your IdP instead of registering a new one – changing your entityId with InCommon can be very disruptive. However, there are cases where transitioning from one IdP to another is appropriate. The Cirrus Identity Team can be a resource for planning such a move. 

InCommon does support transitioning from one IdP to another, and will require the organization to contact them directly (by submitting a request to “help@incommon.org”) to arrange the transition. As of the Summer of 2022, InCommon will allow up to six months for an organization to move from one IdP to another without additional charges.   

Site Administrator Access

See the following to get access to Federation Manager:

https://spaces.at.internet2.edu/display/federation/federation-manager-requirements

Cirrus Bridge Parameters for InCommon Registration

Once the Cirrus Bridge instance is provisioned, Cirrus will provide parameters to registered the IdP with InCommon. Those parameters will be: 

Setting Example Value Description
EntityID https://sso.example.edu/idp

NOTE 1 – This will be different from the entityID used to integrate the Cirrus Bridge with the source IdP (such as Azure AD or Okta).

NOTE 2 - The entityID used to register does not need to match the fully qualified domain name for the SSO Binding endpoint – in many cases they will be different when deploying the Cirrus Bridge.

The unique ID for the IdP. It must be in your domain. It is usually a bad idea to change it once registered with InCommon (1).
Attribute Scope example.com Generally the root domain for the organization.
SAML2 SSO binding endpoint https://something.example.edu/saml2/idp/SSOService.php The Bridge supports both the HTTP-Redirect and  HTTP-POST for performing Single sign on.
SAML2 SLO binding endpoint https://something.example.edu/saml2/idp/SingleLogoutService.php The Bridge supports advertising a single-logout endpoint, but SLO must also be configured between the source IdP and the Bridge.
Certificate https://something.example.edu/module.php/saml/idp/certs.php/idp.crt The certificate the Bridge IdP uses to sign and encrypt assertions.
errorURL https://something.example.edu/error.php?code=ERRORURL_CODE&ts=ERRORURL_TS&rp=ERRORURL_RP&tid=ERRORURL_TID&ctx=ERRORURL_CTX The errorURL can either be the default page provided by Cirrus Bridge, or a static URL hosted by the organization (2).

(1) There are some cases where registering a new IdP entityId is needed. Cirrus Identity can provide guidance appropriate for an organization's situation.

(2) The default errorURL provided by the Cirrus Bridge supports the basic functionality specified by https://refeds.org/specifications/errorurl-v1

Contact, Policy, and Branding

Before registering, the Site Administrator should also have the following information ready:

Setting Example Value Description
Contacts

Administrative: “alice@example.edu”

Technical: “iam@example.edu” or “support@cirrusidentity.com”

Security: “iso@example.edu” or “security@cirrusidentity.com”

 Contacts for the IdP. The “Administrative” contact should be for your organization. The “Technical” and “Security” contacts can be either for your organization (preferred), or you can use Cirrus Identity support and security contacts as long as you maintain operational and security contacts registered with Cirrus Identity.
Display Name “Example University” The display name from the IdP.
Description “The main identity provider for Example University” A short description for the IdP.
Information URL “https://www.example.edu” A link to provide information about the Identity Provider. Many organizations will either use a main website, or a website that supports access for the organization.
Privacy URL “https://www.example.edu/privacy” A link to a privacy policy that covers the identities asserted by your Azure AD instance. 
Logo “https://branding.example.edu/main_logo.png” An organizational logo hosted on the organization website and directly available from a URL (redirection is not supported by InCommon). The Cirrus Bridge does not support hosting a logo.
Assert R&S support Check box Cirrus recommends asserting R&S support. See https://spaces.at.internet2.edu/display/federation/Declare+R+and+S+support+for+an+identity+provider for details.
Assert SIRTFI compliance Check box

The IdP cannot be registered without SIRTFI compliance.

See https://spaces.at.internet2.edu/display/federation/Declare+Sirtfi+compliance for details.
Exporting metadata to the global eduGAIN federation of federations Check box Cirrus recommends exporting the IdP metadata to eduGAIN. See https://spaces.at.internet2.edu/display/federation/saml-metadata-export-options for details.

Registering the IdP

After logging into the Federation Manager, you should see a button to add an IdP:

This will start a wizard that will ask you for the values needed to register the IdP. Many of these values are required as set by InCommon Baseline Requirements. See https://spaces.at.internet2.edu/display/federation/federation-manager-add-idp for the details of registering a new IdP with Federation Manager. 

Entity ID

The wizard will start by asked for the entityID and scope. Enter the entityID exactly as provided by Cirrus Identity. Once entered, the entityID cannot be changed. If the entityID is entered incorrectly, you will have to delete the registration and start over. See https://spaces.at.internet2.edu/display/federation/saml-metadata-entityid for details.

Contacts

The wizard will asked for the following contact information for:

  • Administrative
  • Technical
  • Security

See https://spaces.at.internet2.edu/display/federation/saml-metadata-contacts for details.

User Interface Elements

The wizard will ask for some user interface elements for the organization. See https://spaces.at.internet2.edu/display/federation/saml-metadata-mdui-elements for details.

Error URL

The wizard will ask for an error URL – see https://spaces.at.internet2.edu/display/federation/saml-metadata-error-url for details.

IDPSSODescriptor

The wizard will ask for HTTP-Redirect and HTTP-POST bindings for the IdP. Use the value provided by Cirrus Identity for both. A single-logout binding may also be provided – use the value provided by Cirrus Identity. See https://spaces.at.internet2.edu/display/federation/saml-metadata-idp-sso-settings for details. 

Digital Certificate

The wizard will ask for the certificate to be used for the SAML protocol. Upload the one provided by Cirrus Identity. See https://spaces.at.internet2.edu/display/federation/saml-metadata-cryptographic-keys for details.

Assertion Choices

The wizard will then ask questions about:

Submit

Once all data has been entered, review and submit the registration to InCommon. Depending on the time of day the submission takes place, the metadata is published by InCommon sometime in the next 24 to 72 business hours. It can take an additional 24 to 48 hours for metadata to propagate to service providers reliant on the global eduGAIN metadata service. See https://spaces.at.internet2.edu/display/federation/Metadata+Service for the latest information on the submission and publishing process.

© Copyright Cirrus Identity, Inc.

Blog comments