[jboss-user] [Security & JAAS/JBoss] - Re: SSO on JBOSS with Kerberos

[noFreak]

ok, is there even a way to sent a pm :)?...
Dann kopiere ich das wesentliche mal hier rein, sorry für die formatierung, allerdings ist mir das jetzt zu viel arbeit, das alles ordentlcih aussehen zu lassen :)

Single Sign-On Umsetzung mit Kerberos
Nachdem wir alle benötigten Technologien kennen gelernt haben, werden wir uns in diesem Kapitel der Umsetzung einer SSO Komponente in Java mithilfe von Kerberos widmen. Da die Konkrete Implementierung in einem Beispielprojekt im Anhang vorhanden ist, möchten wir hier lediglich auf die Umzusetzende Funktionalität und der Zuordnung zu den verschiedenen Technologien eingehen. Dabei soll klar werden, wie die Technologien miteinander agieren und in welcher Reihenfolge dies geschieht. 
Zunächst sollten wir uns noch einmal die Vorgehensweise der Authentifizierung wie zu Beginn beschrieben genauer anschauen. Dabei unterteilen wir die Schritte in Client und Serverseitige Aufgaben.
Client:
1.Der Benutzer meldet sich an seinem Betriebssystem mit einem Domänenkonto an. Dabei wird mithilfe von Kerberos ein sicherer Kontext auf dem Client des Benutzers hergestellt. Bei diesem Schritt werden zwischen dem Betriebssystem und dem AS von Kerberos die beiden Nachrichten Authentication Server Request und Authentication Server Reply ausgetauscht. Innerhalb eines sicheren Bereichs des Arbeitsspeichers wird das TGT gespeichert. Schlüsselkomponente : Kerberos
2.Die Anmeldung an dem Betriebssystem ist vollständig.
3.Der ORGA Benutzer startet auf diesem Client eine auf ORGA basierende Anwendung. Das TGT wird aus dem Arbeitsspeichers ausgelesen. Das LoginModule Krb5LoginModule von JAAS übernimmt diesen Schritt.
4.Das ORGA Modul fordert mit dem TGT ein Service Ticket für den Dienst, welcher Ausgeführt werden soll. Dieses Service Ticket kann ausschließlich für diesen Dienst genutzt werden. Das senden des TGT wird durch Kerberos innerhalb der Nachricht Ticket Granting Server Request abgebildet und mit dem Java GSS-API transparent implementiert. Schlüsselkomponenten: Kerberos und  Java GSS-API
5.Der angeforderte Schlüssel wird dem Client ausgeliefert. Das ausliefern wird durch die Kerberos Nachricht Ticket Granting Server Reply durchgeführt wobei das Empfangen auf der Seite des Clients mithilfe von Java GSS-API abstrakt implementiert wird. Schlüsselkomponenten: Kerberos und  Java GSS-API
6.Das Service Ticket wird Base64 kodiert und mithilfe von JBoss Funktionalitäten an diesen gesendet. Dieser Schritt entspricht dem Application Request in der Kerberos Authentifizierung, wird allerdings nicht von Kerberos oder dem Java GSS-API durchgeführt. Schlüsselkomponente: JBoss
Server:
7.Der JBoss empfängt das Service Ticket und decodiert es. Danach wird transparent durch Java GSS-API geprüft ob es von einem sicheren Client ist und ob er den angeforderten Dienst ausführen darf. Schlüsselkomponente: Java GSS-API und Kerberos
Um diese Funktionalitäten Umzusetzen implementieren wir zwei LoginModule. Eines Clientseitig für die Schritte 3 bis 6 und eines Serverseitig für den Schritt 7. Lesen Sie sich zum besseren Verständnis der Vorgehensweise am besten die jeweiligen Codeabschnitte im Projekt mgs-orga-security durch.
Clientseitige Umsetzung:
Das Clientseitige LoginModule benennen wir mit KerberosClientLoginModule. Es setzt sich folgendermaßen zusammen:
Es hat als member das Krb5LoginModule um das TGT anfordern zu können.
initialize(...):
Diese Methode sorgt für die Initialisierung des Login Modules. Die Werte der Optionen krbRealm, kdcAddress und serviceName werden ausgelesen, Membervariablen der Klasse zugewiesen und teilweise als Systemeigenschaft gesetzt. Dies ist nötig, damit später die Java GSS-API darauf zugreifen kann. Außerdem wird ein neues Krb5LoginModule instantiiert und ebenfalls dessen initialize Methode aufgerufen.
abort():
Hier setzen wir alle Membervariablen auf null. Außerdem rufen wir die abort() Methode des Krb5LoginModule auf.
commit():
Da wie später in Abschnitt der Methode login() bereits alle nötigen Informationen gespeichert wurden, ist hier nichts mehr zu tun.
logout():
Wie bei der Methode abort() setzen wir alle Membervariablen auf null und rufen die logout Methode des Krb5LoginModule auf.
login():
Die Aufwendigste aller Methoden.
Zunächst wird versucht ein Login mithilfe des Krb5LoginModule durchzuführen. Dabei wird das TGT aus dem Betriebssystem ausgelesen. Ist dies nicht erfolgreich, wird je nach Konfiguration des LoginModule's möglicherweise das Passwort und der Benutzername vom Benutzer erfragt und versucht anhand deren ein TGT vom KDC zu beziehen. Ist der Loginvorgang des Krb5LoginModule erfolgreich werden mit der Methode commit die Credentials (also auch das TGT) und die Principals in das bei der Initialisierung übergebene Subject geschrieben. Dies bereitet uns die Grundlage um ein Service Ticket zu erhalten.
Im nächsten Schritt wird eine PrivilegedAction im Namen des Subjects ausgeführt. Dabei wird wie im Kapitel 3.6  Java Generic Security Service API (Java GSS-API) beschrieben zuerst anhand des TGT's das Service Ticket vom KDC angefordert. Wurde dieses zurückgeliefert wird es Base64 codiert und zur Übertragung an den JBoss beim einem Aufruf einer EJB aufbereitet.
Wird dabei keine Rezeption geworfen und wird beim Anfordern des Service Tickets ein sicherer Kontext erstellte, so kann man davon ausgehen, dass der Benutzer am JBoss authentifiziert werden kann. Der Clientseitige Vorgang ist damit abgeschlossen.
Achtung!: Eine Authentifizierung des Clients am Server ist noch nicht sichergestellt. Der JBoss kann immer noch die Identität des Subjects ablehnen! Dies kann bisher nicht festgestellt werden, da die Serverseitige Authentifizierung erst bei Aufruf einer EJB vonstatten geht. 
Serverseitige Umsetzung:
Wie wir bereits im Kapitel 3.4.3.1 Unterschied zum Standard JAAS LoginModule gelernt haben, müssen wir hier anders wie bei einem normalen LoginModule von der Abstrakten Klasse AbstractServerLoginModule erben und somit auch andere Methoden implementieren. Unserer Klasse nennen wir KerberosJBossLoginModule. Da wir für den vom Server bereitgestellten Service ebenfalls ein TGT benötigen,  verwenden wir hier wie beim Clientseitigen LoginModule ebenfalls das Krb5LoginModule als Member unserer Klasse.
initialize(...):
Wie beim Client benötigen wir ebenfalls die Optionen krbRealm und kdcAddress. Diese werden wieder als Systemeigenschaft gesetzt, damit die Java GSS-API sie verwenden kann. Außerdem haben wir noch die Optionen name und password, mit deren Werte wir später das TGT für den Dienst erhalten können. 
Weiterhin initialisieren wir das Krb5LoginModule, allerdings mit einem selbst geschriebenem CallbackHandler welcher das eben genannte Passwort und den Name als Konstruktorparameter hat. Dieser CallbackHandler wird später dem Krb5LoginModule die nötigen Daten (Passwort und Name) liefern, welche zur Anforderung des TGT's nötig sind. Eine weitere Auffälligkeit ist, dass wir hier dem Krb5LoginModule nicht das zur Initialisierung übergebene sondern ein selbst erstelltes subject bei der Initialisierung übergeben. Dies ist daran zu Begründen, dass das übergebene Subject nach dem Login dazu verwendet wird, den Aufrufenden Benutzer zu identifizieren. Da wir zum Anfordern des TGT's aber auch ein Subject benötigen, verwenden wir hier eines, welchen den Server repräsentiert.
getIdentity():
Mit dieser Methode fragt der Server nach der Identität des Aufrufenden Subjects. Wir geben als ein Principal des Subjects zurück.
getRoleSets():
Da dieses LoginModule ausschließlich zur Authentifizierung des Benutzers dienen soll, übergeben wir hier lediglich ein Objekt, welches angibt, dass dem Subject bisher keine Rollen zugeteilt wurden.
login():
Als erstes wird ein TGT vom KDC angefordert. Dies wird benötigt, um das vom Client gesendete Service Ticket zu validieren und die Authentizität des innerhalb des Service Tickets angegebenen aufrufenden Clients zu prüfen. Da das zuständige Krb5LoginModule mit dem selbst geschriebenen CallbackHandler initialisiert wurde, werden hierbei die in den Optionen angegebene Werte des Passwortes und Namens herangezogen. 
Wenn dieser Vorgang erfolgreich war, wird im Namen des Servers wieder eine PrivilegedAction ausgeführt. Innerhalb dieser wird das vom Client übertragene Service Ticket Base64 decodiert und geprüft ob es von einem gültigen Client stammt und ob dieser Authentifiziert werden darf. Wenn dem so ist, wird das Subject zur weiteren Verwendung aufbereitet wesentliche Daten in den sharedState der LoginModule geschrieben. Der Serverseitige Authentifizierungsvorgang ist somit abgeschlossen.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4174537#4174537

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4174537