Bridge | Using Cirrus Bridge


Because of how it works, the Cirrus Bridge is implemented between an Organization’s authentication source and SAML or CAS enabled Service Providers. The most common authentication sources are Azure Active Directory and Okta, but any of the following may be used:

  • Azure Active Directory (Licensed at the Free, Basic, Office365, or Premium P1/P2 levels)

  • Okta

  • Google GSuite

  • Slate

  • Other options we can support include: On-prem Active Directory, OneLogin, LDAP, RDMS (Professional Services May Apply)

Cirrus Bridge Setup in Authentication Source

To integrate the Cirrus Bridge with an authentication source, Cirrus Identity will provider customers will instructions depending on the authentication source (See Cirrus Bridge getting started for more details). At a high level, each side will need to exchange some information:

The Cirrus Bridge

The Authentication Source will need a handful of parameters from the Organization’s Bridge instance:

  • EntityID — https://<<domain>>/bridge

  • Reply URL — https://<<name>><<name>>_proxy

There will also be a testing URL that can be used to test the connectivity between the authentication source and the Bridge:

  • Test URL — https://<<name>><<name>>_proxy

The Cirrus Bridge will need metadata from the Authentication Source (see the next section).

The Authentication Source

As indicated above, Cirrus Identity will provide detailed instructions based on the Authentication Source. In most cases, the integration will involve defining some type of “application” or “service provider” in the Authentication Source. Examples of this for Azure AD and Okta are as follows:

Azure Active Directory Free / Basic / Office365


Azure Active Directory Premium P1 / P2




To provide the metadata, each Authentication Source will have a slightly different procedure. The details will be covered in the instructions provided by Cirrus Identity. Examples of the metadata access for Azure AD and Okta are as follows:

Azure Active Directory Free / Basic / Office365


Azure Active Directory Premium P1 / P2




Cirrus Bridge and Federations

One of the primary uses of the Cirrus Bridge is to enable an Organization’s main authentication source to be registered in a multi-lateral trust federation such as InCommon or one of the other eduGAIN federations. Cirrus Identity supports both migrating a previously registered Identity Provider or registering your Bridge as a new federation IdP (see Cirrus Identity planning steps for more details).

If you will be registering as a new IdP, Cirrus Identity will provide you with some additional information so you have what you need to do the registration. For example, if you will be registering with InCommon, we will provide you with:

  • The IdP entityID

  • Attribute scope (this will generally be your organization’s domain)

  • Single Sign-On Service URL

  • Certificate

For InCommon registration, you will also need the following:

  • A logo URL

  • Contact information for an administrative, technical, and security contact

  • A privacy policy URL

You can access the InCommon Federation Manager from the main InCommon website.


Cirrus Bridge and Service Providers

By default, the Cirrus Bridge will be configured to release the REFEDS Research and Scholarship attribute bundle to any service provider properly marked in eduGAIN metadata (including InCommon metadata). If this is not the desired behavior for your Bridge and/or you need other attributes released, additional attribute policies can be configured by contacting Cirrus Support. If you need to have your Bridge access Service Providers that are local to your organization, or are not registered with InCommon or an eduGAIN federation, custom metadata can be configured by contacting Cirrus Support. See Cirrus Bridge getting started for an overview of this process.