Anmelden an Webservice mit Windows Credentials?

Thallius

Top Contributor
Hi,

ich habe ein Java Client App welche sich mit einem von mir ebenfalls geschriebenen REST Service verbindet. Ich würde nun gerne dem User abnehmen sich jedesmal beim Starten der App einloggen zu müssen, will aber auch nicht die Credentials für den Webservice auf dem Client hinterlegen.

Gibt es irgendein Framework, dass es möglich macht sich mit den Windows-Credentials anzumelden?

Gruß

Claus
 

httpdigest

Top Contributor
Wenn du hiermit meinst: Ist es möglich, die Credentials des gerade angemeldeten Windows Users auszulesen, um sie in seinem (eigenen) Authentifizierungsverfahren in seiner eigenen App zu verwenden, dann: nein, das geht nicht.
Und warum stellst du das gleich mit "Credentials für den Webservice auf dem Client hinterlegen"? Der Client ist ja nicht User-spezifisch, würde ich mal sagen.
Damit bedeutet das ja, dass die "App" eigentlich nicht die Identität des Users wissen muss. Wen willst du also genau vor wem schützen mit deiner App Authentifizierung?
Wer soll sich als wen gegen was authentifizieren und warum?
 
Zuletzt bearbeitet:

Thallius

Top Contributor
natürlich will ich die credentials von Windows nicht auslesen. Aber es könnte ja sein, dass Windows sowas anbietet als Framework das man die Anmeldung des Users quasi als „sso“ für andere Anwendungen nehmen kann.

ich möchte meinen Rest Service schützen vor nicht authentifizierten Zugriffen. Sprich wenn ich die credentials für diesen in meine Java App schreibe kann die jeder Halbwegs begabte Hacker auslesen und von überall anders aus nutzen.
 

httpdigest

Top Contributor
natürlich will ich die credentials von Windows nicht auslesen. Aber es könnte ja sein, dass Windows sowas anbietet als Framework das man die Anmeldung des Users quasi als „sso“ für andere Anwendungen nehmen kann.
Naja, sowas geht konzeptuell ja schon nicht. Ja... klar, im Enterprise-Umfeld gibt es hier z.B. ActiveDirectory mit SSO z.B. via SAML. Aber hier hat man ja auch eine zentrale Stelle (nämlich das ActiveDirectory), welches als Identity Provider Authentifizierungsprüfungen durchführen kann und es kennt auch die Identitäten der zur Anmeldung über einen Client/App autorisierten/registrierten User.
Ein einzelner Windows PC ist kein Identity Provider. Wenn dem so wäre, würde deine App bzw. dein WebServer ja deinen Windows PC "fragen" müssen im Sinne von SSO, also: "Hey, ich hab hier eine Authentifizierungsinformation, in der behauptet wird, dass derundderjenige eine bestimmte Identität besitzt. Stimmt das? Kannst du mir das bestätigen?" Und dein Windows PC müsste dann zurückantworten: "Ja, stimmt." oder eben "Nein, stimmt nicht."
So funktioniert SSO.
Da dein App Server ja aber nicht deinen lokalen Windows PC fragen kann, geht das nicht.
P.S./Disclaimer: Ich habe gerade Single Sign-On in unserem Unternehmen per Federation mit AWS Cognito und SAML gegen ein Azure ActiveDirectory (welches für die Windows-Authentisierung verwendet wird) eingerichtet.
 
K

kneitzel

Gast
Also ich habe Thallius jetzt nicht so verstanden, dass er da einzelne Windows Systeme hat. Nach dem Lesen hört es sich schon so an, als ob er da in einer Windows Domäne ist, sprich ein AD / Kerberos hat. (Und nur da kann es, wie schon beschrieben wurde, funktionieren.

Und damit würde es doch auf etwas wie SPNEGO hinaus laufen bzw. etwas wie hier beschrieben:

Aber ich muss gestehen, dass ich im Java Umfeld noch nicht gemacht habe. Ich kenne das nur von meinen .Net / C# Zeiten.
 

httpdigest

Top Contributor
Ja, wenn hier bereits AD/Kerberos im Spiel ist (was ich aktuell nicht raushöre - aber kann ja sein), dann ja. :)
Dann muss nur ein Vertrauensverhältnis (z.B. in Form eines Shared Secret - z.B. Client Secret bei SAML) zwischen dem App Server als Client und dem ActiveDirectory hergestellt werden und die für eine SSO-Anmeldung in Frage kommenden User im AD gemapped sein.
 

Thallius

Top Contributor
Also Ich sehe da jetzt nicht so das große technische Problem. Windows könnte ja problemlos aus seine credentials die es selber weiß z.b. einen public key erzeugen, der dann einmalig meinem Rest Service bekannt gemacht wird. Meine java App würde dann den key bei Windows anfragen und sich damit authorisieren.
 

httpdigest

Top Contributor
Also Ich sehe da jetzt nicht so das große technische Problem. Windows könnte ja problemlos aus seine credentials die es selber weiß z.b. einen public key erzeugen, der dann einmalig meinem Rest Service bekannt gemacht wird. Meine java App würde dann den key bei Windows anfragen und sich damit authorisieren.
Hierzu brauchst du aber dann keine Windows Credentials bzw. Windows irgendwo in der Gleichung. Du kannst ja einfach einen random Public Key erzeugen (in deiner App lokal auf dem Client) und dann über einen sicheren Kanal zu deinem Server schicken (lassen) und den dort registrieren. Dann obliegt es dir, die Authentizität desjenigen, der dir den Key schickt, auch zu prüfen. Die Authentizitätsprüfung obliegt sowieso in jedem Fall dann dir als Serverbetrieber, egal, wie ein Key erzeugt wird oder wer dir den Key schickt.
Oder anders gesagt: Was beweist dir ein solcher Key?
Ob der Key nun irgendwie aus Windows Credentials generiert wird, oder nicht (bzw. einfach Random ist), spielt ja dann keine Rolle.
Und genauso kannst du es auch andersherum machen: Erzeuge (irgendeinen) Key im Server und schicke es zu einem (vorher auf Authentizität überprüften) Client.
 
K

kneitzel

Gast
Also es lässt sich prinzipiell eine Autorisierung über Zertifikate aufbauen. Aber das hat mit der Windows Integrated Authentication nichts mehr zu tun (was die Nutzung des Windows Accounts bedeutet, wobei das nur Sinn macht, wenn es eine klare Vertrauensstellung gibt. Und das wäre die Windows Domäne bzw. ein LDAP/Kerberos was ja ein AD implementiert)

Wenn du ein SSO haben willst, das eben von Windows unabhängig ist, dann gibt es diesbezüglich einige Möglichkeiten. Ein Überblick / Einführung gibt z.B.
(Einfach mal das erste Ergebnis einer Google Suche kopiert, das auf den ersten Blick brauchbar aussah).

Und wenn es nur um das nicht ständig neu anmelden geht: da braucht man kein SSO, aber es reicht ggf. ein Token zu vergeben, welches eine gewisse Lebensdauer hat. Dann wird nur das Token gesichert. Das läuft dann sozusagen etwas auf eine Session hinaus, die eine lange Lebensdauer hat ...
 

Thallius

Top Contributor
Wenn der key mit den Windows Credentials erzeugt wird und ich jedesmal wieder hole bevor ich mich damit authentifiziere wie soll dann jemand den key wo anders herbekommen außer das er sich mit seinen credentials an Windows anmeldet?
 

Thallius

Top Contributor
Also es lässt sich prinzipiell eine Autorisierung über Zertifikate aufbauen. Aber das hat mit der Windows Integrated Authentication nichts mehr zu tun (was die Nutzung des Windows Accounts bedeutet, wobei das nur Sinn macht, wenn es eine klare Vertrauensstellung gibt. Und das wäre die Windows Domäne bzw. ein LDAP/Kerberos was ja ein AD implementiert)

Wenn du ein SSO haben willst, das eben von Windows unabhängig ist, dann gibt es diesbezüglich einige Möglichkeiten. Ein Überblick / Einführung gibt z.B.
(Einfach mal das erste Ergebnis einer Google Suche kopiert, das auf den ersten Blick brauchbar aussah).

Und wenn es nur um das nicht ständig neu anmelden geht: da braucht man kein SSO, aber es reicht ggf. ein Token zu vergeben, welches eine gewisse Lebensdauer hat. Dann wird nur das Token gesichert. Das läuft dann sozusagen etwas auf eine Session hinaus, die eine lange Lebensdauer hat ...

genau Das will ich ja nicht. Wenn der User sich bei Windows angemeldet hat soll er ohne weitere Eingabe von Passwörtern auch zugriff auf meine Rest api haben
 

httpdigest

Top Contributor
Wenn der key mit den Windows Credentials erzeugt wird und ich jedesmal wieder hole bevor ich mich damit authentifiziere wie soll dann jemand den key wo anders herbekommen außer das er sich mit seinen credentials an Windows anmeldet?
Das Problem ist doch nicht, aus welchen Informationen der Key hergestellt wird, sondern, wie dein App Server, gegen den du dich mit solch einem Key ja authentifizieren möchtest, die Authentizität des Keys beweisen kann. Es kann ja jeder x-beliebige User auf der Welt Keys generieren und sich damit mit deinem Server versuchen anzumelden.
Natürlich wirst du die Keys dann in deinem Server manuell und nach erfolgter manueller Authentizitätsprüfung des Key-Anfragenden hinterlegen. Und genau hier ist es dann aber egal, aus welchem Material der Key erzeugt wurde, da du ja sowieso aus anderen Quellen erstmal sicherstellen musst, dass die Authentizität desjenigen, der den Key erzeugt und dir geschickt hat, auch stimmt.
 

Thallius

Top Contributor
Das Problem ist doch nicht, aus welchen Informationen der Key hergestellt wird, sondern, wie dein App Server, gegen den du dich mit solch einem Key ja authentifizieren möchtest, die Authentizität des Keys beweisen kann. Es kann ja jeder x-beliebige User auf der Welt Keys generieren und sich damit mit deinem Server versuchen anzumelden.
Natürlich wirst du die Keys dann in deinem Server manuell und nach erfolgter manueller Authentizitätsprüfung des Key-Anfragenden hinterlegen. Und genau hier ist es dann aber egal, aus welchem Material der Key erzeugt wurde, da du ja sowieso aus anderen Quellen erstmal sicherstellen musst, dass die Authentizität desjenigen, der den Key erzeugt und dir geschickt hat, auch stimmt.
Das läßt sich ja umgehen indem man die erst Autorisierung durch ein login sichert. Es geht ja nur darum dass der User eben nicht jedesmal den Login eingeben muss und dass ich diese Login Daten eben nicht lokal auf dem Rechner haben will.
 

httpdigest

Top Contributor
Lasse die User deiner App dich kontaktieren. Du überprüfst die Authentizität des Users bzw. ob dieser überhaupt im Besitz deiner App ist und sich nicht als jemand solches ausgibt (üblicherweise wird dies durch einen vorgenommenen Bezahlvorgang und mit E-Mail sichergestellt - insbesondere dient die E-Mail hier als Authentizitätsbeweis) und du stellst ihnen ein Token (nennen wir es hier eine "Lizenz") aus, mit dem sich dann der App Client gegen deinen App Server authentizifizeren kann.
Anders ist es nicht möglich, legitime App User von anderen Usern zu unterscheiden, da alles, was deine App eventuell kann auch von einem nicht legitimierten User/Client ausgeführt werden kann. Hinweis: Traue NIEMALS dem Client oder alles, was er dir eventuell sendet.
 
K

kneitzel

Gast
Die Frage ist doch: wenn die Windows Autorisierung ausreichen soll: wie stellst du sicher, dass die Autorisierung gültig ist?

Ich habe einen Windows PC, niemand hindert mich, einen Account Thallius anzulegen. Und schon meldet sich mein PC an Deinem Webservice als Thallius und du vertraust dem?

Damit der Windows Logon vertrauensvoll ist, muss:
- der Rechner vertrauensvoll sein. Windows Systeme sind daher auch im AD mit abgesicherten Computer Konto.
- dem Login muss vertraut werden können. Das wäre im AD das vertrauenswürdige Token, das geprüft werden kann. Sprich: Ich melde mich beim AD Controller an und bekomme ein Kerberos Ticket. Dieses kann ich dann vorzeigen.
 

Thallius

Top Contributor
Die Frage ist doch: wenn die Windows Autorisierung ausreichen soll: wie stellst du sicher, dass die Autorisierung gültig ist?

Ich habe einen Windows PC, niemand hindert mich, einen Account Thallius anzulegen. Und schon meldet sich mein PC an Deinem Webservice als Thallius und du vertraust dem?

Damit der Windows Logon vertrauensvoll ist, muss:
- der Rechner vertrauensvoll sein. Windows Systeme sind daher auch im AD mit abgesicherten Computer Konto.
- dem Login muss vertraut werden können. Das wäre im AD das vertrauenswürdige Token, das geprüft werden kann. Sprich: Ich melde mich beim AD Controller an und bekomme ein Kerberos Ticket. Dieses kann ich dann vorzeigen.

das ist doch quatsch. Wenn Windows den key aus den credentials erzeugt, dann müßtest du beim erstellen meines Accounts auch noch mein Passwort wissen sonst bekommst du einen anderen Key
 

httpdigest

Top Contributor
Okay, folgendes Szenario:
1. Ich besitze deine App nicht
2. Ich generiere mir einen Schlüssel nach dem skizzierten hypothetischen Verfahren aus meinem Windows User mit Namen "kunibert" und Passwort "blablubb"
3. Ich schicke dir diesen Schlüssel
4. Was tust du jetzt damit? Woher weisst du, dass ich legitimiert bin, deine App überhaupt zu nutzen?
 
K

kneitzel

Gast
das ist doch quatsch. Wenn Windows den key aus den credentials erzeugt, dann müßtest du beim erstellen meines Accounts auch noch mein Passwort wissen sonst bekommst du einen anderen Key
Du hast den Ablauf nicht verstanden. Das Passwort geht ja nie an dich. Alles, was du bekommst, ist eine Info vom System, dass ein User eine Authentifizierung erfolgreich durchgeführt hat.
Also System X hat User Y Authentifiziert.... Und das setzt eine Vertrauensstellung voraus und ohne eine solche ist es nicht denkbar.

Aber wir müssen das auch nicht im Detail durchgehen, denn es existiert keine Vertrauensstellung in der Art nach Deiner Aussage, daher ist es erst einmal egal für Dich.

Und bei allen Abläufen, die du implementiert, musst du gut aufpassen. Es gibt schnell Angriffsszenarien: wenn du also z.B. irgend etwas auf Australia a.la. der User meldet sich an und bekommt ein Zertifikat. Weitere Anmeldungen macht die App nur mit dem Zertifikat...

Wenn jemand dieses Zertifikat in die Hände bekommt, dann reicht dies schon aus, damit der Angreifer sich autorisieren kann? Das kann problematisch sein (ist aber auch nicht unüblich. Dinge in der Art gibt es z.B bei Google bekommt eine App nach Anmeldung ein Token und Token + App Key erlaubt dann schon Zugriff ...)

Wenn du eine Autorisierung brauchst, dann wäre auch hier die Frage: warum selbst implementieren und nicht eine vorhandene Lösung verwenden? Gibt ja einige Lösungen, die sowas anbieten. Dann hättest du ggf eine Autorisierung über OAuth2 in Deiner App ...
 

Dompteur

Top Contributor
Vielleicht habe ich es überlesen. Aber bei den Beiträgen von Thallius konnte ich nirgends lesen, ob der Windows-PC in einem Netzwerk hängt und sich gegen ein Active Directory identifiziert.

@Thallius : Gibt es ein zentrales AD ?

Wenn ja, dann kannst du dir von Windows ein (zeitlich begrenzt gültiges) Token holen. Dieses schickst du zu deinem Server. Dieser validiert das Token.
Am Server hast du nun 2 Alternativen :
* Du läßt dir vom zentrale AD die Gültigkeit des Tokens bestätigen
* Du besitzt ein Keytab File mit den Informationen zum Entschlüsseln des Tokens.

In beiden Fällen muss es dir möglich sein, ein Service im AD anzumelden. Also du brauchst entweder selbst Zugriff auf den AD oder ein Admin richtet dir das ein.

Ich habe vor einiger Zeit Variante 2 implementiert. Dabei hat mir folgender Beitrag sehr geholfen: https://stackoverflow.com/questions/25289231/using-gssmanager-to-validate-a-kerberos-ticket
 

Ähnliche Java Themen

Neue Themen


Oben