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.”
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.
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:
|
Application |
Identifier URI/Entity ID |
Description |
User Visible |
|
Default CAS configuration |
https://<<name>>/cas-bridge |
Create an application to be used as the default for CAS requests |
No |
|
A grouping of CAS RPs with alternate attribute requirements |
https://<<name>>/cas-bridge/<<some-appid>> |
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. |
No |
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.
Log into the Azure or Okta portal. Follow the “Azure Bridge Setup” or “Okta Bridge Setup” instructions under Step 1 - Add Application.
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.
Follow the “Azure Bridge Setup” instructions under Set Signing Settings or “Okta Bridge Setup” instructions under Set Signing Response.
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.
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.
Once the CAS application is configured, the following URLS can be used to validate login and configure applications.
https://<<name>>.proxy.cirrusidentity.com/cas/serviceValidate
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.
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.