CAS Tutorial – FoxDevelop

CAS Implementation

jack — Thu, 06 Aug 2026 08:06:30 +0000

Implementation Idea of Legacy CAS Version

Core Principle (CAS 1.0 Protocol)

User accesses protected page /admin/admin.aspx
web.config permission rules block anonymous users and auto‑redirect to login page CasEnter.aspx
CasEnter.aspx checks whether the URL contains the ticket query parameter

No ticket: Redirect to CAS server login endpoint and pass current site address as service
Ticket present: Call serviceValidate API to validate ticket against CAS server

CAS responds with XML; parse out logged‑in username
Upon successful validation, invoke FormsAuthentication.SetAuthCookie() to issue local Forms auth ticket and redirect to target page
Subsequent requests to protected directories rely on ASP.NET Forms for login state recognition

web.config Configuration

<system.web>
  <authentication mode="Forms">
    
    <forms loginUrl="CasEnter.aspx" 
           defaultUrl="admin/admin.aspx" 
           name=".LoginFormsTicket" 
           path="/" 
           timeout="40" 
           protection="All">
    forms>
  authentication>
  <authorization>
    <allow users="*"/>
  authorization>
system.web>


<location path="admin">
  <system.web>
    <authorization>
      <deny users="?"/>
    authorization>
  system.web>
location>

Modern CAS server enforces HTTPS by default. casUrl must be set to https://127.0.0.1:8443/cas/

<appSettings>
  
  <add key="casUrl" value="https://127.0.0.1:8443/cas/"/>
appSettings>

CasEnter.aspx Page Source

1. CasEnter.aspx Markup

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="CasEnter.aspx.cs" Inherits="CasStudy.Web.CasEnter" %>
html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>CAS Relay Logintitle>
head>
<body>
    <form id="form1" runat="server">
        <div>
            <asp:Label ID="Label1" runat="server">asp:Label><br />
            <asp:HyperLink ID="HyperLink1" runat="server">Re‑Authenticateasp:HyperLink>
        div>
    form>
body>
html>

2. CasEnter.aspx.cs Code‑Behind

API upgraded to CAS3.0 p3/serviceValidate
Replaced deprecated WebClient with HttpClient

Added self‑signed certificate compatibility (mandatory for local testing against modern CAS)
Namespace handling for CAS‑returned XML

using System;
using System.Configuration;
using System.Net;
using System.Net.Http;
using System.Xml;
using System.Web.Security;

public partial class CasEnter : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        string casHost = ConfigurationManager.AppSettings["casUrl"];
        string ticket = Request.QueryString["ticket"];
        string service = Request.Url.GetLeftPart(UriPartial.Path);

        // No ticket, redirect to CAS login page
        if (string.IsNullOrEmpty(ticket))
        {
            string redirectUrl = $"{casHost}login?service={Uri.EscapeDataString(service)}";
            Response.Redirect(redirectUrl);
            return;
        }

        // Validate ticket
        string username = ValidateTicket(casHost, ticket, service);
        if (string.IsNullOrEmpty(username))
        {
            Label1.Text = "Sorry, CAS authentication failed. Please try again.";
            HyperLink1.NavigateUrl = Request.Url.AbsolutePath;
        }
        else
        {
            // Issue Forms authentication ticket for local sign‑in
            FormsAuthentication.SetAuthCookie(username, false);
            // Redirect to target page
            Response.Redirect(FormsAuthentication.DefaultUrl);
        }
    }

    /// <summary>
    /// CAS3.0 p3/serviceValidate ticket validation
    /// summary>
    private string ValidateTicket(string casHost, string ticket, string service)
    {
        // Modern CAS recommends p3/serviceValidate (CAS3.0 protocol)
        string validateUrl = $"{casHost}p3/serviceValidate?ticket={Uri.EscapeDataString(ticket)}&service={Uri.EscapeDataString(service)}";

        // Local test only: allow untrusted SSL certificates (remove in production!)
        ServicePointManager.ServerCertificateValidationCallback += (s, cert, chain, err) => true;

        using var httpClient = new HttpClient();
        string xml = httpClient.GetStringAsync(validateUrl).Result;

        XmlDocument doc = new XmlDocument();
        doc.LoadXml(xml);
        XmlNamespaceManager nsMgr = new XmlNamespaceManager(doc.NameTable);
        // CAS3 response XML namespace
        nsMgr.AddNamespace("cas", "http://www.yale.edu/tp/cas");

        // Locate user node
        XmlNode userNode = doc.SelectSingleNode("//cas:authenticationSuccess/cas:user", nsMgr);
        return userNode?.InnerText;
    }
}

CAS Implementation

Installation

jack — Thu, 06 Aug 2026 07:45:00 +0000

Legacy Installation Guide‑ For CAS Versions Prior to 5.0

The CAS server is built with Java and requires two core runtime environments:

JDK (Java Development Kit): Includes the Java Virtual Machine (JVM) to execute Java programs and forms the fundamental runtime base.
Tomcat (Web Container): Used to host and run the CAS WAR web application.

Recommended installation sequence: Install JDK first → then install Tomcat (Tomcat automatically detects the local JDK during setup)

Dependencies

1. JDK

Version: (JDK) Java 17
Direct Link: Java Downloads | Oracle

Note: JDK7 is outdated and only compatible with older CAS releases; avoid using it for new‑project deployments.

2. Apache Tomcat

Version: Tomcat (Windows Installer)
Apache Tomcat® – Welcome!

Installation Steps

Install JDK
- Launch the EXE installer; you may set a custom install directory
- 【Critical】After installation, configure system environment variables: JAVA_HOME and Path, so Tomcat can properly locate your Java runtime
Install Tomcat 7
- Run the setup wizard; it will auto‑detect your pre‑installed JDK
- Customise Tomcat port (defaults to 8080) and define admin account credentials
- Options on the final setup screen:
- Run Apache Tomcat: Check this box to start the Tomcat service automatically once you click Finish
- Show Readme: You can uncheck this; the documentation is not required for setup
- Click Finish to complete installation

Configuring SSL/HTTPS for Tomcat

Core requirement: The CAS protocol enforces HTTPS on the server side. Plain HTTP will not work, so you must configure an SSL certificate within Tomcat.

Use the built‑in JDK keytool utility to create a JKS keystore (self‑signed certificate)
Edit Tomcat’s conf/server.xml file and enable the SSL connector
Restart Tomcat and test HTTPS by visiting https://localhost:8443

Generate Self‑Signed Certificate (JKS)

Pre‑requisites

Create a folder for certificate storage, example: C:\Keys
Launch Command Prompt as Administrator
> On Windows 7/10/11, writing directly to the root of drive C under a normal CMD session triggers permission‑denied errors.
Navigate into the bin folder of your JDK/JRE installation

cd "c:\Program Files\Java\jre\bin"

Generic command template (works with modern JDK releases)

keytool -genkey -alias tomcat -keyalg RSA -storepass changeit -keystore c:\Keys\.keystore -validity 36000

Parameter Reference

Parameter	Description
`-genkey`	Generate a public‑private key pair
`-alias tomcat`	Custom alias name for this certificate
`-keyalg RSA`	Cryptographic algorithm; standard RSA
`-storepass changeit`	Keystore password (remember this value, you will need it later for Tomcat setup)
`-keystore c:\Keys\.keystore`	Output path for the generated keystore file
`-validity 36000`	Certificate validity period in days

Interactive Prompt Input

After running the command, supply the following values step‑by‑step:

First and last name: Enter your domain name (any value is fine for lab environments)
Organisational unit, organisation, city, state or province, country code (cn)
Type y to confirm your entered details
Key password: Press Enter directly; reuse the same password as your keystore

Command To Inspect Certificate

keytool -list -keystore "C:\Keys\.keystore"

Enter your password. Proper output confirms successful certificate creation.

Configure SSL Connector Inside Tomcat server.xml

Open Tomcat/conf/server.xml
Locate the commented‑out SSL Connector block, uncomment it and fill in your certificate path and keystore password

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
    maxThreads="150" scheme="https" secure="true"
    clientAuth="false" sslProtocol="TLS"
    keystoreFile="C:\Keys\.keystore"
    keystorePass="changeit" />

Parameter Breakdown

port="8443": Tomcat default HTTPS port (standard HTTPS runs on 443; switching to port 443 requires handling port‑binding permissions)
keystoreFile: Full absolute filesystem path pointing to your generated certificate file
keystorePass: The keystore password you set earlier with keytool
clientAuth="false": Client‑side certificate validation disabled (keep false for testing environments)

Validation Procedure

Start Tomcat and open this address in your web browser:
https://127.0.0.1:8443

Browsers flag self‑signed certificates as “Not Secure”; this is expected behaviour. For production deployments you must obtain a valid CA‑signed certificate.

CAS Installation 5.0+

1. Obtain Artifacts

Starting from CAS 5.0+, the traditional war + Tomcat pattern has been dropped. Built on SpringBoot, CAS ships as a self‑contained executable Jar; an external Tomcat instance is no longer required

CAS Server

Generate deployment artefact online via CAS Initializr
https://casinitializr.apereo.org

2. CAS Server Deployment Workflow

Open CAS Initializr

Select CAS Version: 7.0.x (latest stable release)
Check core modules: Core / Web / SSL
Generate and download cas.war or directly get the standalone cas.jar

Pick one of the two packaging formats:

Option A (Recommended): Standalone Jar, embeds Tomcat, ready‑to‑run out‑of‑the‑box

Option B: Legacy WAR package, deployable onto external Tomcat (not recommended)

Deploy as Standalone Jar (mainstream approach)
1) Save the downloaded cas.jar
2) Create config directory ./etc/cas/config and add file cas.properties
3) Startup command (Java 17 or newer is mandatory)

java -jar cas.jar

Port and HTTPS notes
Default embedded Tomcat port: 8443 (HTTPS)
Newer releases enforce HTTPS by default, matching the specification for older CAS versions.

3. Access URL

https://127.0.0.1:8443/cas

Installation

Introduction

jack — Thu, 06 Aug 2026 07:35:10 +0000

Concepts

1. CAS

CAS (Central Authentication Service)
An open‑source Web SSO (Single Sign‑On) framework originated from Yale University.

2. SSO (Single Sign‑On)

Unify identity login verification for multiple web applications through one single endpoint.

Features: Applications communicate over web protocols (HTTPS) with a global unified login entry point

Plain explanation: Log in once at the authentication center within the same browser, and you can access all trusted services without repeated sign‑ins

3. Three Roles in the SSO Ecosystem

User: End‑user (web browser)
Web Applications (multiple business systems)
SSO Authentication Center (singleton)

4. Three Core Principles of SSO

All account login operations must be performed at the SSO authentication center;
The authentication center provides mechanisms to notify each web application whether the current user has been authenticated;
Pre‑established trust relationships exist between the authentication center and all business web applications.

Two Core Components

CAS Server (Authentication Server‑Side)

Independently‑deployed web program, serving as the only authentication hub
Responsibilities: Accept username and password credentials, validate user identity; issue tickets (Ticket), manage global session Cookie (TGC)

CAS Client (Embedded within each business system)

Hosted inside each business web application, usually implemented as a Filter
Responsibilities: Intercept requests for protected resources; redirect the browser to the CAS Server login page automatically when the user is unauthenticated

Workflow

User accesses resources on a business system → CAS Client intercepts the request and detects no Service Ticket present
The Client redirects the browser to the CAS Server login URL, passing along the current business system address (Service)
User submits username and password on CAS Server to complete authentication
- Successful login: CAS Server sets a TGC (Ticket Granting Cookie) global session cookie in the browser
- One‑time ticket generated: Service Ticket (ST)
CAS Server redirects the browser back to the business system URL with Ticket=xxx appended as a URL parameter
CAS Client on the business system makes a backend server‑to‑server call with Service address + Ticket to validate ticket legitimacy against CAS Server
CAS Server confirms valid ticket and returns user identity details such as username
Validation succeeds, business system creates local session and user can browse pages normally

Purpose of TGC: As long as the browser holds the TGC Cookie, subsequent visits to other CAS‑integrated systems skip the login prompt and single sign‑on happens automatically.

Introduction