DNS Add-On for Cirrus Bridge with CAS

Table of Contents

Objective

What is the DNS Add-On?

Recommended Usage

Advantages of using DNS Add-On with CAS

Disadvantages of using DNS Add-On with CAS

Background - DNS

Background - CAS

Technical details of Cirrus Bridge DNS Add-On

Testing when using DNS Add-On for CAS

Closing remarks

Objective

The objective of this article is to discuss the choices and the value of using the Cirrus Bridge DNS Add-On to migrate an existing Central Authentication Service (CAS) Web Single Sign-On (Web SSO) deployment. This article will:

What is the DNS Add-On?

The DNS Add-On for the Cirrus Bridge supports migrating authentications from an existing SAML V2 or CAS deployment (such as Shibboleth, simpleSAMLphp, Apereo CAS, Ping, Gluu, Fischer, NetIQ, or Ellucian EIS/Ethos) to the Cirrus Bridge without changes to the configured Service Providers (including all federated SPs). This enables faster and lower effort transitions to the Cirrus Bridge by eliminating the need for Application Administrators to change Service Provider configuration.

The DNS Add-On is a pattern of configuration for the Cirrus Bridge that allows:

1. Operation with an unchanged fully qualified domain name (FQDN)

2. Presentation of valid Transport Layer Security (TLS) certificates

3. Operation with an unchanged SAML signing certificate (applies to SAML V2 only) 

Recommended usage

Cirrus Identity generally recommends the DNS Add-On with CAS for customers who have:

1. 10 or more production CAS Service Providers

2. A good inventory of the business critical service providers

3. An end user community that will allow for a rollback and re-attempt if an initial deployment discovers an issue during the change window

4. Test instances for all business critical service providers

5. Service stakeholders that are willing and able to test the business critical service providers

Every customer organization is different and there are situations where it may not be appropriate to use the DNS Add-On. Each has an existing deployment with unique complexity, and also an existing risk tolerance associated with the organization’s culture. Customers should consult with Cirrus Sales or Cirrus Customer Success when planning a Cirrus Bridge CAS deployment to determine if the DNS Add-On is appropriate for a customer’s specific environment. 

Advantages of using DNS Add-On with CAS

There are a number of advantages to using the DNS Add-On with the Cirrus Bridge for CAS: 

1. The implementation effort is reduced because the production service providers do not need to be individually reconfigured

2. The implementation timeline is reduced because there is not the need to schedule and deploy changes for each production service provider

3. There is one change window for production services which reduces the communication and disruption for service users

4. Fees are avoided for any Service Providers where there is a re-configuration fee associated with changing CAS

For customers migrating to the Cirrus Bridge from an existing CAS deployment with a significant number of production service providers (for example 10 or more), these advantages are generally significant. While these advantages are present for any CAS deployment, if the number of service providers is small, the advantages must be weighed more carefully against the disadvantages that follow.

Disadvantages of using DNS Add-On with CAS

The following are disadvantages of using DNS Add-On that can introduce risk into the deployment:

1. Using the DNS Add-On is a “big success” deployment pattern – it is not possible to selectively move CAS services to the Cirrus Bridge

2. Under typical deployments, it is not possible to deploy the Cirrus Bridge for SAML and CAS at different times – if the existing deployments share a FQDN, they must move at the same time because of the DNS dependency

3. It is not generally possible to test against production Service Providers because of the CAS backchannel – to perform any testing, there must be a test instance of the Service Provider that can be reconfigured, or the production service must be temporarily reconfigured during a change window

4. The DNS Add-On with CAS doesn’t avoid all Service Provider re-configuration – to test, some test Service Providers must be changed 

There are risks associated with any service change. The Cirrus Bridge with DNS Add-On for CAS is no different. The following sessions go into background and technical detail to justify the Cirrus Identity recommendation.

Background - DNS (1)(2)

The Domain Name System (DNS) is a fundamental protocol of the internet that translates user-friendly domain names into IP addresses, enabling seamless communication between devices across the network. Acting as a digital phone book, DNS facilitates the browsing experience by eliminating the need to remember complex numerical IP addresses associated with each website. The DNS system serves as the backbone of the internet, ensuring efficient and user-friendly communication by translating memorable domain names into the numerical IP addresses necessary for data exchange.

The Windows, macOS, and Linux operating systems also contain a system configuration file called "/etc/hosts". It maps hostnames to IP addresses, allowing the local system to resolve domain names to specific IP addresses without querying a DNS server.

When a user enters a domain name (for example websso.example.edu) in a web browser, that domain name needs to be resolved. Typically the DNS system comes into play. The browser sends a query to a DNS resolver configured for the operating system. The resolver then communicates with authoritative DNS servers responsible for storing and managing the IP address associated with the requested domain.

Common operating systems also still support the /etc/hosts file. This allows a person to locally modify the mapping of a domain name to an IP address in the /etc/hosts file. This provides a practical testing method for Web Single Sign-On (Web SSO) protocols such as SAMLV2 that use the end user’s web browser for all communication. We will come back to this, but first we need to talk about the Central Authentication Service (CAS) Web SSO protocol. 

(1) Edited from ChatGPT (GPT 3.5) response to prompt “200 words describing domain name service” 2023-08-25 at 7:30 PDT

(2) Edited from ChatGPT (GPT 3.5) response to prompt “describe /etc/hosts file in two sentences” 2023-08-25 at 7:49 PDT

Background - CAS (3)

The Central Authentication Service (CAS) is a Web SSO protocol widely used for web applications and services. CAS provides a seamless way for users to access multiple applications with a single set of credentials, enhancing user experience and security. CAS operates based on a trust relationship between the CAS server and the applications it serves.

When a user attempts to access a CAS-protected application, they are redirected to the CAS server for authentication. The CAS server prompts the user to enter their credentials (username and password). Upon successful authentication, the CAS server generates a unique ticket and sends it back to the application.

The application directly contacts the CAS server with the received ticket to validate its authenticity. Once verified, the user is granted access to the application. The ticket is usually valid for a single use and has a short lifespan, enhancing security. The backchannel communication between the CAS server and the application does not pass through the end user’s web browser. This backchannel communication presents a problem when testing the DNS Add-On with CAS.

An example of a basic CAS Web SSO flow is as follows:

The following is a description of the actions taken at each step:

1. The user attempts to access the application

2. The application uses its configuration to redirect the end user to the CAS login URL (for example https://websso.example.edu/cas/login)

3. The end user is redirected to the CAS login URL which DNS determines is located at IP address 192.168.1.1

4. The CAS server authenticates the end user, creates a CAS ticket, and redirects end user with the ticket ID back to the application

5. The end user is redirected back to the application with the CAS ticket ID

6. The application uses its configuration to validate the ticket by sending a request to the CAS serviceValidate URL (for example https://websso.example.edu/cas/serviceValidate) - in the process DNS determines the FQDN is located at 192.168.1.1

7. The CAS server verifies it has a valid ticket for the end user and responds to the application with attributes associated with the user

8. The application uses the attributes to establish an application session and provides access to the end user

(3) Edited from ChatGPT (GPT 3.5) response to prompt “200 words Central Authentication Service (CAS) Web SSO protocol” 2023-08-25 at 7:34 PDT

Technical details of Cirrus Bridge DNS Add-On (4)

The DNS Add-On is a pattern of configuration for the Cirrus Bridge that allows:

1. Operation with an unchanged fully qualified domain name (FQDN)

2. Presentation of valid Transport Layer Security (TLS) certificates

3. Operation with an unchanged SAML signing certificate (applies to SAML V2 only) 

The first item requires more explanation. Most Web SSO protocols function by exchanging HTTP protocol messages between endpoints at defined URLs that contain fully qualified domain names (FQDN). For example https://websso.example.edu/cas/login might be the URL configured to initiate CAS login. Such URLs are contained in metadata or in application configurations for each Service Provider. To avoid changing the configuration of each Service Provider, when fully deployed the Cirrus Bridge with DNS Add-On uses DNS CNAME (Canonical Name) records to direct traffic that was going to the existing Web SSO deployment to the Cirrus Bridge instead. 

DNS CNAME records are used to create an alias for a fully qualified domain name, allowing one domain name to be associated with another domain's IP address. When a CNAME record is queried, the DNS resolution process resolves to the target domain's IP. This allows the Cirrus Bridge to take the place of the existing Web SSO deployment without Service Providers needing to make configuration changes.

An example of the CAS Web SSO flow using the Cirrus Bridge with DNS Add-On is as follows:

The steps for this flow are the same as those in the CAS background section. The only difference is when DNS is resolving the IP address for the CAS protocol URLs, it follows the CNAME record which points to a Cirrus alias which leads to IP addresses for the Cirrus Bridge.

(4) Edited from ChatGPT (GPT 3.5) response to prompt “describe DNS CNAME records in two sentences” 2023-08-25 at 13:21 PDT

Testing when using DNS Add-On for CAS

Any deployment of the Cirrus Bridge for customers with existing Web SSO  involves a certain amount of testing. This ensures the attribute release and other aspects of Web SSO have been properly migrated from the existing deployment to the Cirrus Bridge based deployment. When using the DNS Add-On, this testing has to occur in a way that doesn’t disrupt the existing production Web SSO deployment.

For Web SSO protocols that exchange HTTP requests and responses that only pass through the end user’s web browser (for example SAML V2), testing with the DNS Add-On can be accomplished very effectively. The end user workstation is locally modified to have a mapping for the FQDN from the existing server that points to an IP address of the Cirrus Bridge.

For Web SSO protocols that exchange messages over a back channel, the method of editing the /etc/hosts file isn’t effective. Not only do you have to override the DNS resolution at the end user workstation, but also at the Service Provider infrastructure. Very often such modifications aren’t practical. 

As already discussed, CAS is a Web SSO protocol with a backchannel. If testing is attempted by just editing the /etc/hosts file on the end user workstation, the protocol fails to authenticate the end user. This is because the CAS ticket for the end user is generated at the Cirrus Bridge, but when the application attempts to validate the ticket, it looks to the existing CAS server which has no knowledge of the ticket. The following illustrates the problem: 

To avoid this problem, an alternate method of testing is used when the Cirrus Bridge is deployed for CAS with the DNS Add-on. To facilitate testing before the actual DNS Add-on cutover, Cirrus Identity deploys a temporary bridge (Temp Bridge) that shares the same configuration as the production Cirrus Bridge. The Temp Bridge has CAS /login and /serviceValidate URLs that are distinct from the existing FQDN - thus are not dependent on the CNAME record being in place. 

For example, if the CAS /login URL in the existing deployment is https://websso.example.edu/cas/login, the Temp Bridge might have a CAS /login URL something like https://example-temp-bridge.proxy.cirrusidentity.com/cas/login. This does require the customer to both have and reconfigure test instances of key applications to use these Temp Bridge URLS. The following illustrates this approach: 

The steps for this flow are the same as those in the CAS background section. The only change is the Test application was reconfigured to use the CAS URLs for the Temp Bridge. The paths in blue reflect the unchanged production configuration and the paths in green reflect the changed configuration.

Cirrus customers have also tested against production CAS instances by scheduling a change window for the service, re-configuring to use the Temp Bridge, testing, and then reverting back to the production configuration. 

Closing remarks

This article provides a recommendation for when the DNS Add-On for Cirrus Bridge with CAS should be used, the advantages and disadvantages of using it, and technical details to support the recommendation. 

As stated in the recommendation, every customer organization is different and there are situations where it may not be appropriate to use the DNS Add-On. Customers should consult with Cirrus Sales or Cirrus Customer Success when planning a Cirrus Bridge CAS deployment to determine if the DNS Add-On is appropriate for a customer’s specific environment.