Setting up the Cirrus CAS Bridge Rev 2.0 Table of Contents Overview Allow Cirrus Bridge API Access...
Registering Cirrus Bridge with InCommon
Registering Cirrus Bridge with InCommon
Table of ContentsRequirements
- Site Administrator Access
- Cirrus Bridge Parameters for InCommon Registration
- Contact, Policy, and Branding
- Entity ID
- User Interface Elements
- Error URL
- Digital Certificate
- Assertion Choices
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:
- Access to InCommon Federation Manager (https://service1.internet2.edu/siteadmin/) as a “Site Administrator” (SA)
- Some parameters specific to your organization’s Cirrus Bridge deployment
- 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 “firstname.lastname@example.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:
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:
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:
Technical: “email@example.com” or “firstname.lastname@example.org”
Security: “email@example.com” or “firstname.lastname@example.org”
|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.|
|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.
|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.
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.
The wizard will asked for the following contact information for:
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.
The wizard will ask for an error URL – see https://spaces.at.internet2.edu/display/federation/saml-metadata-error-url for details.
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.
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.
The wizard will then ask questions about:
- Supporting R&S – Cirrus recommends checking this box. See https://spaces.at.internet2.edu/display/federation/Declare+R+and+S+support+for+an+identity+provider for details.
- SIRTFI Compliance – This is required to register the IdP. See https://spaces.at.internet2.edu/display/federation/Declare+Sirtfi+compliance for details.
- Exporting Metadata to eduGAIN – Cirrus recommends checking this box. See https://spaces.at.internet2.edu/display/federation/saml-metadata-export-options for details.
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.