CAS Bridge Setup - REV 2.0

Overview 

The Cirrus CAS Bridge supports service providers requiring the CAS protocol. This document reviews setting up your Cirrus Bridge for authentication using the CAS protocol. 

Cirrus Conditional Access is a feature that allows the Cirrus Bridge to authenticate users against specific Azure AD (AAD) or Okta apps based on which service provider (SP) is making the request. Cirrus Conditional Access allows customers to control attribute naming, attribute release, cas:user attribute mapping, signing and encryption settings, and MFA requirements from the Azure or Okta administrative portal.

This feature is driven through API access. The Cirrus Bridge will communicate with Azure or Okta to learn about the applications and send users to the correct one for authentication.

Allow Cirrus Bridge API Access

The process for allowing the Cirrus Bridge API access will vary depending on the IdP environment. 

Log into the Azure or Okta portal. Follow the “Azure Bridge Setup” or “Okta Bridge Setup” instructions under “Allow Cirrus Bridge API Access.”

• Allow Cirrus Bridge Azure API Access 

• Allow Cirrus Bridge Okta API Access

Note: Cirrus' back channel CAS (Central Authentication Service) service requires that all validate calls made to it must use the TLS 1.2 (Transport Layer Security version 1.2) protocol.

Configure the Cirrus CAS Bridge Application

The Cirrus Bridge’s conditional access features allow you to customize the login requirements, attribute release, signing and encryption settings for different relying parties. 

You can add multiple Cirrus Bridge applications using different Identifier URI/Entity IDs - see table below:

About Conditional Access Settings for CAS

Note: <<name>> will be provided for you by Cirrus. 

Common Settings for all CAS Applications

All Cirrus CAS Bridge applications will use the same Redirect URI / Single Sign On / Reply URL 

This is the pattern for the Redirect URI / Single Sign On / Reply URL:

https://<<name>>.proxy.cirrusidentity.com/module.php/saml/sp/saml2-acs.php/<<name>>_proxy

If using a temporary Cirrus Bridge for testing, an additional URL may be required with the following pattern:

https://<<name>>-temp-bridge.proxy.cirrusidentity.com/module.php/saml/sp/saml2-acs.php/<<name>>-temp-bridge_proxy

Okta customers should also remember to add CAS applications to the “Cirrus” group so that the API can access them.

Step 1 - Add Application

Log into the Azure or Okta portal. Follow the “Azure Bridge Setup” or “Okta Bridge Setup” instructions under Step 1 - Add Application.

Step 2 - Attribute Mapping 

The process to set up attribute release is outlined in the “Azure Bridge Setup” or “Okta Bridge Setup” instructions under Attribute Release.

Note that the attributes that must be released to SAML service providers will differ from those required for CAS service providers.

Each App used for CAS, must define at least an attribute called “cas:user”. The Bridge will use this to identify the end user to the downstream application.

You can configure the names and values for other attributes to be released in the CAS ticket as required by the relying parties.

Step 3 - Signing Response 

Follow the “Azure Bridge Setup” instructions under Set Signing Settings or “Okta Bridge Setup” instructions under Set Signing Response.

Step 4 - Set Encryption Settings 

Follow the “Azure Bridge Setup” instructions under Set Encrypted Settings or “Okta Bridge Setup” instructions under Set Signing Response.

Note: The specific encryption settings and configuration options may depend on the version of CAS being used and the underlying infrastructure.

Step 5 - MFA 

For applications that require MFA follow the “Azure Bridge Setup” or “Okta Bridge Setup” instructions under MFA.

Step 6 - Assigning Access

Before you can use the Cirrus Bridge, you will need to assign access. Once again, follow the “Azure Bridge Setup” or “Okta Bridge Setup” instructions as appropriate. 

Once complete, you can configure CAS RPs and test your integration.

CAS RP Configuration Integration

Once the CAS application is configured, the following URLS can be used to validate login and configure applications. 

• CAS /login URL: https://<<name>>.proxy.cirrusidentity.com/cas/login

• CAS /serviceValidate URL:

https://<<name>>.proxy.cirrusidentity.com/cas/serviceValidate

• CAS/validate URL https://<<name>>proxy.cirrusidentity.com/cas/validate
• CAS/samlValidate URL https://<<name>>.proxy.cirrusidentity.com/cas/samlValidate

Testing 

If you want to test CAS RPs against the temporary bridge, adjust the CAS configuration URLs to point to the temp bridge. Cirrus Customer Success will provide the FQDN to use for testing.

To test the connection between the Prod CAS Cirrus Bridge and a CAS application, add the following parameter at the end of the URL:    &debugMode=true

Example

https://<<name>>.proxy.cirrusidentity.com/cas/login?service=<<serviceURL>>&debugMode=true

You will need to encode the <<serviceURL>>.  For instance, the serviceURL “http://localhost/configCommon” encoded looks like:

http%3A%2F%2Flocalhost%2FconfigCommon%0A

Many tools are available to encode URLs; here is one of them.

urlencoder.org

This test is helpful to see the cas:user value as well as other attributes you have set up to be released. Here is an example of a response:

© Copyright Cirrus Identity, Inc.