none
WindowsIdentity auf Server nachprüfen

    Question

  • Hallo,

    ich möchte in meiner Client/Server Anwendung gern Single Sign On unterstützen, weis aber nicht wie ich die Single Sign On Aktiviert sicher bekomme.

    Ich stelle mir das dabei so vor, das ich mit Hilfe von WindowsIdentity auf dem Client den Domänenbenutzer der versucht mein Programm auszuführen herausbekomme und dann diese Daten meinem Server (der auf einem anderem Rechner läuft) übermittle. Mein Server schaut dann in meiner Datenbank nach, ob ein solcher Domänenbenutzer zulässig ist und meldet den User ggf. an.

    Das Problem dabei ist allerdings, dass ich so sich ja im Prinzip jeder als irgendein Domänennutzer ausgeben könnte (indem er einfach meinem Server sagt, er sei der Nutzer XY). Was ich bräuchte wäre eine Art SessionToken welches ich vom Client bekomme und welches ich von der Domäne gegenprüfen lassen kann.

    Weiss irgendjemand wie so etwas geht?

    Danke.

    Tuesday, August 21, 2012 4:40 PM

Answers

  • Hallo allerseits,

    Ich würde euch folgende Lektüre empfehlen (freier Download):

    Dominick Baier u.a. - A Guide to Claims-Based Identity and Access Control, Second Edition
    http://www.microsoft.com/en-us/download/details.aspx?id=28362

    Dort wird anschaulich erklärt, wie man die Windows Identity Foundation (WIF) mit WCF-Anwendungen verwenden kann.
    Im Standardfall läuft alles darauf hinaus, ADFS oder ACS als Tokenaussteller zu verwenden. 

    Der Mechanismus ist (vereinfacht) dieser:

    1. Der Client schickt die (Windows-)Credentials zum STS-Dienst
    2. Der Dienst authentiziert die Credentials, erstellt Claims für den User und stellt ein Sicherheitstoken aus
    3. Der Client schickt das Sicherheitstoken sowie die konkrete Anfrage zur Anwendung auf dem entfernten Rechner (Server) 
    4. Die Server-Anwendung empfängt und überprüft das Token, parst die signierte Claims-Liste und führt ggf. die Authorisierung der Client-Anfrage durch

    Da hier die gegenseitige Authentifizierung (des Clients, des Dienstes, der Anwendung) über Zertifikate und die Übermittlung über SSL erfolgen kann, braucht man sich über diese Sicherheitsaspekte weniger Gedanken zu machen. Und: Solange Nachrichten mit dem öffentlichen Schlüssel des Empfängers verschlüsselt werden, kann nur der Empfänger die Nachrichten (über den privaten Schlüssel) entschlüsseln.

    Man könnte in Versuchung geraten, diesen Mechanismus in selbstgestrickter Sicherheitssoftware replizieren zu wollen. Davon rate ich ab. An die Programmierung eigener Sicherheitssoftware würde ich mich nur dann machen, wenn die Verwendung von WIF/ADFS aus trifftigen Gründen unmöglich ist.

    Ab .NET 4.5 wird übrigens WindowsIdentity nicht mehr direkt von System.Object abgeleitet, sondern von System.Security.Claims.ClaimsIdentity, was die Verwendung anspruchbasierter Authorisierung durch im Framework eingebackene Klassen wesentlich vereinfacht.

    Windows Identity Foundation 4.5 – Übersicht (ich empfehle die englische Version)
    http://msdn.microsoft.com/de-de/library/hh291066(v=vs.110).aspx

    Gruß
    Marcel

    Wednesday, August 22, 2012 1:17 PM
    Moderator

All replies

  • Ich bin daran auch sehr interessiert :-)

    Gruß
    Rudolf

    "Der Nachteil der Intelligenz besteht darin, dass man ununterbrochen gezwungen ist, dazuzulernen." Georg Bernhard Shaw

    Wednesday, August 22, 2012 6:39 AM
  • Hallo allerseits,

    Ich würde euch folgende Lektüre empfehlen (freier Download):

    Dominick Baier u.a. - A Guide to Claims-Based Identity and Access Control, Second Edition
    http://www.microsoft.com/en-us/download/details.aspx?id=28362

    Dort wird anschaulich erklärt, wie man die Windows Identity Foundation (WIF) mit WCF-Anwendungen verwenden kann.
    Im Standardfall läuft alles darauf hinaus, ADFS oder ACS als Tokenaussteller zu verwenden. 

    Der Mechanismus ist (vereinfacht) dieser:

    1. Der Client schickt die (Windows-)Credentials zum STS-Dienst
    2. Der Dienst authentiziert die Credentials, erstellt Claims für den User und stellt ein Sicherheitstoken aus
    3. Der Client schickt das Sicherheitstoken sowie die konkrete Anfrage zur Anwendung auf dem entfernten Rechner (Server) 
    4. Die Server-Anwendung empfängt und überprüft das Token, parst die signierte Claims-Liste und führt ggf. die Authorisierung der Client-Anfrage durch

    Da hier die gegenseitige Authentifizierung (des Clients, des Dienstes, der Anwendung) über Zertifikate und die Übermittlung über SSL erfolgen kann, braucht man sich über diese Sicherheitsaspekte weniger Gedanken zu machen. Und: Solange Nachrichten mit dem öffentlichen Schlüssel des Empfängers verschlüsselt werden, kann nur der Empfänger die Nachrichten (über den privaten Schlüssel) entschlüsseln.

    Man könnte in Versuchung geraten, diesen Mechanismus in selbstgestrickter Sicherheitssoftware replizieren zu wollen. Davon rate ich ab. An die Programmierung eigener Sicherheitssoftware würde ich mich nur dann machen, wenn die Verwendung von WIF/ADFS aus trifftigen Gründen unmöglich ist.

    Ab .NET 4.5 wird übrigens WindowsIdentity nicht mehr direkt von System.Object abgeleitet, sondern von System.Security.Claims.ClaimsIdentity, was die Verwendung anspruchbasierter Authorisierung durch im Framework eingebackene Klassen wesentlich vereinfacht.

    Windows Identity Foundation 4.5 – Übersicht (ich empfehle die englische Version)
    http://msdn.microsoft.com/de-de/library/hh291066(v=vs.110).aspx

    Gruß
    Marcel

    Wednesday, August 22, 2012 1:17 PM
    Moderator
  • Hallo kampfkeks23,

    Ich gehe davon aus, dass die Antwort Dir weitergeholfen hat.
    Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

    Grüße,
    Robert


    Robert Breitenhofer, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Thursday, August 30, 2012 4:32 PM
    Owner