Bridge | Planning Steps

Cirrus Bridge solutions sit between your organization’s commercial identity management (IdM) solution (Azure AD, Okta, Google GSuite, or others) and the applications using it for authentication — the Cirrus Bridge is no different. 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):

    1. Azure Active Directory

    2. Okta

    3. Google GSuite

    4. Slate

    5. Others (Professional Services May Apply)

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

    1. What is the approximate number?

    2. Are the SPs registered with InCommon or one of the other eduGAIN federations -- if not, how will Cirrus Identity get the metadata?

    3. Do these SPs all have the same attribute requirements?

    4. 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?

    1. How will attributes be mapped across the bridge?

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

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

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

    1. Will this be a new registration or will the Bridge take the place of an existing solution?

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

    1. What should ‘cas:user’ be set to?

    2. What other attributes should be released with the CAS ticket?

    3. What are the CAS service URLs?

    4. Do any of the CAS services use proxy mode?

    5. 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, there will be decisions and/or organizational information needed before the Bridge is defined. 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:

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

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

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

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

    5. 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?

    1. 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 be assigned?

    2. If your organization does have a current registration, Cirrus Identity will work with you to transition the existing 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.

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

    2. If organizations cannot provide an aggregate or there is 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.

    1. 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, those will be accommodated with configuration.

  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.

  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, that will also be included. Additional SAML attribute mapping and release policies will be configured as needed and count against the caps defined by the Bridge subscription.

    1. 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, additional configuration will be required. The central item will be the setting of the “cas:user” value for services, and the authorization of service URLs.

    1. 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.

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

    3. 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

Don’t Live With Identity Provider Islands

We all dream of a future where every service talks to your identity management platform as soon as the ink dries on the contract. Our customers have been able to configure our Bridge with their local Identity Provider to join the InCommon federation in less than 2 hours.

Identity Federation in 3 - 2 - 1...

If you need a SAML Identity Provider that plays nicely with InCommon or eduGAIN federation metadata, the Cirrus Bridge can get you there in record time. Our Bridge integrates with popular commercial solutions, like Microsoft Azure AD, to enable easy registration of your identities in popular identity federations. Our Bridge can even speak protocols so you don’t have to, like cases where you have one or more service providers that speak CAS and the rest of your organization is leveraging SAML.

Common Uses

Connect enterprise identities from Azure AD or other commercial identity solutions with federated services (InCommon), without having to run ADFS, or local installations of Shibboleth, SimpleSAMLphp, etc.

Create custom federations to share web-based services among multiple organizations

How It Works

The Bridge adds a tool between your enterprise identities, the federations you want to join, and the services your users need to access.   The Bridge is able to interoperate easily with open source identity provider solutions like Shibboleth and simpleSAMLphp; as well as commercial offerings from Microsoft and others.