Single Sign On für Webanwendungen am Beispiel von CAS

1. Single Sign On für Webanwendungenam Beispiel von CAS Single Sign On mit CAS Düsseldorf, 30.10.2009

2. Ausgangssituation Häufig anzutreffendes Szenario : • Es gibt mehrere Web-Anwendungen in einer Behörde oder einem Unternehmen, an denen man sich anmelden muss/kann • Benutzerkreis ist im wesentlichen identisch, oder es gibt zumindest Schnittmengen • Benutzer müssen sich an jeder Anwendung einzeln anmelden • Jede Anwendung kümmert sich selbst um Anmeldung Single Sign On mit CAS Düsseldorf, 30.10.2009

3. Probleme • unkomfortabel für Benutzer • Verwaltung der Benutzerdaten an verschiedenen Stellen • Programmieraufwand durch mehrfache Umsetzung der Anmeldeprozedur • potentiell mehr Sicherheitslücken Single Sign On mit CAS Düsseldorf, 30.10.2009

4. Single Sign On (SSO) Übertragung der Anmeldung für verschiedene Anwendungen an eine zentrale Anmeldeinstanz. Wenn man sich einmal angemeldet hat, ist man bei allen Anwendungen im SSO-Verbund angemeldet. Vorteile: • Benutzer müssen sich nicht an jeder Anwendung neu anmelden. • Benutzer müssen sich nur eine Kennung und ein Passwort merken. • Einzelne Anwendungen müssen den Anmeldeprozess nicht selbst umsetzen. • Sicherheit: Nur eine zentrale Stelle nimmt Logindaten entgegen. Die einzelnen Anwendungen sehen davon nichts. => Verbesserung von Anwenderfreundlichkeit und Sicherheit Single Sign On mit CAS Düsseldorf, 30.10.2009

5. Nachteile von SSO • Wenn nichtbefugte Personen die persönlichen Zugangsdaten kennen, können Sie jede Anwendung im Verbund benutzen. => Das eigene Passwort ist noch wertvoller als vorher. • Umstellung von Altanwendungen Single Sign On mit CAS Düsseldorf, 30.10.2009

6. Single Sign On mit CAS • Central Authentication Service • Open Source (http://www.jasig.org/cas) • Java Servlet, das in einem Servlet-Container (z.B. Tomcat) läuft • Clients für diverse Programmiersprachen verfügbar • Kommunikation nur über https, damit Anmeldedaten nicht im Klartext übers Netz gehen • über Adapter anpassbar an alle denkbaren Varianten der Benutzerdatenhaltung • Aussehen der CAS-Seiten (Login, Abmeldung) beliebig anpassbar Single Sign On mit CAS Düsseldorf, 30.10.2009

7. Ablauf bei der Authentifizierung Web-Browser (Anwender) 8. Fortfahren in Anwendung (Session aufbauen) 13. Fortfahren in Anwendung (Session aufbauen) 1. Aufruf 9. Aufruf 3. Anmeldung 5. persönliches Cookie setzen CAS-Server Anwendung 1 Anwendung 2 2. Redirect 10. Redirect CAS-Client CAS-Client 6. Redirect mit Über- gabe Serviceticket 11. Redirect mit Über- gabe Serviceticket 7. Überprüfung ST 12. Überprüfung ST 4. Authentifizierung Benutzer-DB Single Sign On mit CAS Düsseldorf, 30.10.2009

8. Single Sign Out Wenn ein Anwender sich von einer Anwendung (oder zentral) abmeldet, soll er nirgendwo mehr angemeldet sein. Voraussetzung: Abmeldung von einer Anwendung muss durchgereicht werden zum CAS-Server Möglichkeiten: • Für jeden Seitenaufruf in einer Anwendung wird beim CAS-Server ein neues Serviceticket gezogen • CAS informiert angemeldete Anwendungen über eine erfolgte Abmeldung. Anwendungen müssen diesen Aufruf verarbeiten. Single Sign On mit CAS Düsseldorf, 30.10.2009

9. Autorisierung bei Verwendung von CAS • CAS kümmert sich nur um Authentifizierung, nicht um Autorisierung Möglichkeiten: • Jede Anwendung entscheidet selbst darüber, wer was darf • Zusammenfassung an zentraler Stelle und Bereitstellung über Autorisierungskomponente, z.B. als Webservice Single Sign On mit CAS Düsseldorf, 30.10.2009

10. Integration von Altanwendungen • Falls Quellcode verfügbar: Software anpassen (lassen), entsprechende Clientbibliotheken einbinden • versteckte Anmeldung durch CAS-Server Single Sign On mit CAS Düsseldorf, 30.10.2009

11. Ist Single Sign On etwas für mich? Der mögliche Nutzen hängt von mehreren Faktoren ab: • Wie viele Anwendungen gibt es? • Wo liegen die Benutzerdaten? • Wer verwaltet sie? • Kann man bestehende Software anpassen (lassen)? • ... Lassen Sie uns darüber sprechen. Vielen Dank. Single Sign On mit CAS Düsseldorf, 30.10.2009