1 2 Previous Next 21 Replies Latest reply on Sep 21, 2011 3:17 AM by mehul.kapadia

    SSO on JBOSS with Kerberos

    djzak

      Hi everyone.

      I am, what someone would call a newbie on jboss.

      I've searched on the web for a while, but i didn't found an concrete answer.

      Is SSO with Kerberos against a MIT Kerberos Infrastrukture working on JBOSS somehow?

      I've come to the term now that SPNEGO / NEGOTIATE is only working with MS AD, right?

      Thanks for your answers.

        • 1. Re: SSO on JBOSS with Kerberos
          aamonten

          You could use http://www.jboss.org/jbosssso/, but would need to develop a Login Provider for Kerberos.

          • 2. Re: SSO on JBOSS with Kerberos
            dlofthouse

            If you have a look at the Beta2 release of JBoss Negotiation: -

            http://www.jboss.com/index.html?module=bb&op=viewtopic&t=139944

            This has now been documented against FreeIPA, FreeIPA is essentially a distribution that simplifies the installation of an MIT KDC backed by LDAP.

            Although not documented yet provided you set up the service principals correctly you should be able to run against a standard MIT KDC.

            • 3. Re: SSO on JBOSS with Kerberos
              soshah

              Also take a look at the new SPNEGO integration that was released a few weeks ago as a start to see how the Kerberos pieces would fall into place

              Thanks
              Sohil

              • 4. Re: SSO on JBOSS with Kerberos
                soshah

                There you go. Darran beat me to the punch. This is the integration I am referring to. Still need to look into how this fits in with JBoss SSO from an integration standpoint

                Thanks

                • 5. Re: SSO on JBOSS with Kerberos
                  aamonten

                  Yeah, I'm also getting a little bit confused about the relation between SSO & negotiation.

                  • 6. Re: SSO on JBOSS with Kerberos
                    djzak

                    Hi again.
                    thanks to everybody for their answers.

                    i don't know, how i could miss the release of the 2nd beta of the Spnego module, i am going to try this out.

                    in the case of SSO:

                    I looked at the jboss-sso and got the demo application working, but I dont know where to stuck in with a kerberos login module and how?

                    The next thing is, to get full benefit of the kerberos thing, i would have to replace the SAML thing with kerberos tickets. i guess that would be a very complicated step to do?


                    thanks

                    • 7. Re: SSO on JBOSS with Kerberos
                      nofreak

                      Hi,
                      i have developed a Kerberos authentication, my environment is following:
                      JBoss, Eclipse RCP, Win2k3 Server (Kerberos KDC in AD) and i have used following technologies:
                      Client side:
                      - JAAS (Krb5LoginModule) for aquire Kerberos TGT from client TGT Cache or Kerberos Authentication Server
                      - Java GSS-API in a JAAS LoginModule to obtain the Kerberos Service Ticket
                      Server side:
                      - The JBossSX to implement my own LoginModule
                      - Java GSS-API to validate the Service Ticket from client
                      - EJB Security to implement access controll

                      I have wrote a 50 site dokumentation (internal) in German, do you speek german? If so, i could give you an overview about the steps i've done to get it work...
                      Here are aditional links in this forum:
                      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73494&postdays=0&postorder=asc&start=20
                      (My post there is confusing, cause my comprehension about Kerberos was a little bit wrong :))

                      • 8. Re: SSO on JBOSS with Kerberos
                        djzak

                        Hi noFreak

                        Thanks for answer.

                        i would be thankfull for every information on how you have done it, i speak german, so this is also great.

                        the only thing is. we cannot use AD Kerberos KDC, we use MIT, shouldn't be a problem or?

                        thanks

                        • 9. Re: SSO on JBOSS with Kerberos
                          nofreak

                          No, i don't think it's a problem, cause AFAIK all the kerberos vendors have to implement the same 'interface' to implement the Kerberos protocoll. Please sent me a pm with your email and i will send you more information.

                          • 10. 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.

                            • 11. Re: SSO on JBOSS with Kerberos
                              djzak

                              ok, ich habe auch gerade verzweifelt versucht eine pm zu schicken aber geht anscheinend wirklich nicht.

                              danke für die infos. werde mir das ganze mal durchlesen.

                              lg

                              • 12. Re: SSO on JBOSS with Kerberos
                                djzak

                                Hi, eine wichtige Frage die irgendwie bei Kerberos immer untergeht:

                                Verwendest du dieses Kerberos-SSO Szenario intern in einer Firma oder (auch) extern?

                                lg

                                • 13. Re: SSO on JBOSS with Kerberos
                                  nofreak

                                  Wir verwenden das nur in geschlossenen Systemlandschaften.

                                  • 14. Re: SSO on JBOSS with Kerberos
                                    frito

                                    Hi noFreak,

                                    could you please upload the whole documentation somewhere, perhaps a small entry in the Wiki with an attachment of the zipped document. Even if in german, it could help a lot ...

                                    Thanks a lot,

                                    1 2 Previous Next