entwickler.de

Um verschiedene Anwendungen in einem einheitlichen Bild erscheinen zu lassen, gilt es, Mehrfachanmeldung zu vermeiden. Aus Gründen der Benutzerfreundlichkeit wird hier also ein Single-Sign-on-(SSO-)Mechanismus angestrebt (also ein Mechanismus zur Einmalanmeldung), der es dem Benutzer erlaubt, sich mit einer einzigen Authentifizierung an einem gesamten Anwendungsverbund anzumelden. Der Benutzer muss sich somit nur noch eine Kennung und ein Passwort merken. Das hierdurch entstehende Sicherheitsrisiko - einem Angreifer genügt das Ausspähen einer einzigen Benutzeridentität, um Zugriff auf den gesamten Verbund zu bekommen - wird in den meisten Fällen in Kauf genommen, denn der Vorteil von SSO wiegt dies meist auf. Nach der Einmalanmeldung werden alle weiteren Aufrufe automatisch und zeitsparend mit den notwendigen Authentifizierungsdaten - den Credentials - versorgt.

Vor- und Nachteile

Welche Vorteile bietet SSO denn nun und was sind die Nachteile? Zu den wichtigsten Vorteilen, sowohl für Endanwender als auch für Unternehmen, die eine SSO-basierte Infrastruktur einsetzen, zählen hierbei:

• einheitlicher Zugriff über einen einheitlichen Authentifizierungsmechanismus.
• Benutzer müssen sich nur genau eine Kennung und ein Passwort merken.
• Benutzer können ein komplexeres Passwort wählen, was die Sicherheit erhöht.
• im Idealfall nur eine manuelle Anmeldung pro Sitzung.
• Kostenreduktion durch bessere Wartbarkeit von Zugangs- und Benutzerdaten.

Obwohl die Vorteile in den meisten Fällen die Nachteile überwiegen, sollen diese nicht verschwiegen werden. Als besonders kritisch einzustufen sind folgende Aspekte:

• Angreifer können durch Ausspähen der Zugangsdaten auf alle Systeme zugreifen.
• Ein zentraler Anmeldevorgang kann Single Point of Failure sein, sowohl in Bezug auf Sicherheitsprobleme als auch hinsichtlich des Lastverhaltens.

Zudem kann es aufgrund von Datenschutzgesetzen ein Problem darstellen, wenn personenbezogene Daten zentral gespeichert werden. Ein über Unternehmensgrenzen hinweg arbeitendes Single Sign-on zu realisieren ist deshalb schwierig.

Lösungsansätze

Es gibt verschiedene Methoden, einen SSO zu realisieren (mal ganz abgesehen von einer clientbasierten Lösung wie etwa einem Passwort-Manager). Im Rahmen dieses Artikels werden jedoch nur zwei der wichtigsten Lösungsansätze beschrieben: Zum einen die Verwendung einer zentralen Instanz, welche die Anmeldung vornimmt, zum anderen die Realisierung eines Circle of Trust, bei der die Anmeldung am Gesamtsystem durch Anmeldung an einem beliebigen System innerhalb des Verbunds erfolgt. Ein grundsätzlicher Ansatz bei SSO, der vorab kurz erläutert werden muss, ist der Einsatz von Tickets. Diese Tickets werden bei einer erfolgreichen Anmeldung erzeugt und dienen ab diesem Zeitpunkt dazu, den Anwender zu authentifizieren. Das Ticket, das ein Benutzer erhält, wird idealerweise automatisch verifiziert (anstelle einer interaktiven Anmeldung durch Eingabe von Benutzerkennung und Passwort). Klar ist jedoch, dass ein solches Ticket - wird es denn von einem Angreifer abgefangen - ein potenzielles Risiko darstellt. (Dieses ist jedoch keinesfalls so schlimm, wie ein erspähtes Passwort!) Tickets sollten deshalb mit einer Gültigkeit versehen werden. Falls ein Ticket entwendet und unrechtmäßig eingesetzt wird, ist es wahrscheinlich schon abgelaufen. Es wird dann wieder eine interaktive Anmeldung nötig, und der Angreifer hat seine Chance vertan. Um Veränderungen an einem Ticket zu verhindern (z.B. um besagte Gültigkeit zu manipulieren), sollte dieses zudem möglichst verschlüsselt oder wenigstens signiert werden. Benutzerkennung und Passwort sind natürlich auf keinen Fall in ein solches Ticket zu speichern. Nein, auch nicht verschlüsselt.

Circle of Trust

Ein möglicher Lösungsansatz für SSO ist der so genannte Circle of Trust. Hierbei wird ein Netz aus vertrauenswürdigen Anwendungen aufgebaut. Meldet sich ein Benutzer bei einer der Anwendungen an, so ist er danach für alle anderen Anwendungen gleichermaßen angemeldet. Die ideale Lösung sieht dabei so aus, dass der Benutzer bei der Anmeldung am ersten System ein Ticket bekommt, mit dem er sich bei allen anderen Anwendungen authentifizieren kann. Das Ticket muss hierzu bei jeder Anwendung aus dem Circle of Trust verifiziert werden können. In der echten Welt (ich hätte doch die blaue Pille nehmen sollen) steht man jedoch oft vor dem Problem, dass man alte Anwendungen hat, die man nur minimal verändern möchte oder kann. Oft muss auch mit kleinem Budget eine Lösung realisiert werden, die SSO umsetzt. Bei obigem Ansatz müsste man aber jede Anmeldeprozedur der Anwendungen durch einen neuen Mechanismus ersetzen, der dieses eine (allen Anwendungen gemeinsame) Ticket interpretieren kann. Eine einfachere Möglichkeit, einen Circle of Trust für Java-basierte Webanwendungen zu realisieren, ist es, mit versteckter Anmeldung (Hidden Logon) zu arbeiten. Hierzu wird zwischen der Anmeldung und dem eigentlichen Anwendungsfall ein Schritt in den Ablauf integriert, welcher Anmeldungen an allen beteiligten Anwendungen des Circle of Trust durchführt (mittels eines HTTP-Aufrufs) - quasi ein Login anstelle des Benutzers. Dieser neue Schritt bringt den Zustand der Sitzungen aller Anwendungen auf „angemeldet“. Falls die beteiligten Anwendungen alle mit Cookies arbeiten, ist man danach im Idealfall schon fertig. Jedes Cookie im Browser identifiziert den Benutzer gegenüber der Anwendung, die er „ansurft“, und der Benutzer erhält dadurch Zugriff. Er muss sich nicht interaktiv anmelden, denn er wurde ja versteckt automatisch angemeldet, und die Anwendung erkennt den Benutzer durch das Cookie, das er mit sich bringt. Hinlänglich bekannt sein sollten allerdings die Risiken beim Einsatz von Cookies. Falls sich mehrere Benutzer einen Rechner teilen, muss sichergestellt werden, dass bei einem Benutzerwechsel keine gültigen Cookies mehr auf dem Rechner vorhanden sind. Zudem existiert das Problem von möglichen Angriffen durch Cross-Site-Scripting-Attacken. Die Umsetzung dieses einfachen Circle of Trust wird schwieriger, wenn die Identifikation der Anwendungssitzungen mittels SessionId-Parameter in dem URL realisiert ist. Dann muss jeder Link auf eine der Anwendungen zusätzlich den richtigen Wert für den URL-Parameter gesetzt bekommen. Man kann dies beispielsweise über ein JSP Custom Tag realisieren, welches - abhängig von dem Anwendungs-URL - den richtigen Parameter anhängt. Allerdings muss trotzdem noch das Problem gelöst werden, wo man sich die ganzen Werte für die SessionId-Parameter merkt. Zudem muss man noch jeden Link auf allen JSP-Seiten dahingehend anpassen, dass das neue JSP Custom Tag verwendet wird. Das klingt nach viel Arbeit und Chaos. Je nach Beschaffenheit der Anwendungen, ist es das auch. Es gibt auch noch eine Reihe weiterer möglicher Probleme bei dieser Lösung: Die beteiligten Anwendungen können beispielsweise in Time-outs laufen. Das kann zwar meist durch Erhöhen des Session-Time-outs verhindert werden, ist dies jedoch im Einzelfall nicht möglich, muss ein „Keep alive“-Mechanismus realisiert werden. Des Weiteren muss eine Abmeldung vom System natürlich für alle beteiligten Anwendungen durchgeführt werden und Sonderfälle, wie eine erzwungene Änderung des Passworts bei der ersten Anmeldung, müssen ebenso berücksichtigt werden. Eine naive Umsetzung der versteckten Anmeldung impliziert zudem, dass alle Anwendungen die gleichen Zugangsdaten verwenden. Möchte man nicht für alle Anwendungen eine Angleichung der Benutzerdaten (gleiche Benutzerkennung und gleiches Passwort) durchführen, muss man sich an dieser Stelle auch noch etwas überlegen, quasi eine Zuordnung zwischen den neuen, „einzigen“ Benutzerdaten und den pro Alt-Anwendung existierenden Benutzerdaten. Je mehr man über diese vermeintlich einfache Lösung nachdenkt, desto mehr wünscht man sich eine sauberere Vorgehensweise, bei der die Anmeldeprozeduren und die Sitzungsverwaltung entsprechend angepasst sind. Bei einer Cookie-basierten Sitzungsverwaltung kommt man mit der Methode der versteckten Anmeldung jedoch oft relativ schnell zum Ziel. Allerdings nur, falls die angedeuteten Probleme vernachlässigt werden können.

Zentraler Sign-on-Server

Ein anderer Lösungsansatz ist, für die Anmeldeprozedur eine zentrale Instanz zu etablieren. Bei dieser Lösung - mit einem dezidierten Sign-on- bzw. Ticket-Server - wird eine eigene Anwendung implementiert, die zu Beginn jeder Sitzung angesprochen werden muss. Der Client erhält über diesen Server das Ticket, mit dem er sich gegenüber allen Anwendungen im Verbund authentifizieren kann. Das Ticket muss vom Client bei jeder Anfrage an eine Anwendung des Verbunds mitgegeben werden. Jede einzelne Anwendung enthält dann eine spezielle Logik, die das Ticket verifiziert bzw. beim zentralen Ticket-Server verifizieren lässt. Falls das Ticket erfolgreich verifiziert werden konnte, erhält der Benutzer Zugriff auf die Anwendung. Alte Anwendungen müssen entsprechend dieser Logik angepasst werden. Die alte Anmeldeprozedur muss durch einen neuen Ablauf ersetzt werden. Anstatt über die ursprüngliche Anmeldeseite muss über den Sign-on-Server eingestiegen werden, welcher dann an die Anwendung weiterleitet (oder umgekehrt). Zusammengefasst enthält das Vorgehen für eine erfolgreiche Anmeldung am Anwendungsverbund folgende Schritte:

• Jeder Aufruf eines Benutzer-Clients wird zuerst an den Sign-on-Server gerichtet (oder dahin umgelenkt).
• Nach der interaktiven Anmeldung erhält der Client vom Sign-on-Server ein persönliches Ticket. Die Anfrage des Clients wird vom Sign-on-Server an die eigentliche Anwendung weitergeleitet (mittels einer mitgegebenen Rücksprunginformation z.B. in Form eines Rücksprungs-URL).
• Der Client überträgt das Ticket an die Anwendung.
• Die Anwendung verifiziert das Ticket mithilfe eines Aufrufs an den zentralen Sign-on-Server.
• Bei gültigem Ticket wird dem Benutzer Zugriff auf die eigentliche Anwendung gewährt.

Dieses Vorgehen hat den Vorteil, dass die Client-Anwendung niemals das Passwort des Benutzers sehen muss. Es wird lediglich an den zentralen Sign-on-Server übermittelt, der daraufhin ein Ticket generiert und dieses an die Client-Anwendung zurückgibt. Ein interessanter Aspekt im Ablauf des oben beschriebenen Anmeldevorgehens ist die Weiterleitung vom Sign-on-Server zur Anwendung oder - als Alternative - von der Anwendung zum Sign-on-Server. Man hat einerseits die Möglichkeit zu vereinbaren, dass der Einstieg in alle Anwendungen des Verbunds immer über den zentralen Server erfolgen muss. Dieser muss dann entscheiden, auf welche Zielanwendung der Aufruf nach der erfolgreichen Anmeldung weitergeleitet werden soll. Dies kann beispielsweise anhand eines Parameters erfolgen, welcher in einem URL für die Weiterleitung umgesetzt wird. Die andere Möglichkeit ist die, direkt den URL der Ziel-Anwendung aufzurufen. Dieser überprüft, ob der Benutzer bereits angemeldet ist (das ist er, falls er ein gültiges Ticket mitbringt) und leitet den Aufrufer an die eigentliche Anwendung weiter. Ist der Benutzer noch nicht angemeldet, so wird auf den Sign-on-Server (und nur dann!) umgeleitet, wo eine interaktive Anmeldung gemacht werden muss. Damit der Sign-on-Server weiß, wohin die Reise nach der Anmeldung weitergeht, muss die Applikation auch hier einen URL zu Weiterleitung mitgeben. Dies liegt jedoch in der Verantwortung der einzelnen Anwendungen. Der Vorteil ist, dass man die Einstiege in die Einzelanwendungen nicht anpassen muss. Falls man einen Interceptor-Mechanismus verwendet (beispielsweise mittels AOP oder einfach in Form eines Servlet-Filters), ist der Aufruf der Anmeldung zudem weitgehend transparent. Sieht man von dem etwas höheren Implementierungsaufwand ab, hat man hier jedoch eine saubere Lösung aus einem Guss. Weitere Anwendungen lassen sich bei dieser Lösung transparent in den Anwendungsverbund eingliedern. Der Aufwand ist ja eigentlich auch gar nicht so groß, denn die meisten Anfragen werden einfach an den zentralen Server delegiert. Man muss jedoch die Sitzungsverwaltung komplett neu implementieren und die Benutzerdaten auch irgendwo speichern. Aber muss man deswegen jetzt das Rad neu erfinden? Stattdessen kann man auch eine bereits existierende Implementierung dieser Art verwenden, wie beispielsweise den frei verfügbaren Central Authentication Service (CAS).

Der Server

Der CAS-Server lässt sich im Auslieferungszustand einfach in den Tomcat-Server deployen, indem die Datei target/cas.war in das Verzeichnis $CATALINA_HOME/webapps kopiert wird. Er ist dann zwar sofort lauffähig und kann getestet werden, in den meisten Fällen wird man jedoch Anpassungen der Konfiguration vornehmen wollen, um beispielsweise seinen eigenen Authentifizierungsmechanismus zu realisieren. CAS bietet eine flexible Plug-in-Architektur für so genannte AuthenticationHandler. In dem hier vorgestellten Beispiel wurde eine entsprechende Klasse geschrieben, welche das Interface AuthenticationHandler implementiert. Diese Klasse prüft die Eingabedaten gegen eine statische HashMap (Listing 1).

1. Listing 1
2. public class HashmapAuthHandler implements AuthenticationHandler {
3. private static final HashMap<String, String> DUMMY_STORE = new HashMap();
5. static {
6. // Map laden, damit wir etwas haben, gegen das wir Eingaben prüfen
7. // können: Form <Benutzer, Passwort>
8. DUMMY_STORE.put("Harry", "hirsch");
9. DUMMY_STORE.put("foo", "bar");
10. DUMMY_STORE.put("Oli", "Rummeyer");
11. DUMMY_STORE.put("Joe", "dust");
12. }
14. public boolean authenticate(Credentials credentials)
15. throws AuthenticationException {
16. UsernamePasswordCredentials upCredentials =
17. (UsernamePasswordCredentials) credentials;
19. String user = upCredentials.getUsername();
20. String pw = upCredentials.getPassword();
22. if (!DUMMY_STORE.containsKey(user))
23. return false;
25. String compareMe=DUMMY_STORE.get(user);
26. return compareMe.equals(pw);
27. }
29. public boolean supports(Credentials credentials) {
30. return credentials instanceof UsernamePasswordCredentials;
31. }
32. }

Die beiden implementierten Methoden werden von CAS nach dem Hollywood-Prinzip aufgerufen. Zuerst wird die supports-Methode aufgerufen. Hier wird zunächst überprüft, ob der angesprochene Handler in der Lage ist, die übergebenen Authentifizierungsdaten (Credentials) formal korrekt zu behandeln. Der HashmapAuthHandler ist für die Behandlung von Benutzerkennungs- und Passwortdaten zuständig, also für Eingabedaten des Typs UsernamePasswortCredentials. Diese Klasse ist Bestandteil von CAS und repräsentiert einen Container für Anmeldedaten, die aus dem Benutzernamen und dem zugehörigen Passwort bestehen. Die supports-Methode liefert deshalb „true“ zurück. Die Methode authenticate enthält die eigentliche Logik zur Verifizierung der übergebenen Credentials. An diesem Punkt beginnt die eigentliche Implementierung der Authentifizierungslogik. Man könnte hier entsprechende Anfragen an eine Datenbank richten oder sich beliebig andere Vorgehensweisen überlegen, wie beispielsweise eine LDAP-Anbindung. CAS ist an diesem Punkt einfach mit Technologien wie Java Authentication and Authorization (JAAS) kombinierbar, mit der man auch eine Kerberos-Integration realisieren kann. Die AuthenticationHandler müssen in der Datei WEB_INF/deployerConfigContext.xml eingetragen und konfiguriert werden. Sie werden bei einem Authentifizierungsvorgang der Reihe nach auf die übergebenen Credentials ausgeführt:

1. <property name="authenticationHandlers">
2. <list>
3. ...
4. <bean class="com.syngenio.cas.authentication.handlers.support.HashmapAuthHandler"/>
5. </list>
6. </property>

Sind mehrere AuthenticationHandler konfiguriert, so durchläuft der CAS-Server diese nacheinander. Sobald eine supports-Methode erfolgreich durchlaufen wurde (also „true“ zurückliefert), wird dieser Handler zur Authentifizierung herangezogen. Falls auch die authenticate-Methode erfolgreich ist, ist der Benutzer angemeldet.

Client-Integration

CAS bietet Bibliotheken für die schnelle Implementierung eines Java-basierten Clients. Dieser wird als Servlet-Applikation realisiert. Die Bibliotheken enthalten Java-Klassen, welche den clientseitigen Teil des CAS-Protokolls implementieren - also Klassen für die Überprüfung von Tickets, Servlet-Basisklassen sowie Klassen für die Umleitung von HTTP-Aufrufen zum CAS-Server (Filter). Die jar-Datei mit den benötigten Klassen muss nach $CATALINA_HOME/common/lib kopiert werden. Dadurch können alle Webanwendungen auf die CAS-Client-Klassen zugreifen. Damit die Anwendung SSO-fähig wird, muss sie bei jeder Anfrage (httpRequest) die Gültigkeit des übergebenen Tickets beim CAS-Server prüfen lassen. Die Aufgabe, diese Anfrage an den CAS-Server zu richten, übernimmt der Servlet-Filter mit dem Namen CASFilter aus der CAS-Client-Bibliothek. Diese Klasse spielt eine zentrale Rolle für den Ablauf der Anmeldung. Der CAS-Filter wird in der web.xml-Datei der Client-Anwendung konfiguriert (Listing 2).

1. Listing 2
2. <filter>
3. <filter-name>CAS Filter</filter-name>
4. <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
5. <init-param>
6. <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
7. <param-value>https://localhost:8443/cas/login</param-value>
8. </init-param>
9. <init-param>
10. <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
11. <param-value>https://localhost:8443/cas/proxyValidate</param-value>
12. </init-param>
13. <init-param>
14. <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
15. <param-value>localhost:8080</param-value>
16. </init-param>
17. </filter>
19. <!-- Filter für alle URL's aktivieren -->
20. <filter-mapping>
21. <filter-name>CAS Filter</filter-name>
22. <url-pattern>/*</url-pattern>
23. </filter-mapping>

Der Filter kann über die oben aufgeführten Parameter in der web.xml konfiguriert werden bzw. benötigt diese, um korrekt zu funktionieren. Der Parameter validateUrl verweist auf die Adresse, unter der der CAS-Service für die Überprüfung der Tickets installiert ist. Sollte die Überprüfung des Tickets negativ ausfallen bzw. ist der Benutzer nicht angemeldet, leitet der Filter die Anfrage auf die unter loginUrl konfigurierte Adresse um. Fällt die Überprüfung des Tickets positiv aus, so wird sofort auf den unter serverName angegebenen Server weitergeleitet und die ursprüngliche Anwendung aufgerufen. Alternativ kann statt serverName auch serviceUrl verwendet werden, wenn der Benutzer nach einem Login stets auf denselben URL weitergeleitet werden soll (ohne Berücksichtigung des ursprünglichen Anwendungspfads). Dies kann nützlich sein, um Quereinstiege zu verhindern und dafür zu sorgen, dass die Anwendung über einen zentralen Einstieg wieder korrekt initialisiert wird. Die Konfiguration lässt eine Frage offen: Was passiert, wenn eine Anwendung für mehrere virtuelle Hostnamen (z.B. www.foo.com und www.bar.com) funktionieren soll? Es kann bei obigem Filter nur ein Hostname angegeben werden. Es sei an dieser Stelle auf das Projekt Extended CAS Client verwiesen, welches einen erweiterten CAS-Filter enthält. Dieser Filter ist in der Lage, genau dieses Problem zu beheben und ermöglicht es somit, mehrere Hostnamen zu konfigurieren. Der passende Ziel-Server wird dabei zur Laufzeit anhand des HOST_NAME-Request-Parameters ermittelt.

Hallo, CAS User!

Der Benutzer soll in der Beispielanwendung mit seinem Namen begrüßt werden, falls er sich erfolgreich anmelden konnte. Hierzu wurde ein Servlet entwickelt, das diese Aufgabe übernimmt (Listing 3).

1. Listing 3
2. protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
3. ...
4. // der cas-filter erzeugt eine session, explizit keine neue erstellen
5. HttpSession s = req.getSession(false);
7. // name des angemeldeten benutzers auslesen
8. String authenticatedUser =
9. (String) s.getAttribute("edu.yale.its.tp.cas.client.filter.user");
11. // die http-antwort zusammenbauen
12. ...
13. out.println("<p>Hello "+authenticatedUser+", you have successfully\
14. signed on using the Central Authentication Service</p>");
15. ...
16. }

Der CAS-Filter legt im SessionContext ein Attribut mit dem Namen edu.yale.its.tp.cas.client.filter.user an, das den Namen des angemeldeten Benutzers enthält. Der Benutzername wird im obigen Beispiel ausgelesen und als HTML-formatierter Text ausgegeben. Alternativ zu diesem Vorgehen existiert in den CAS-Client-Bibliotheken noch eine umfangreiche Tag Library, welche für die JSP-Entwicklung genutzt werden kann. Alternativ zu der beschriebenen Vorgehensweise mit dem CAS-Filter können für die JSP-Entwicklung auch entsprechende Tags genutzt werden. Diese werden mit dem CAS Client ausgeliefert und funktionieren analog zum CAS-Filter. Die Anwendung muss nun lediglich in den Tomcat-Server deployt werden. Danach kann der URL http://localhost:8080/cashellouser/helloCasUser in einem Browser-Fenster eingegeben werden. Daraufhin erscheint statt der angeforderten Adresse die Login-Seite des CAS-Servers. Die Anmeldung kann beispielsweise mit der Net-ID foo und dem Passwort bar erfolgen. Der AuthenticationHandler prüft die Anmeldedaten und leitet die Anfrage zum eigentlichen Ziel weiter - der Benutzer wird mit seinem Namen begrüßt. Der CAS-Filter lässt sich für beliebige andere Webapplikationen (z.B. auch für Tomcats HelloWorld-Anwendung) konfigurieren. Wird danach eine solche Webapplikation per URL angesprungen, funktioniert dies nur mittels Anmeldung beim CAS-Server oder falls bereits ein gültiges Ticket vorhanden ist.

Fazit

Mit CAS bekommt man eine ausgereifte Software frei zur Verfügung gestellt. Es lassen sich damit die üblichen Anforderungen eines zentralen Single-Sign-on-Service abdecken. CAS bietet eine flexibel erweiterbare Architektur und zudem umfangreiche Integrationsmöglichkeiten in heterogenen Umgebungen. Für nahezu jede gängige Programmiersprache existieren Client-Bibliotheken (z.B. C#/.NET oder PHP). Auch bestehende Portale können einfach an CAS angebunden werden (Unterstützung von JSR 168: Portlet Specification) und sogar eine Integration mit Acegi (Security System for Spring) wird unterstützt. Beim Einsatz von CAS ist man also auch für die Zukunft gut gewappnet.
Oliver Rummeyer und Jörg Düsterhaus sind als Berater bei der syngenio AG tätig. Sie beschäftigen sich mit komplexen Java EE-basierten Anwendungen in heterogenen IT-Landschaften von Banken und Finanzdienstleistern.

Links & Literatur

• [1] de.wikipedia.org/wiki/Single_Sign_On
• [2] www.ja-sig.org/products/cas
• [3] www-128.ibm.com/developerworks/web/library/wa-singlesign
• [4] tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
• [5] www.discursive.com/projects/cas-extend