Bridge | Planning Steps

Cirrus Bridge solutions sit between your organization’s commercial identity management (IdM) solution (Azure AD, Okta, OneLogin, Google GSuite, or others) and the applications users need to access. A bit of planning before getting started will go a long way to reducing initial confusion. Consider the following questions:

  1. Is your identity management (IdM) solution supported by the Cirrus Bridge? Cirrus Identity currently supports the following IdM solutions, and will consider supporting any other identity providers that support a bilateral SAML V2 or CAS connection (Professional Services May Apply):

    • Azure Active Directory

    • Okta

    • Google GSuite

    • Slate

    • Other authentication sources such as On-prem Active Directory, OneLogin, LDAP enabled directories, or RDMS based identity stores (Professional Services May Apply)

  2. What are the Service Providers (SPs) that will be accessed using the Bridge?

    • What is the approximate number?

    • Are the SPs registered with InCommon or one of the other eduGAIN federations? -- If not, you will need to share the metadata with Cirrus Identity (we support a variety of options to accomplish this)?

    • Do these SPs all have the same attribute requirements?

    • Do any of the SPs have unique requirements? For example, do any of them us SAML v1 style inline scopes or expect assertions from an IdP with a SAML cert/key that is unique.

  3. What capabilities of your IdM solution do you want to extend with the Bridge?

    • How will attributes be mapped across the Bridge?

    • Is affiliation or entitlement (for example eduPersonAffiliation or eduPersonEntitlement) being used for access control?

    • Will a multi-factor authentication (MFA) solution be integrated?

  4. Will the Bridge be registered with InCommon or one of the other eduGAIN federations?

    • Will this be a new registration or will the Bridge take the place of an existing federated IdP?

  5. Will the Bridge also function as a CAS identity provider?

    • What should ‘cas:user’ be set to?

    • What other attributes should be released with the CAS ticket?

    • What are the CAS service URLs?

    • Do any of the CAS services use proxy mode?

    • Do any of the CAS services rely on a static IP address -- said another way, are there firewall or other network policies that need to be considered?

Next you will want to look at Cirrus Bridge | Getting Started.

Bridge | Getting Started

Unlike many of Cirrus Identity modules, the Cirrus Bridge is usually not provisioned before having a kickoff call, or at least a few email exchanges with customers. In most cases, Cirrus will need organizational information and to confer with you about integration decisions before the Bridge is set up. This does not imply the Bridge has more complexity -- quite the contrary. The Cirrus Bridge is often one of the quickest modules to deploy.

The following are the steps needed to get started using Cirrus Bridge:

  1. Customers should plan out their Bridge deployment. Cirrus Identity can offer generally accepted practices, customer stories, and professional services to help. Reviewing the questions covered by the Cirrus Bridge | Planning Steps is a good first step:

    • Is the organization’s identity management (IdM) solution supported by the Cirrus Bridge?

    • What are the Service Providers (SPs) that will be accessed using the Bridge?

    • What capabilities of your IdM solution do you want to extend with the bridge?

    • Will the Bridge be registered with InCommon or one of the other eduGAIN federations?

    • Will the Bridge also function as a CAS identity provider?

  2. If the Bridge will be registered in InCommon (or another trust federation), does your organization already have an IdP registered with InCommon or another trust federation?

    • If your organization doesn’t have a current registration, has your organization performed the needed administrative procedures to join the federation and has a site administrator been assigned?

    • If your organization does have a current registration, Cirrus Identity offers an add-on service that allows you to transition the existing federation registration to the Bridge. You will maintain your existing entityID and signing certificate in the process. A new TLS certificate will be requested. During setup, Cirrus will work with the organization to securely transfer the cryptographic material during setup of the Bridge.

  3. If the Bridge will need to support Service Providers other than those in InCommon or one of the other eduGAIN federations, Cirrus Identity will need the metadata for those SPs.

    • Generally we ask organizations to provide the SP metadata in a local metadata aggregate that we can consume.

    • If organizations cannot provide an aggregate or there are only a handful of SPs, the metadata can be sent to the Cirrus Support Center.

  4. If the Bridge is a migration from an existing IdP (for example Shibboleth or SimpleSAMLphp), the organization will need to provide certain configuration files to Cirrus Identity to support configuration of the Bridge. The files needed will depend on several factors related to the deployment and will be discussed during the initial kickoff call or email exchange.

    • If there are any SPs that require different SAML certs/keys, are looking for a different IdP entityId, or are looking for SAML V1 style inline scopes, we will configure the integration to accommodate those requirements.

  5. Fairly early in the process, Cirrus Identity will ask the customer to create the needed integration in the organization’s identity management (IdM) solution. For example, both Azure Active Directory and Okta require the organization to create an “application” for the integration. Cirrus Identity will provide vendor specific instructions for the integration. See “Cirrus Bridge Setup in Authentication Source” for examples of this setup.

  6. By default, the Cirrus Bridge is configured to comply with REFEDS Research and Scholarship basic attribute release. If a customer provides an attribute to map to eduPersonAffiliation, we will also include that. We work with customers to configure any additional SAML attribute mapping and release policies as needed and count against the caps defined by the Bridge subscription.

    • Attribute setup will also factor in older style attribute naming requirements specific to SPs.

  7. If the organization is using a multi-factor authentication (MFA) solution, the Bridge can be configured to assert the AuthnContextClassRef as defined by REFEDS MFA standard. Depending on the organization’s IdM solution, some attribute configuration may be required.

  8. If the Bridge is to support CAS services, we will set up an additional “CAS Bridge” for your environment (we offer this at a discounted price for campuses already using our SAML Bridge). You will need to define the “cas:user” value for services, and then send Cirrus Identity authorized service URLs.

    • Because the CAS protocol requires a back channel connection, Cirrus Identity will recommend an additional endpoint for the CAS services. This allows any critical services to be tested ahead of a production deployment.

    • If there are additional attributes to be included with the CAS response ticket, those will need to be mapped.

    • If the Bridge is taking over for an existing CAS installation, the existing configuration will need to be assessed much like the SAML IdP one outlined in Step 4.

  9. Cirrus Identity will work with the organization to put together a testing plan before deployment. This will vary based on the migration needs, number of active service providers, and complexity of existing integrations.

  10. If this Bridge deployment will be a new InCommon (or other federation registration), Cirrus Identity will provide the information and instructions needed for the customer to register their Bridge instance with the federation operator.

Once these steps are complete, you are ready to use Proxy with your service provider.

Bridge | Using Cirrus Bridge

Overview

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>>.proxy.cirrusidentity.com/module.php/saml/sp/saml2-acs.php/<<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>>.proxy.cirrusidentity.com/module.php/core/authenticate.php?as=<<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_basic_add_app.png

Azure Active Directory Premium P1 / P2

azure_premium_add_app.png

Okta

okta_add_app.png

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_basic_metadata.png

Azure Active Directory Premium P1 / P2

azure_premium_metadata.png

Okta

okta_metadata.png

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.

inc_fed_mgr.png

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.