Het Central Authentication Service (CAS)-protocol: een toelichting

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

Het Central Authentication Service- of CAS-protocol is een single sign-on (SSO)-protocol dat websites in staat stelt gebruikers te authenticeren.

Inloggegevens worden eenmalig gebruikt voor authenticatie voor toegang tot meerdere applicaties, zonder dat het beveiligde wachtwoord wordt onthuld. De applicatie waarvoor autorisatie vereist is, stuurt de gebruiker door naar één gecentraliseerde, vertrouwde server, de CAS-server.

Het CAS-protocol kan worden gebruikt om niet-vertrouwde webapplicaties te authenticeren die een serviceticket vereisen voor toegang. CAS is een tool om gebruikers te authenticeren, wat niet hetzelfde is als autoriseren. De applicatie voert de specifieke autorisaties uit.

De CAS-benadering vereist weinig onderhoud en kan na de initiële configuratie worden toegepast op een groot netwerk van computers. Het biedt gebruiksgemak, consistentie en een hoge mate van security.

Central Authentication Service (CAS) begrijpen

Met CAS kan SSO (single sign-on) worden toegepast op meerdere webapplicaties voor een soepelere end-user experience. De gecentraliseerde authenticatieserver, de CAS-server, is een vertrouwde bron voor authenticatiedoeleinden.

Het CAS-protocol en de autorisatie-flow zien er als volgt uit:

  1. Een gebruiker probeert toegang te krijgen tot een webapplicatie die nog niet geverifieerd is. Dit is de eerste poging om toegang te krijgen tot een webapplicatie die gebruikmaakt van de CAS-server.
  2. De gebruiker wordt naar de CAS-server geleid. 
  3. De gebruiker voert de inloggegevens één keer in op de CAS-server en de CAS-server stelt vast of de gebruiker authentiek is. 
  4. Na authenticatie door de CAS-server wordt een serviceticket aan de URL gekoppeld. 
  5. De applicatie verstuurt een verzoek naar de CAS-server, die het serviceticket valideert. Als het ticket geldig is, wordt de gebruiker geauthenticeerd en teruggestuurd naar de applicatie.

Dankzij CAS hoeft de gebruiker dit proces tijdens dezelfde single sign-on-sessie niet meer te herhalen voor andere applicaties. Zodra de gebruiker zich aanmeldt bij het gecentraliseerde authenticatiesysteem, wordt een cookie of systeemdata-element met de authenticatiestatus ingesteld, zodat tijdens dezelfde sessie niet opnieuw geauthenticeerd hoeft te worden.

Belangrijke CAS-componenten

Bij het CAS-protocol en de authenticatie-flow komen drie (of vier) partijen kijken.

  • Client-webbrowser: dit is software die is geïntegreerd in de webapplicatie die de CAS-service gebruikt.
  • Webapplicatie: de applicatie die om authenticatie verzoekt.
  • CAS-server: de losstaande component die wordt gebruikt om gebruikers te authenticeren en toegang te verlenen tot webapplicaties via de CAS-service.
  • Back-end-service: binnen een CAS-protocol kan er ook een databaseserver zijn die geen eigen HTTP-interface heeft, maar wel kan communiceren met een webapplicatie.

CAS verwijst naar een softwarepakket dat ook gebruikmaakt van het CAS-protocol.

CAS op uw website gebruiken

Om applicaties te integreren met het CAS-protocol, moet u eerst een CAS-server aanwijzen. Iedereen die voor deze applicaties geauthenticeerd wil worden, moet een login hebben op de CAS-server. CAS kan in praktisch elke webapplicatie worden geïntegreerd en ondersteunt een veelvoud aan programmeertalen, waaronder Java, Python, PHP en PL/SQL.

Er zijn ook allerlei verschillende client-libraries beschikbaar die CAS kunnen authenticeren. Voor PHP kunt u gebruikmaken van de phpCAS-library. Voor Python, waar Flask en Django onder vallen, is de python-cas-library perfect. Als u een andere taal gebruikt, kunt u zoeken naar bestaande libraries.

Het CAS-protocol is opensource en voor iedereen toegankelijk. U kunt hier terecht voor informatie over de interne werking van het CAS-protocol en de implementatie ervan.

Authenticatie versus autorisatie

Authenticatie en autorisatie is niet hetzelfde.

Het CAS-protocol authenticeert alleen de toegang van gebruikers tot webapplicaties, maar autoriseert geen gebruikers. Wanneer gebruikers inloggen op de CAS-server met hun inloggegevens, bepaalt de CAS-authenticatie wie deze gebruiker is. Er wordt gedocumenteerd wie inlogt, maar de applicatie "ziet" het wachtwoord en de inloggegevens niet direct.

U moet bepalen welke gebruikers toegang en machtigingen moeten krijgen en deze toegang en machtigingen configureren in het systeem. Zo kunt u adminmachtigingen toekennen aan specifieke gebruikers-ID's, zodat deze gebruikers specifieke bestanden kunnen lezen en erin kunnen schrijven. Dit is een vorm van autorisatie.

Kort samengevat, wordt bij authenticatie de identiteit van een gebruiker geverifieerd en worden bij autorisatie de specifieke toegang tot data en machtigingen van een gebruiker geverifieerd. Binnen uw systeem moet zowel authenticatie als autorisatie plaatsvinden. De CAS-service verzorgt alleen het authenticatiegedeelte. Autorisatie moet dan nog in een andere laag worden geïmplementeerd.

Voordelen van CAS

Het CAS-protocol heeft allerlei voordelen voor gebruikers, waaronder de volgende:

  • Gemak: gebruikers hoeven tijdens een sessie maar één keer in te loggen op de CAS-server om toegang te krijgen tot meerdere webapplicaties, zonder dat aanvullende logins nodig zijn.
  • Consistentie: elke gebruiker heeft dezelfde inlogpagina op de CAS-server.
  • Minder werk voor applicaties: webapplicaties hoeven geen eigen infrastructuur en processen voor authenticatie te hebben.
  • Security: webapplicaties hebben geen toegang tot de inloggegevens of wachtwoorden.

De initiële configuratie van het CAS- protocol kan wat extra tijd vergen, maar het protocol biedt een end-user experience met minder frictie. Het is daarnaast eenvoudiger te onderhouden, aangezien er één gecentraliseerde server is en één systeem, en het dus niet nodig is de authenticatieprocessen van elke webapplicatie afzonderlijke te beheren.

Authenticatieprotocollen hoeven niet één voor één te worden geïntegreerd. In plaats daarvan kunt u meerdere webapplicaties, waaronder webmail-servers en webmail-clients, op één gecentraliseerde, vertrouwde locatie beheren.

Belangrijkste punten

Het CAS-protocol is een opensource single sign-on-service waarmee gebruikers één keer per sessie inloggen op een vertrouwde server en vervolgens toegang hebben tot meerdere applicaties zonder zich steeds weer opnieuw te hoeven aanmelden. Dit draagt positief bij aan de productiviteit, snelheid en end-user experience.

Bij het CAS-protocol is er een vertrouwde centrale CAS-server waar alle gebruikers direct op inloggen. Na het inloggen "onthoudt" het systeem de gebruiker gedurende de rest van de sessie met behulp van cookies.

Wanneer gebruikers een webapplicatie proberen te openen waarvoor autorisatie vereist is, worden ze de eerste keer doorgeleid naar de CAS-server voor authenticatie. Na hun authenticatie wordt er een serviceticket aan de URL gekoppeld. Wanneer een gebruiker een andere webapplicatie opent, wordt de authenticatie op de achtergrond afgehandeld. De gebruiker hoeft zelf niets meer te doen.

Het CAS-protocol is veilig, aangezien webapplicaties geen wachtwoorden te zien krijgen. Daarnaast is het praktisch en gebruiksvriendelijk.

Referenties

Central Authentication Service. Microsoft Academic.

CAS Enterprise Single Sign-On. Apereo Foundation.

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

Getting Started. Apereo Foundation.