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.