Das Central Authentication Service (CAS) Protokoll im Überblick

Okta's cloud-based authentication gives users high-assurance with simple-to-use factors like biometrics and push notifications.

Der Central Authentication Service, kurz CAS, ist ein Single-Sign-On-Protokoll (SSO), das Websites ermöglicht, ihre User zu authentifizieren.

Einmal eingegeben, können die Login-Daten von multiplen Anwendungen zur Authentifizierung genutzt werden. Dabei wird das sichere Passwort der User jedoch nicht preisgegeben. Die Anwendung, für die eine Authentifizierung erforderlich ist, leitet den User an den CAS-Server weiter – einen zentralen und vertrauenswürdigen Server.

Mithilfe des CAS-Protokolls können weniger vertrauenswürdige Web-Anwendungen authentifiziert werden. In der Regel benötigen diese Anwendungen ein Service-Ticket. CAS kann verwendet werden, um User zu authentifizieren – jedoch nicht, um sie zu autorisieren. Die Autorisierung kann nur über die App selbst erfolgen.

Nach der Ersteinrichtung kann das CAS-Protokoll einfach auf einem verteilten Rechnernetzwerk ausgerollt und einfach gewartet werden. Es bietet einen hohen Bedienkomfort, eine durchgängige Lösung und ein hohes Maß an Sicherheit.

Was ist der Central Authentication Service (CAS) genau?

Der CAS stellt eine SSO-Lösung (Single-Sign-On) für multiple Web-Anwendungen zur Verfügung, um den Anwendern eine hochwertige User-Experience zu bieten. Der CAS-Server ist eine vertrauenswürdige Quelle und kann daher zuverlässig für Authentifizierungsprozesse herangezogen werden.

Und so sieht das CAS-Protokoll mit dem Authentifizierungsflow aus:

  1. Ein User möchte auf eine Web-Anwendung zugreifen, für die er noch nicht verifiziert wurde. Hierbei handelt es sich also um einen Erstzugriff auf eine Anwendung, die den CAS-Service nutzt.
  2. Der User wird an den CAS-Server weitergeleitet. 
  3. Hier wird er dazu aufgefordert, seine Login-Daten einmalig anzugeben. Anschließend entscheidet der CAS-Server, ob der betreffende User authentifiziert werden kann. 
  4. Sobald der Authentifizierungsprozess erfolgreich abgeschlossen wurde, wird der URL ein Service-Ticket beigefügt. 
  5. Die Anwendung sendet eine Anfrage an den CAS-Server. Dieser überprüft das Service-Ticket.Ist das Ticket gültig, wird der User wieder zurück zur Anwendung geleitet.

Sollte der Nutzer innerhalb der Single-Sign-On-Session zwischen verschiedenen Anwendungen wechseln wollen, so kann er dies tun – ohne erneuten Authentifizierungsprozess. Sobald ein User sich erfolgreich im zentralen System authentifiziert hat, wird sein Status – z.B. durch Cookies – aufrechterhalten, ganz ohne erneute Authentifizierung in derselben Sitzung

Schlüsselkomponenten des CAS

Das CAS-Protokoll und der Authentifizierungsprozess werden in drei (oder vier) Schritten abgewickelt.

  • Client Web Browser: Diese Software wurde über den CAS-Service in die Web-Anwendung eingebettet.
  • Web-Anwendung: Das ist die App, die eine Authentifizierung erfordert.
  • CAS Server: Das ist die Stand-Alone-Komponente, die den Anwender über den CAS-Service authentifiziert und ihm Zugang zur Anwendung gewährt.
  • Backend-Service: Das CAS-Protokoll kann auch einen Database-Server enthalten, der zwar kein eigenes HTTP-Interface besitzt, aber trotzdem mit der Web-Anwendung kommuniziert.

CAS bezeichnet eine Software, die das CAS-Protokoll verwendet.

Wie integriert man CAS in eine Website?

Um Anwendungen in das CAS-Protokoll zu integrieren, müssen Sie zunächst einen CAS-Server wählen. Jeder User, der eine Authentifizierung für die Nutzung der Anwendung einholen möchte, muss sich über den CAS-Server einloggen. CAS kann in nahezu jede Web-Anwendung integriert werden und unterstützt eine Vielzahl gängiger Programmiersprachen wie Java, Python, PHP und PL/SQL.

Zudem stehen bei der Nutzung von CAS viele verschiedene Client-Libraries zu Authentifizierungswecken zur Verfügung. Für PHP könnne Sie die phpCAS Library nutzen. Für Python (einschließlich Flask und Django) Ist die python-cas-library am besten geeignet. Für den Fall, dass sie eine andere Sprache nutzen, können Sie nach allen anderen vorhandenen Libraries suchen.

Das CAS-Protokoll ist Open-Source und für jedermann zugänglich. Mehr darüber, wie das CAS-Protokoll funktioniert und wie die Implementierung erfolgt, erfahren Sie hier.

Vergleich von Authentifizierung und Autorisierung

Authentifizierung und Autorisierung sind zwei unterschiedliche Dinge.

Das CAS-Protokoll ist lediglich für die Authentifizierung von Usern zuständig, nicht aber für die Autorisierung. Sobald sich ein User mit seinen Login-Daten über den CAS-Server anmeldet, erkennt das System, um wen es sich handelt, und dokumentiert die Anmeldung. Kennwort und weitere Anmeldedaten werden jedoch nicht in der Anwendung selbst hinterlegt.

Es ist Ihnen überlassen, welchen Usern Sie bestimmte Zugriffsrechte und Privilegien einräumen – deshalb müssen auch Sie das im System festlegen. Beispiel: Sie können bestimmten User-IDs „Administrator“-Rechte einräumen. So erhalten betreffende User die Möglichkeit, mit bestimmten Dateien zu arbeiten. Das ist ein Beispiel für Autorisierung.

Zusammenfassung: Die Authentifizierung überprüft die Identität von Usern und die Autorisierung überprüft, welche spezifischen Privilegien ein User besitzt. Das System verlangt sowohl nach Authentifizierung als auch nach Autorisierung. Der CAS-Service kann nur einen Teil für Sie übernehmen – Autorisierungsprozesse müssen auf anderem Wege erfolgen.

Vorteile von CAS

Das CAS-Protokoll weist viele Vorzüge auf, unter anderem:

  • Bedienkomfort: User müssen nur einen einmaligen Login-Prozess am CAS-Server durchlaufen und können über die gesamte Session hinweg auf multiple Anwendungen zugreifen.
  • Durchgängigkeit: Jedem User wird auf dem CAS-Server die gleiche Login-Page präsentiert.
  • Weniger Aufwand für die Anwendungen: Es ist nicht notwendig, für jede Web-Anwendung eine Authentifizierungsmöglichkeit bereitzustellen.
  • Sicherheit: Die Anwendungen selbst speichern weder Login-Daten noch Passwörter.

Die Ersteinrichtung des CAS-Protokolls ist zwar nicht ganz einfach, dafür bieten Sie Ihren Anwendern aber jederzeit eine hochwertige Experience. Zudem ist die langfristige Pflege einfacher, da sich die Authentifizierungsprozesse auf einen zentralen Server beschränken.

Es gibt keinen Grund mehrere Authentifizierungsprotokolle einzurichten. Stattdessen erfolgt die Verwaltung multipler Web-Anwendungen, inklusive des Webmail-Servers und der Webmail-Clients, an einem zentralen und vertrauenswürdigen Ort.

Wichtige Erkenntnisse

Das CAS-Protokoll ist ein Open-Source-Service. Es minimiert den Aufwand für User, die sich nur noch einmal über einen vertrauenswürdigen Server anmelden und sofort auf multiple Anwendungen zugreifen können – ohne erneute Anmeldung innerhalb einer Session. Das System trägt damit zur Produktivität, Effizienz und User-Experience bei.

Die Anmeldung der User erfolgt über einen zentralen und sicheren CAS-Server. Nach der Anmeldung bleibt der User für den Rest der Sitzung im System eingeloggt. Dies wird durch Cookies ermöglicht.

Sobald ein User versucht, auf eine Anwendung zuzugreifen, die eine Authentifizierung voraussetzt, wird er auf den CAS-Server geleitet. Nach erfolgreicher Authentifizierung wird der URL ein Service-Ticket beigefügt. Sobald der User auf eine andere Web-Anwendung zugreift, wird die Authentifizierung im Backend abgewickelt – der User ist an diesem Prozess nicht einmal beteiligt.

Das CAS-Protokoll ist sicher. Passwörter werden nicht in den Anwendungen gespeichert. Es ist außerdem praktisch und nutzerfreundlich.

Referenzen

Central Authentication Service. Microsoft Academic.

CAS Enterprise Single Sign-On. Apereo Foundation.

Python-cas/ Python-cas. (2021). GitHub, Inc.

Los geht‘s. Apereo Foundation.