CAS‑Tutorial – FoxDevelop

Umsetzung von CAS

jack — Thu, 06 Aug 2026 08:09:55 +0000

Implementierungsansatz der älteren CAS‑Version

Kernprinzip (CAS‑1.0‑Protokoll)

Benutzer ruft die geschützte Seite /admin/admin.aspx auf
Die Berechtigungsregeln in web.config blockieren anonyme Benutzer und leiten automatisch zur Anmeldeseite CasEnter.aspx weiter
CasEnter.aspx prüft, ob der URL‑Parameter ticket vorhanden ist

Kein Ticket vorhanden: Weiterleitung zur Anmeldeseite des CAS‑Servers, die aktuelle Site‑Adresse wird als service übergeben
Ticket übergeben: Aufruf der Schnittstelle serviceValidate zur Ticketprüfung am CAS‑Server

CAS liefert XML‑Daten zurück, daraus wird der angemeldete Benutzername extrahiert
Nach erfolgreicher Prüfung wird FormsAuthentication.SetAuthCookie() aufgerufen, um das lokale Forms‑Anmeldeticket zu schreiben, anschließend erfolgt die Weiterleitung zur Zielseite
Bei späteren Zugriffen auf geschützte Verzeichnisse erkennt ASP.NET Forms den Anmeldezustand

web.config‑Konfiguration

<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>

Neuere CAS‑Server erzwingen standardmäßig HTTPS, casUrl muss mit https://127.0.0.1:8443/cas/ befüllt werden

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

Quellcode der Seite CasEnter.aspx

1. CasEnter.aspx Frontend‑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‑Relais‑Anmeldungtitle>
head>
<body>
    <form id="form1" runat="server">
        <div>
            <asp:Label ID="Label1" runat="server">asp:Label><br />
            <asp:HyperLink ID="HyperLink1" runat="server">Erneute Authentifizierungasp:HyperLink>
        div>
    form>
body>
html>

2. CasEnter.aspx.cs Code‑Behind‑Logik

Schnittstelle auf CAS3.0 p3/serviceValidate aktualisiert
HttpClient hinzugefügt, um das veraltete WebClient zu ersetzen

Kompatibilität für selbstsignierte Zertifikate ergänzt (erforderlich für lokale Tests mit neueren CAS‑Versionen)
Namensraum‑Verarbeitung für das von CAS zurückgelieferte 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);

        // Kein Ticket vorhanden, Weiterleitung zur CAS‑Anmeldeseite
        if (string.IsNullOrEmpty(ticket))
        {
            string redirectUrl = $"{casHost}login?service={Uri.EscapeDataString(service)}";
            Response.Redirect(redirectUrl);
            return;
        }

        // Ticket prüfen
        string username = ValidateTicket(casHost, ticket, service);
        if (string.IsNullOrEmpty(username))
        {
            Label1.Text = "Entschuldigung! Die CAS‑Authentifizierung ist fehlgeschlagen, bitte versuchen Sie es erneut!";
            HyperLink1.NavigateUrl = Request.Url.AbsolutePath;
        }
        else
        {
            // Forms‑Authentifizierungsticket schreiben, lokale Anmeldung abschließen
            FormsAuthentication.SetAuthCookie(username, false);
            // Zur Zielseite weiterleiten
            Response.Redirect(FormsAuthentication.DefaultUrl);
        }
    }

    /// <summary>
    /// Ticketprüfung über CAS3.0 p3/serviceValidate
    /// summary>
    private string ValidateTicket(string casHost, string ticket, string service)
    {
        // Neuere CAS‑Versionen empfehlen p3/serviceValidate (CAS3.0‑Protokoll)
        string validateUrl = $"{casHost}p3/serviceValidate?ticket={Uri.EscapeDataString(ticket)}&service={Uri.EscapeDataString(service)}";

        // Lokaler Test: Nicht vertrauenswürdige SSL‑Zertifikate zulassen (im Produktivbetrieb entfernen!)
        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);
        // Namensraum des von CAS3 zurückgegebenen XML
        nsMgr.AddNamespace("cas", "http://www.yale.edu/tp/cas");

        // Benutzer‑Knoten suchen
        XmlNode userNode = doc.SelectSingleNode("//cas:authenticationSuccess/cas:user", nsMgr);
        return userNode?.InnerText;
    }
}

Umsetzung von CAS

Installation

jack — Thu, 06 Aug 2026 07:55:23 +0000

Installation älterer Version – Hinweise für CAS vor 5.0

Der CAS‑Server ist in Java entwickelt, für den Betrieb werden zwei zentrale Umgebungen benötigt:

JDK (Java‑Entwicklungskit): Enthält die Java‑Virtual‑Machine (JVM), wird zur Ausführung von Java‑Programmen benötigt und bildet die Betriebsgrundlage.
Tomcat (Web‑Container): Dient zum Bereitstellen und Ausführen der CAS‑WAR‑Webanwendung.

Vorgeschriebene Installationsreihenfolge: zuerst JDK installieren → dann Tomcat (Tomcat sucht bei der Installation automatisch die lokale JDK‑Umgebung)

Abhängigkeiten

1. JDK

Version: (JDK) Java 17
Direktlink: Java Downloads | Oracle

Hinweis: JDK7 ist eine veraltete Version und läuft nur mit älteren CAS‑Versionen; für neue Projekte nicht empfohlen.

2. Apache Tomcat

Version: Tomcat (Windows‑Installationsversion)
Apache Tomcat® – Welcome!

Installationsablauf

JDK installieren
- Führen Sie die EXE‑Installationsdatei aus, der Installationspfad kann individuell festgelegt werden
- 【Wichtig】Nach Abschluss der Installation empfehlen sich Umgebungsvariablen zu konfigurieren: JAVA_HOME, Path, damit Tomcat die Java‑Umgebung erkennt
Tomcat7 installieren
- Installationsprogramm ausführen, es scannt automatisch das bereits installierte JDK
- Tomcat‑Port anpassen (Standard 8080), Administrator‑Benutzername und Passwort festlegen
- Optionen auf der Abschlussseite der Installation:
- Run Apache Tomcat: Haken setzen, um den Tomcat‑Dienst nach Klick auf Finish automatisch zu starten
- Show Readme: Haken entfernen, die Dokumentation wird nicht benötigt
- Klicken Sie auf Finish um die Installation abzuschließen

SSL/HTTPS‑Konfiguration für Tomcat

Hintergrund: Das CAS‑Protokoll schreibt zwingend HTTPS für den Server vor, HTTP ist unzulässig, deswegen muss für Tomcat ein SSL‑Zertifikat eingerichtet werden.

Erstellen Sie mit dem im JDK enthaltenen Tool keytool einen JKS‑Keystore (selbstsigniertes Zertifikat)
Passen Sie die Datei conf/server.xml von Tomcat an und aktivieren Sie den SSL‑Connector
Tomcat neu starten, unter https://localhost:8443 die HTTPS‑Funktion prüfen

Selbstsigniertes Zertifikat (JKS) erstellen

Vorbereitungen

Ordner für Zertifikate anlegen: Beispiel C:\Keys
Eingabeaufforderung (cmd) als Administrator ausführen
> Bei Windows7/10/11 treten Berechtigungsfehler auf, wenn eine normale cmd‑Instanz in das Stammverzeichnis von Laufwerk C schreibt.
Wechseln Sie in den bin‑Ordner von JDK/JRE

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

Allgemeiner Befehlsvorlage (funktioniert auch mit neueren JDK‑Versionen)

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

Parametererklärung

Parameter	Bedeutung
`-genkey`	Schlüsselpaar generieren
`-alias tomcat`	Zertifikatsalias, frei wählbar
`-keyalg RSA`	Verschlüsselungsalgorithmus, Standard‑RSA
`-storepass changeit`	Keystore‑Passwort (unbedingt merken, wird später bei der Tomcat‑Konfiguration benötigt)
`-keystore c:\Keys\.keystore`	Ausgabepfad der Zertifikatsdatei
`-validity 36000`	Gültigkeitsdauer des Zertifikats (Tage)

Interaktive Eingabe der Daten

Geben Sie nach Ausführung des Befehls nacheinander ein:

Vor‑ und Nachname: Domain eintragen (für Lernumgebungen beliebiger Inhalt möglich)
Organisationseinheit, Organisation, Stadt, Bundesstaat, Ländercode (cn)
Zur Bestätigung der Angaben y eingeben
Schlüsselpasswort: Einfach die Eingabetaste drücken, verwenden Sie dasselbe Passwort wie beim Keystore

Befehl zum Anzeigen des Zertifikats

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

Geben Sie das Passwort ein; eine fehlerfreie Ausgabe bestätigt die erfolgreiche Zertifikaterstellung.

SSL‑Connector in Tomcat server.xml konfigurieren

Öffnen Sie Tomcat/conf/server.xml
Suchen Sie den auskommentierten SSL‑Connector, heben Sie die Auskommentierung auf und passen Sie Zertifikatspfad sowie Passwort an

<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" />

Parameterbeschreibung

port="8443": Standard‑HTTPS‑Port von Tomcat (Standard‑HTTPS‑Port ist 443, bei Wechsel auf 443 auf Portbelegung und Berechtigungen achten)
keystoreFile: Absoluter Pfad zur erstellten Zertifikatsdatei
keystorePass: Das zuvor mit keytool festgelegte Keystore‑Passwort
clientAuth="false": Kein Client‑Zertifikat erforderlich (für Lernumgebungen fest auf false setzen)

Prüfverfahren

Starten Sie Tomcat und rufen Sie im Browser auf:
https://127.0.0.1:8443

Bei selbstsignierten Zertifikaten gibt der Browser eine „unsicher“‑Warnung aus, das ist normal. Für Produktivumgebungen kaufen Sie ein offizielles CA‑Zertifikat.

CAS‑Installation 5.0+

1. Ressourcen beziehen

CAS 5.0+ verzichtet auf das klassische war + Tomcat‑Modell. Es basiert auf SpringBoot und liefert eine eigenständige ausführbare Jar‑Datei, ohne externes Tomcat

CAS‑Server

Bereitstellungspaket online mit CAS Initializr erstellen
https://casinitializr.apereo.org

2. Ablauf der CAS‑Server‑Bereitstellung

CAS Initializr öffnen

CAS Version auswählen: 7.0.x (aktuelle stabile Version)
Grundmodule auswählen: Core / Web / SSL
cas.war generieren und herunterladen (oder direkt die eigenständige cas.jar erstellen)

Wählen Sie eines der beiden Paketverfahren:

Modus A (empfohlen): Standalone (eigenständige Jar‑Datei), integriertes Tomcat, sofort einsatzbereit

Modus B: Klassisches War‑Paket, kann auf externem Tomcat bereitgestellt werden (nicht empfohlen)

Bereitstellung im【eigenständigen Jar‑Modus】(gängige Lösung)
1) Heruntergeladene Datei cas.jar
2) Konfigurationsordner ./etc/cas/config erstellen sowie die Konfigurationsdatei cas.properties
3) Startbefehl (Java 17 oder höher ist zwingend erforderlich)

java -jar cas.jar

Hinweise zu Port und HTTPS
Standard‑Port des integrierten Tomcat: 8443 (HTTPS)
Neue Versionen erzwingen standardmäßig HTTPS, entsprechend den Vorgaben älterer Versionen.

3. Zugriffsadresse

https://127.0.0.1:8443/cas

Installation

Einführung

jack — Thu, 06 Aug 2026 07:37:12 +0000

Konzepte

1. CAS

CAS (Central Authentication Service, Zentraler Authentifizierungsdienst)
Ein quelloffenes Web‑SSO‑Framework (Single Sign‑On, Einmalanmeldung), das an der Yale‑Universität entwickelt wurde.

2. SSO (Single Sign‑On / Einmalanmeldung)

Mehrere Webanwendungen nutzen eine zentrale Adresse zur Durchführung der Benutzer‑Anmelde‑ und Identitätsprüfung.

Merkmale: Anwendungen kommunizieren über Web‑Protokolle (HTTPS) mit einem global eindeutigen Anmeldezugang

Einfache Erklärung: Melden Sie sich im gleichen Browser einmal am Authentifizierungszentrum an, dann können Sie alle vertrauenswürdigen Dienste ohne erneute Anmeldung aufrufen

3. Drei Rollen im SSO‑System

User: Endbenutzer (Web‑Browser)
Web‑Anwendungen (mehrere Fachsysteme)
SSO‑Authentifizierungszentrum (eindeutig)

4. Drei Kernprinzipien von SSO

Alle Anmeldevorgänge von Benutzerkonten werden ausschließlich im SSO‑Authentifizierungszentrum ausgeführt;
Das Authentifizierungszentrum stellt einen Mechanismus bereit, um jede Webanwendung darüber zu informieren, ob der aktuelle Benutzer authentifiziert ist;
Zwischen Authentifizierungszentrum und allen Fach‑Webanwendungen besteht eine vorab vereinbarte Vertrauensbeziehung.

Zwei zentrale Komponenten

CAS Server (Authentifizierungsserver)

Eigenständig bereitgestellte Webanwendung, das einzige Authentifizierungszentrum
Aufgaben: Entgegennahme von Benutzername und Passwort, Prüfung der Benutzeridentität; Ausstellung von Tickets, Verwaltung des globalen Sitzungs‑Cookies TGC

CAS Client (Client, eingebettet in jedes Fachsystem)

Wird innerhalb jeder Fach‑Webanwendung ausgeführt, meist als Filter realisiert
Aufgaben: Abfangen von Anfragen auf geschützte Ressourcen; leitet den Browser bei fehlender Anmeldung automatisch auf die CAS‑Server‑Anmeldeseite um

Ablauf

Benutzer ruft Ressourcen eines Fachsystems auf → CAS Client fängt die Anfrage ab und stellt fest, dass kein Service Ticket vorhanden ist
Der Client leitet den Browser um zur CAS‑Server‑Anmeldeadresse und übergibt die Adresse des aktuellen Fachsystems (Service)
Benutzer gibt Benutzername und Passwort auf dem CAS‑Server ein und schließt die Authentifizierung ab
- Erfolgreiche Anmeldung: CAS Server schreibt in den Browser das TGC (Ticket Granting Cookie), globales Sitzungs‑Cookie
- Einmal‑Ticket wird erzeugt: Service Ticket (ST)
CAS Server leitet den Browser erneut auf die Adresse des Fachsystems um und hängt den URL‑Parameter Ticket=xxx an
Der CAS Client des Fachsystems führt im Hintergrund eine Server‑zu‑Server‑Anfrage durch mit Service‑Adresse und Ticket zur Prüfung der Gültigkeit des Tickets am CAS‑Server
CAS Server bestätigt gültiges Ticket und gibt Benutzeridentitätsdaten (Benutzername u. a.) zurück
Prüfung erfolgreich, Fachsystem erstellt lokale Sitzung, Benutzer kann Seiten normal aufrufen

Funktion von TGC: Solange der Browser das TGC‑Cookie behält, erscheint bei Aufruf weiterer CAS‑integrierter Systeme keine Anmeldeseite, die Einmalanmeldung läuft automatisch ab.

Einführung