Tomcat Single Sign On und Webservice Authentifizierung

[Guybrush Threepwood]

Ich will das für eine Intranetseite SSO stattfindet wenn der Benutzer lokal mit seinem Domänenaccount angemeldet ist. Soweit ja erstmal nicht das Problem, da gibt es ja genug Module für den Tomcat bzw. Apache.

Allerdings soll die Seite einen anderen Webservice (die Exchange Web Services um genau zu sein) ansprechen und hier kommt das Problem. Ich hab verschiedene Möglichkeiten gefunden per Java die EWS zu benutzen, es gibt zum Beispiel direkt eine API von MS dafür.

Die alle wollen zum Authentifizieren aber immer Benutzername + Kennwort haben.

In meinem Fall hab ich das ja aber nicht sondern nur die automatische Authentifikation die irgendwie vom Browser an den Webserver übertragen und da überprüft wird.

Hat irgendwer Erfahrung wie ich sowas nutzen kann um mich zusätzlich noch an einem Webservice (speziell am EWS wär natürlich super) zu authentifizieren?

[flashpixx]

SSO ist doch meines Wissens Kerberos, d.h. der Tomcat und der Exchange können via Kerberos sich die Tickets anfordern und prüfen, ob der User angemeldet ist oder nicht, d.h. in meinen Augen müsste der Tomcat mit den Exchange gar nicht kommunizieren. Oder hab ich da etwas falsch verstanden !?

Entweder müsste der Client doch seine Authentifizierungstickets an beide Systeme reichen oder der Tomcat reicht das Ticket was er von dem Client erhalten hat, einfach an den Exchange durch und dieser validiert gegen den Kerberosserver (jedenfalls mal salopp ausgedrückt)

[Guybrush Threepwood]

d.h. in meinen Augen müsste der Tomcat mit den Exchange gar nicht kommunizieren.

Doch, hier ist der Ablauf auch nochmal etwas genauer erklärt: Just my stuff: SPNEGO authentication and credential delegation with Java

Da ist auch erklärt wie man das Token theoretisch weiterleiten kann, aber so ganz klar ist mir das noch nicht. Also in der Theorie schon, nur die praktische Umsetzung hapert noch.

[flashpixx]

Da ist auch erklärt wie man das Token theoretisch weiterleiten kann, aber so ganz klar ist mir das noch nicht. Also in der Theorie schon, nur die praktische Umsetzung hapert noch.

Ich habe damit leider noch nie gearbeitet, aber kannst Du nicht einfach das Beispiel nehmen und einfach mal den Token durch reichen und im Log schauen, wie und ob er ankommt?

[Guybrush Threepwood]

Ja ich versuche jetzt erstmal mir ein Servlet zu schreiben um das Token anzufordern und dann zu verifizieren. Danach schau ich dann mal ob ich das zum Exchange Service weiterreichen kann.

[Guybrush Threepwood]

Konnte da jetzt endlich mal weiter machen aber im Moment sieht es so aus das ich immer den selben Fehler

SCHWERWIEGEND: Servlet.service() for servlet [default] in context with path [/my-server] threw exception [GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)] with root cause

javax.security.auth.login.LoginException: Unable to obtain password from user

bekomme, egal was ich mache.

Hab mich da an die Anleitung hier gehalten die ich noch gefunden hatte: Apache Tomcat 7 (7.0.14) - Windows Authentication How-To

Da der selbe Fehler kommt selbst wenn ich die so erstellten konfigs ändere/lösche macht das die Fehlersuche ziemlich frustrierend...

Der Fehler kommt wenn das token welches vom Client geschickt wird überprüft werden soll:

byte[] token = Base64.decode(authorization.substring(index + 1));

token = context.acceptSecContext(token, 0, token.length);[/PHP]

[lupo49]

Stimmt die Systemzeit auf beiden Systemen überein? Kerberos stellt keine Tickets aus, wenn die Differenz zu groß ist.

Steht etwas in der Ereignisanzeige des AD-Controllers? (stuff:dokuwiki [49er])

[flashpixx]

Ich kenne so Meldungen von einem LDAP Server, wenn ich die Kennung z.B. uid=myuser,dc=mycompany,dc=tld nicht richtig hatte. Da Du ja mit Exchange, also MS arbeitest und die AD letztendlich ein LDAP ist, könnte der Fehler auch daher kommen

[Guybrush Threepwood]

Stimmt die Systemzeit auf beiden Systemen überein? Kerberos stellt keine Tickets aus, wenn die Differenz zu groß ist.

Steht etwas in der Ereignisanzeige des AD-Controllers? (stuff:dokuwiki [49er])

Ja Zeiten sollten stimmen, auf den AD Controller hab ich leider keinen Zugriff. Ich hab aber noch die Vermutung das er gar nicht erst bis dahin kommt...

Ich kenne so Meldungen von einem LDAP Server, wenn ich die Kennung z.B. uid=myuser,dc=mycompany,dc=tld nicht richtig hatte. Da Du ja mit Exchange, also MS arbeitest und die AD letztendlich ein LDAP ist, könnte der Fehler auch daher kommen

Also bisher gehts um das reine SSO, zum Exchange bin ich noch gar nicht gekommen. Es soll also nur geprüft werden ob das Token das der Browser sendet gültig ist.

Hatte aber auch ein paar sachen gefunden wo stand das der Fehler von sowas kommen könnte, aber bisher konnte ich noch nichts finden wo ich etwas falsch konfiguriert habe -.-

[Guybrush Threepwood]

Wenn die Keytab Datei für einen Benutzer wie in dem oben verlinkten Tutorial erstellt wurde

ktpass /out c:\tomcat.keytab /mapuser tc01@DEV.LOCAL

/princ HTTP/win-tc01.dev.local@DEV.LOCAL

/pass tc01pass /kvno 0

Müsste ich mich dann nicht als dieser Benutzer unter Windows anmelden können und kinit -k ausführen können?

Weil wenn ich das mache bekomme ich immer die Meldung das kein passender Key in der Keytab file wäre.

Mache ich nur kinit dann werde ich nach dem Passwort gefragt und bekomme nach Eingabe mein Ticket, also scheint die krb5.ini schonmal zu stimmen. Aber die Keytab File nicht oder hängt das noch irgendwie mit dem Usermapping auf die SPN zusammen?

[lupo49]

Bei der Generierung der Keytab-Datei gibst du doch den Service Principal Name (HTTP/win-tc01.dev.local@DEV.LOCAL) mit an, der dann auch im User-Objekt "tc01@DEV.LOCAL" im AD hinterlegt sein muss. (Es darf auch nur ein User-Objekt die angegebene SPN besitzen, ansonsten scheitert die Authentifizierung auch.)

Um das zu testen sollte "kinit tc01@DEV.LOCAL" reichen. Dann sollte unter "klist" eine entsprechende Sitzung erscheinen.

Bearbeitet 27. Juni 2011 von lupo49

[Guybrush Threepwood]

Habe jetzt gemerkt das kinit -k HTTP/win-tc01.dev.local@DEV.LOCAL funktioniert.

Man muss also den principal statt des usernamens angeben.

Jetzt muss ich das nur noch irgendwie aus meinem Java Filter ans laufen bekommen

[Guybrush Threepwood]

Also die vorherige Fehlermeldung ist verschwunden nachdem ich den Tomcat mal auf Version 7 geupdatet hatte. Allerdings bekomme ich stattdessen lediglich eine andere

javax.servlet.ServletException: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)

Das liegt wohl daran das er in der Keytab keinen passenden Schlüssel findet. Allerdings weiß ich nicht warum nicht.

Durch diesen besch***enen Fallback Mechanismus in der GSS API wodurch er einfach versucht entsprechende Konfig Dateien in verschiedenen Verzeichnissen zu finden und wenn er keine findet einfach irgendwelche Standardwerte zu nehmen weiß ich nicht ob der Fehler in meinen Konfigs, in der Keytab, der Implementierung oder sonst wo liegt...

Hatte auch schon mal versucht die API zu debuggen aber leider ist (wohl aus lizenzgründen) kein Quellcode aus dem Sun package im jdk enthalten.

Bin also weiterhin für alle möglichen Tips dankbar die mich weiterbringen könnten.