# SingleSignOn auf Client mittels Windows Credentials



## CodeRed (8. Jul 2010)

Hallo,

ich arbeite gerade an einer Client-/Server-Anwendung, bei der sich der Client per Kerberos am Server anmeldet. Solange ich die Anmeldedaten am Client zur Verfügung stelle, funktioniert die Anmeldung ohne Probleme.

Nun würde ich jedoch gerne eine Single-Sign-On-Lösung schaffen, bei der am Client auf den angemeldeten Windows-User zurückgegriffen wird. Ich habe mit verschiedensten Einstellungen in der JAAS-Konfiguration experimentiert, darunter auch 'useticketcache'. Leider waren bisher alle meine Versuche ohne Erfolg.

Auf den Clients sind die Windows-Versionen WinXP, Vista und Win7 im Einsatz, jeweils mit aktuellem Java (6.20).

Hat mir vielleicht jemand einen Tipp, an welcher Stelle ich noch weiter suchen kann?


----------



## DerEisteeTrinker (9. Jul 2010)

wenn du Daten vom Client zum Server schickst und nun ein SingleSigneOn realisieren willst, dann versuch doch Daten abzulegen, die den Client eindeutig identifizieren. So ala HttpSession. Ich bin leider eher auf der Webschiene, da gibt es das ja schon


----------



## FArt (12. Jul 2010)

java kerberos - Google-Suche

Ich habe so was schon mit SPNEGO und JBoss umgesetzt. Dabei gibt es verschiedene Lösungsansätze, auch wenn der Server selber in der Domäne ist, oder nicht. Insgesamt solltest du dich aber mit der Materie gut auskennen!!!


----------



## Der Müde Joe (12. Jul 2010)

>ch habe so was schon mit SPNEGO und

Tomcat umgesetzt.

>Insgesamt solltest du dich aber mit der Materie gut auskennen!!! 

Das kann ich nur bestätigen. Da gibts Fehlermeldungen en masse.


Wie wars noch gleich?
"java.security.krb5.conf" --> saubere Kerberos Konfig
"java.security.auth.login.config" --> saubere andere config
und ein
keytab file, erstellt auf dem DC (auf Win ca: ktpass - princ HTTP/pc.domain.tld@DOMAIN.TLD -mapuser user -pass password -crypto ALL -ptype KRB5_NT_PRINCIPAL -out foo.keytab), welches auf dem Server benötigt wird und in der (2ten Konfg referenziert wird)

So in etwa. Ein recht komplexes und fehleranfälliges Thema.


----------



## Niki (12. Jul 2010)

witzig, genau das gleiche blüht mir auch. für jboss gibts da ein gutes paket mit doku zum downloaden:

https://jira.jboss.org/secure/attachment/12324608/security-negotiation-2.0.3.GA.tgz

ich versuch das mal zumindest mit dem umzusetzen. das thema ist leider wirklich kein so simples :-/


----------



## FArt (12. Jul 2010)

Google ist dein Freund!

JBossNegotiation - JBoss Community
NegotiateKerberos - JBoss Community
http://community.jboss.org/thread/44059
https://jira.jboss.org/browse/SECURITY-355


----------



## Niki (12. Jul 2010)

ist es eigentlich möglich, dass der browser bei fehlerhaften sso auf ein login-form kommt?

hintergrund ist der, dass die webapp im internet über form-based authentication laufen soll, und im intranet über sso. im notfall sind es halt zwei unterschiedliche war-files, angenehmer fürs deployment wäre halt, wenn es ein und das selbe paket wäre


----------



## FArt (12. Jul 2010)

Niki hat gesagt.:


> ist es eigentlich möglich, dass der browser bei fehlerhaften sso auf ein login-form kommt?
> 
> hintergrund ist der, dass die webapp im internet über form-based authentication laufen soll, und im intranet über sso. im notfall sind es halt zwei unterschiedliche war-files, angenehmer fürs deployment wäre halt, wenn es ein und das selbe paket wäre


 
Ja, das ist möglich. Du brauchst passende Loginmodule (z.B. eines für die Authentifizierung mit Kerberos, eines für die Authorisierung über den LDAP-Server und eines für den Login mit User/Password. Ich glaube das Feature heißt "stacking". Da kann man Loginmodule logisch miteinander verknüpfen.

Je nach Anforderungen würde ich aber getrennte Server vorziehen, oder zumindest getrennte Einsprungstellen (Annahme: der JBoss mit seinem Tomcat hängt sowieson nicht direkt im Internet, sondern hat noch einen Apache in der DMZ vor sich).


----------



## Niki (13. Jul 2010)

ich bin mir nicht sicher ob das mit stacking funktioniert, da ich ja da schon im login-ablauf drinnen bin. ich möchte aber bei fehlerhaften login versuch mittels sso auf form-based wechseln. ich glaub beim stacking werden die login-module die ich konfiguriert habe nur hintereinander aufgerufen. soweit ich das richtig verstanden habe könnte z.b. das erste login modul das login machen und die weiteren würden dann z.b. rollen von irgendwoher laden. ich müsste jedoch den login-prozess abbrechen und auf form-based wechseln


----------



## FArt (13. Jul 2010)

Ja, das kann durchaus sein. Ich wäre mir über die genaue Konfiguration auch noch nicht im Klaren und würde das mit einem kleinen Protoypen mal ausprobieren, natürlich erst mal mit "einfachen" Loginmodulen (z.B. basierend auf Properties).
Die Logik kann ich über Stacking abbilden (die ersten beiden Loginmodule müssen erfüllt sein oder das dritte). Danach müsste ich auch erst mal experimentieren. 
Mein erster Gedanke war, dass von Außen erst mal alle drei Loginmodule (der Login fehlt ja noch) den Zugriff verweigern. Der Fehler führt zu einem Redirect auf die Loginseite. Das nächste mal zieht das letzte Loginmodul, welches ja dann mit Credentials versorgt wurde. Das ist aber u.U. wieder verwirrend für User aus dem Intranet, die nicht an der Domäne angemeldet sind... die würde dann auch diese Seite zu sehen bekommen, außer dieses Szenario kann nicht vorkommen.


----------



## Der Müde Joe (13. Jul 2010)

Ich weiss jetzt nicht genau, wie das beim JBoss läuft. Beim Tomcat added man einfach beide Valve s zum Context. Oder besser gesagt, die werden zur Pipeline geadded (macht der Context). Danach im SSO-Autheticator wenn nicht erfolgreich den nächsten in der Pipeline aufrufen (getNext().invoke(req,res) (wenn vorhanden). Der FormAuthenticator leitet dann weiter an den LoginScreen.

Das Realm muss dabei sowohl Form als auch SSO können (CombinedRealm oder ne eigene Implementation) (So ca hab ichs noch in den Gedanken)


----------



## CodeRed (15. Jul 2010)

Mein Problem ist, dass ich nicht auf die SingleSignOn Lösungen der Browser (SPNEGO) zurückgreifen kann, sondern mir am Client das Service-Ticket selber mit Java-Mitteln besorgen muss.

Dabei möchte ich keine keytab-Datei bereitstellen, sondern über das TGT des Windows-Benutzers gehen. Die Server-Seite funktioniert einwandfrei. Auch die Client-Seite mit keytab würde funktionieren, aber dann hätte ich kein SingleSignOn über die Windows Authentifizierung.

Ich suche also eine Möglichkeit, den Ticket-Cache von Windows über Java anzuzapfen.


----------

