Smart Clients in .NET: Leicht installieren, einfach verteilen, sicher betreiben

1. Smart Clients in .NET:Leicht installieren, einfach verteilen, sicher betreiben Christof Sprenger Technologieberater .NET Strategy & Developer Group Microsoft GmbH

2. Agenda • Motivation • „Definition“ des Begriffs Smart Client • Grundlagen • Versioning in .NET • Security in .NET • Einzelne Aspekte • No-Touch Deployment • Security und No-Touch Deployment • Automatisches Update • Zusammenfassung

3. Motivation

4. Thin Clients • Applikation die mit einem Browser zu bedienen ist • Denkbar einfaches Deployment • Benutzbarkeit nicht gut wurde/wird aber immer besser • Menu Bars • Toolbars • Keyboard Shortcuts • „Standard“-UI • Was ist mit State? • Benutzereinstellungen • Session • Speichern von Dokumenten

5. Typische Thin Client Layer

6. Rich Clients • Auch Desktop Applikationen genannt • Jedes UI Feature verfügbar • State Handling denkbar einfach • Die Resourcen/Dienste des Betriebssystems und der Hardware sind vollständig nutzbar • Prozessor, • Festplatte, • Graphik, • Eingabegeräte, … • Die Folge daraus: • Bessere Responsiveness, • Bessere Performance, • Bessere Integrierbarkeit, …

7. Smart Clients • Es gibt nicht nur die beiden Wege • Rich (Fat) Clients • Thin Clients • Smart Client nutzen die Vorteile beider Architekturen • Reichhaltiges UI • Einfaches State Management • Deployment über das Web • Daten und Services über das Web

8. Smart Client Layer

9. Weitere mögliche Features • Offline/Online Fähigkeit • Logik beliebig auf Client oder Server ausführbar • Auto Update

10. .NET Framework & Smart Clients • Was bietet .NET um das zu ermöglichen? • Windows Forms für reichhaltiges UI • Einfachen Zugriff auf Server Logik mit Web Services • No Touch Deployment • Zero Impact Install • Sauberes Versioning von Komponenten • Ende der DLL-Hell • Security Modell • Rechtezuweisung an Code (nicht nur Benutzer) • „Baukasten für Sandboxes“ ! ! ! !

11. Grundlagen:Versioning in .NET

12. Das Problem • Eine Applikation wird installiert… • … und läuft nicht, weil benötigte DLLs nicht gefunden werden oder nicht kompatibel sind • … und läuft problemlos, aber andere Applikationen auf der Maschine haben plötzliche Probleme mit fehlenden oder inkompatiblen Versionen von benötigten DLLs

13. Was erreicht werden soll • Verhinderung von "Nebenwirkungen" • Neue Applikationen sollen bereits installierte Applikationen nicht negativ beeinflussen • Zero Impact Install • Unkompliziertes Deployment • Installation durch Kopieren • Verschieben von Applikationen • Pflege der Software • Bugfixes auf einfache Weise ausliefern • Krisenmanagement: Was tun, wenn der Bugfix neue Bugs enthält? • Hotfixes für einzelne Applikationen

14. Sorgenkind Registry • Aufgabe der Registry • Auffinden von gemeinsam genutzen Komponenten (Identity, Binding) • Informationen über Komponenten speichern (Metadaten) • Probleme • Es gibt nur eine Registry nicht eine Pro Applikation • Registry-Pflege bei Installation, Deinstallation und Wartung ist mühsam und fehleranfällig

15. Versionierungsärger • Bisher: Der „Highlander-Effekt“ • Eine gemeinsam genutzte Komponente konnte nur einmal vorhanden sein • Die Komponente musste deshalb abwärtskompatibel sein mit allen Vorgängerversionen • Direkte Konsequenzen • Aufwändiges Testen auf Kompabilität • Was tun, wenn eine Applikation mit einer neuen Komponentenversion Probleme hatte? • Die Folge war/ist die sogenannte DLL-Hell

16. Ein neues Komponentenmodell • Komponenten unter .NET • enthalten alle wichtigen Daten über sich selbst in Metadaten-Tabellen • nehmen diese Informationen mit, wohin sie auch gehen • „Strong Names“ geben jeder Komponente eine eindeutige, sichere Identität • Die Registry wird unnötig für Komponenten-Metadaten und Identität

17. Assembly Binding • Laden von Komponenten • Benötigte Komponenten werden vom CLR Loader über einen festgelegten Algorithmus gesucht (Assembly Binding Algorithm) • Das Suchverhalten ist bei Bedarf pro Applikation konfigurierbar • Die Registry wird unnötig für das Auffinden von Komponenten (Binding)

18. Assembly Manifest • Das Manifest enthält • Assembly name • Version number • Culture • Strong name Information • Public Key des Herstellers • Liste aller FIles die das Assembly bilden • Liste der Typen die Referenziert werden • Liste von referenzierte Assemblies • assembly's name, version, culture und public key

19. Strong Name • Ein Strong Name einer Assembly besteht aus • Dem einfachen textuellen Namen • Einer Versionnummer (Major, Minor, Revision, Build) • Culture Information (optional) • Plus ein Public Key und eine Digitale Signature der Assembly • Strong-Named Assemblies ermöglichen • Uniqueness • Versions-„Abstammungslinien“ • Integrity Check • Damit die Kette nicht bricht können Strong-Named Assemblies nur wiederum andere Strong-Named Assemblies referenziern.

20. Der Ladevorgang • Bestimmen der korrekten Version • Konfigurationsdateien: application configuration, publisher policy, machine configuration. • Überprüfung des Global Assembly Cache • Lokalisieren der Datei • Suche im Codebase Verzeichniss • Sonst das sogenannte Probing • Suche im Application Base Verzeichniss und in den Unterverzeichnissen mit dem Namen der Assembly und der Culture • Suche im binpath Verzeichniss und in den Unterverzeichnissen mit dem Namen der Assembly und der Culture

21. Diagramm zum Ladevorgang

22. Grundlagen:Security in .NET

23. Das Problem

24. Mobiler Code heute • Code aus diversen Quellen – speziell dem Internet/Intranet • Code darf entweder nichts oder alles (was der Benutzer darf) • Benutzer muss Entscheidung über vertrauenswürdigen Code "on the fly" treffen • Kann er dies? • Zertifikate helfen wenig

25. Code Access Security • Granulares Sicherheitsmodell für "partially trusted" Code • Orthogonal zu nutzerbasierter OS-Sicherheit • Beruht auf Indizien ("evidence") über Assemblies  auch evidence-based security genannt • Verwaltung durch Sicherheitsregeln ("policies") • CLR berücksichtigt bei Ausführung die dem Code zugestandenen Rechte ("permissions") • Frei erweiterbar

26. Evidence • Woher/Von Wem kommt dieser Code? • Charakterisierung pro Assembly • Ist unabhängig vom Ausführenden • Stammt vom Host (Anwendung, IE, ASP.NET, ...) oder vom Assembly selbst • Die Base Class Library (BCL) definiert: • Publisher (Authenticode-Zertifikate) • Site (Website, von der Assembly geladen wird) • Url • Zone (IE-Sicherheitszone) • StrongName • ApplicationDirectory • Hash

27. Permissions • Was könnte dieser Code tun? • Feingranulare Rechte, die an .NET-Code verliehen werden können • Schützen Ressourcen & Operationen • Checks zur Lauf- oder Compile-Zeit • Verwendung: • Vergeben durch Sicherheits-Policy • Von Assembly angefordert • Deklarativ & imperativ • Sind unabhängig voneinander (orthogonal)

28. FileIO FileDialog IsolatedStorage Environment Registry UI Printing Reflection Security Socket Web DNS OleDb SQLClient MessageQueue EventLog DirectoryServices … erweiterbar Permissions in der BCL Execution, Assertion, Skip Verification, Unmanaged code, Control evidence, Control policy, Control principal, Control threads

29. Sicherheitsregeln • Begriffe: • Bedingung (membership condition): Boolesche Funktion, die Evidenz auswertet • Permissionset: Gruppierung von Permissions (FullTrust, LocalIntranet, ...) • Codegroup: besteht aus einer membership condition und einem permission sets P Bedingung ? Codegruppe

30. Policy Level • Codegruppen werden hierarchisch in sogenannten Policy Levels angeordnet • Meist werden alle Child-CodeGroups untersucht nachdem eine Memership Condition zutrifft (Union Code Group)

31. Enterprise policy Machine2 policy Machine1 policy User A User B User C User D Sicherheitsrichtlinien • Richtlinien (policy levels): Permissionsets + Codegruppenhierarchie + vertrauenswürdige Assemblies • Effektive Richtlinie: Schnittmenge der einzelnen Ebenen

32. Demo • .NET Konfiguration Configuration

33. Assembly A1 Dem Assembly gewährte Rechte R Assembly A2 Call Stack P R1 R2 P Vergleich von P mit den Rechten R aller aufrufenden Assemblies P R3 Methode in A4 fordert Permission P an R4 P Assembly A3 AssemblyA4 Rechteanforderung • Permission demand: Überprüfung, daß alle Aufrufer ausreichende Rechte haben • stack walk: schützt gegen sog. "luring attack" • Kann vorzeitig abgebrochen werden • Assert(), Deny(), PermitOnly()

34. Imperative Sicherheitsprüfung • Alle Permission-Objekte haben Demand()-Methode • Ausführung zur Laufzeit wie normale Methode • Vorteil: flexibel & variabel Public Sub New(fileName As String) ' Must fully qualify the path for the security check Dim fullPath As String = _ Directory.GetFullPathInternal(fileName) New FileIOPermission(FileIOPermissionAccess.Read, _ fullPath).Demand() … '[rest of function] End Sub

35. Deklarative Sicherheitsprüfung • Aktionen durch custom attributes beschrieben • In den Metadaten abgespeichert • Können mittels PERMVIEW.EXE oder Metadaten-APIs gelesen werden • Check zur Lauf- oder Linkzeit • Demand() zur Laufzeit • LinkDemand(), InheritanceDemand() beim Linken • Linkzeit-Aktions werden automatisch vom JIT-Compiler durchgeführt, wenn Aufrufer kompiliert oder Klasse geladen wird • Für Laufzeit-Deklarationen erzeugt der JIT-Compiler Code, der die Sicherheitsprüfung durchführt

36. Deklarative Sicherheitsprüfung • Nachteil: Deklarationen können keine Laufzeitvariablen enthalten <FileIOPermission(SecurityAction.Demand, _Write:="c:\temp")> _ Public Sub Foo() ' Subroutine implementation End Sub

37. Host Evidence Permission Requests Assembly A1 G1 Assembly A2 G2 G3 Assembly A3 G3 Und jetzt alles zusammen … Assembly A3 Security Policy Policy Evaluator

38. Demo • Simple Applikation • Über C:\.... • Über \\localhost\c$\... • Über \\127.0.0.1\c$\...

39. Starten von Applikationen über HTTP

40. No-Touch Deployment • Der Assembly Loader ist in der Lage Assemblies über HTTP zu laden • Assembly wird in den Download Cache kopiert und von dort ausgeführt •  Starten von Desktop Applikationen über einen Link im Browser

41. No-Touch Deployment • Versioning greift • Security greift • Abhängige Assemblies werden nachgeladen • Controls im Browser • Ähnlich, aber nicht ganz das gleiche • Sieht aus wie ActiveX Controls • Jedoch anderes Security Modell • Kommunikation mit HTML möglich

42. Demo • TaskManager

43. Erster Download GET /foo.exe HTTP/1.1Accept: */*Accept-Language: en-usAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705)Host: localhostConnection: Keep-Alive HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Fri, 01 Feb 2002 02:11:29 GMT Content-Type: application/octet-stream Accept-Ranges: bytes Last-Modified: Fri, 01 Feb 2002 01:41:16 GMT ETag: "50aae089c1aac11:916" Content-Length: 45056 …

44. Folgende Downloads GET /foo.exe HTTP/1.1Accept: */*Accept-Language: en-usAccept-Encoding: gzip, deflateIf-Modified-Since: Fri, 01 Feb 2002 01:41:16 GMTIf-None-Match: "50aae089c1aac11:916" User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705)Host: localhostConnection: Keep-Alive HTTP/1.1 304 Not Modified Server: Microsoft-IIS/5.1Date: Fri, 01 Feb 2002 02:42:03 GMTETag: "a0fa92bc8aac11:916" Content-Length: 0

45. Wann wird was runtergeladen? • Beim ersten Download kann die Runtime die Version nicht kennen • Beim zweiten Download wird auch dann geladen wenn • Datei neuer aber • Version kleiner • Abhängige Assemblies • Zuerst wird überprüft ob die richtige Version im Cache • GAC wird immer zuerst überprüft

46. Security und No-Touch Deployment

47. Security und No-Touch Deployment • Applikationen, die über http://www.server.com gestartet wurden sind im Normalfall in der Code Group Internet • In Version 1.0 war dort das PermissionSet Internet eingetragen • Im ServicePack 1 ist dort das PermissionSet Nothing eingetragen

48. Top-Level Code Groups • Im Auslieferungszustand haben die Top-Level CodeGroups Membership-Conditions die sich an der Zone orientieren

49. Security Zones • MyComputer_Zone • PermissionSet: FullTrust • LocalIntranet_Zone Permissions • FileDialog • IsolatedStorage • Printing • … • Internet • PermissionSet: Nothing

50. FileIO- und FileDialogPermission • Die Permission FileIO ermöglicht Assemblies den Zugriff aufs FileSystem • Dies ist meist zu viel • FileIO findet sich nur im PermissionSet Everything • Die Klasse FileDialog hat Methode OpenFile • FileDialogPermission ist ausreichend • Property FileName benötigt FileIOPermission