Configuring Cirrus Bridge with Azure AD REV 7.1 Table of Contents Overview Allow Cirrus Bridge...
CAS Bridge Setup - REV 2.0
Setting up the Cirrus CAS Bridge
Table of Contents
- Allow Cirrus Bridge API Access
- Configure the Cirrus CAS Bridge Application
- CAS RP Configuration Integration
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.
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
Identifier URI/Entity ID
Default CAS configuration
Create an application to be used as the default for CAS requests
A grouping of CAS RPs with alternate attribute requirements
You will need to create an additional application for CAS applications that do not have the same attribute requirements as the default CAS configuration.
Pick an Entity ID of the form https://<<domain>>/cas-bridge/<<some-appid>>
<<some-appid>> should be a label meaningful to you (e.g., banner.)
Share the Entity ID you selected with Cirrus and let them know which CAS service urls or url patterns should be associated with the Entity ID.
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:
If using a temporary Cirrus Bridge for testing, an additional URL may be required with the following pattern:
Okta customers should also remember to add CAS applications to the “Cirrus” group so that the API can access them.
Step 1 - Add Application
Step 2 - Attribute Mapping
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
Step 4 - Set Encryption Settings
Note: The specific encryption settings and configuration options may depend on the version of CAS being used and the underlying infrastructure.
Step 5 - MFA
Step 6 - Assigning Access
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:
- CAS/validate URL https://<<name>>proxy.cirrusidentity.com/cas/validate
- CAS/samlValidate URL https://<<name>>.proxy.cirrusidentity.com/cas/samlValidate
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
You will need to encode the <<serviceURL>>. For instance, the serviceURL “http://localhost/configCommon” encoded looks like:
Many tools are available to encode URLs; here is one of them.
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.