CardSpace und Identity Metasystem

Vor wenigen Stunden wurde myhealth präsentiert (pilot Projekt). Myhealth ist ein aus Silverlight basiertes Portal das von dem Changi Spital in Singapur gemanaged ist. Myhealth bietet allen Singapur Bürger eine Web Seite, wo sie Ihre Fitness und Gesundheitsinformationen managen können. Was sehr interessant ist, dass der Zugriff auf vertrauliche Daten von einer Managed Card gesichert wird, die von der Singapur Regierung an Ihre Bürger verteilt wird.

Aber was ist genau eine Managed Card? Sagen Ihnen Identity Metasystem oder CardSpace überhaupt irgend etwas? Wenn nicht, dann nehmen sie sich eine halbe Stunde Zeit um diesen Blog Post zu lesen….

Es ist schon lange, dass ich einen Post über CardSpace und das Identity Metasystem schreiben wollte. Nun ist es Zeit CardSpace innerhalb unserem Team-Blog zu präsentieren. Tatsächlich in der letzten Zeit wurde sehr viel Interesse rund um das Cardspace und die Microsoft Vision über das Identity Metasystem gezeigt. Es wurden auch viele Ansagen in diesem Bereich über die Zusamennarbeit von Microsoft mit Dritten gemacht (Beispiel: https://www.microsoft.com/presspass/press/2007/oct07/10-09ZendPR.mspx).

Ich werde also versuchen Ihnen die Grundkonzepte zu erklären; aber starten wir von Anfang an…

Wenn Sie jemanden das erste Mal treffen und Sie möchten mit dieser Person ein Gespräch führen das keinen Austausch von vertraulichen Informationen enthält, dann können Sie einfach das Gespräch starten indem Sie Ihren Vornamen sagen. Wenn es sich aber um vertraulichen Informationen handelt, dann möchten Sie genau wissen wer diese Person ist, bevor Sie überhaupt bereit sind, Vertrauen in dieser Person zu haben. Sie möchten genau eine Antwort auf die Frage „Wer sind Sie“ haben.
Im Vergleich mit der Vergangenheit ist die „Wer sind Sie“ Frage wichtiger geworden und der Grund wieso diese Frage heute sehr wichtig ist, ist weil wir heute in einer verbundenen Welt leben; die Annahme von Produkten, die im Internet vorhanden sind ist explodiert. Denken Sie wie Internet unser Leben beeinflusst hat: heute kann man praktisch alles suchen und kaufen, von Musik, Filmen, Kurse oder Ferien; wir zahlen unsere Rechnungen, wir füllen unsere Steuererklärung via Internet aus….Sie können sogar einen Partner kennenlernen J… Wirklich alles coole Sachen!

Aber während die Verwendungsfähigkeit von Internet gewachsen ist, ist das Vertauen der Menschen in Internet verringert. Diese Krise des Vertrauens in Internet ist wirklich real: jeder Bericht zeigt wie das Vertrauensniveau von den Leuten im vergleich vor vielen Jahren (als die Leute für das erste Mal Internet anwanten) vermindert ist. Wieso das? Weil Internet ein gefährlicher Ort sein kann; es gibt „Phishing“ und online „Identity Fraud“. Ausserdem sind Benutzer frustriert, Sie müssen sich an eine Menge von Benutzernamen und Passworte erinnern.

Der Grund wieso wir alle diese Probleme haben, ist weil Internet ohne ein digitales Identitätsystem konzepiert wurde. Als Microsoft haben wir in der Vergangenheit probiert dieses Problem mit Passport zu lösen, ein einziges Authentisierungssystem, sodass Benutzer einen einzigen Benutzername und Kennwort für das ganze Web verwenden können. Als Passport lanciert wurde, waren alle daran sehr interessiert. Die Probleme kamen aber auf der Ebene des Vertrauens: wieso sollte Ebay Ihr Authentiesierungssystem zu Passport verlinken? Wieso sollte ein Benutzer seine Identitätsinformationen auf einen Server von Microsoft speichern lassen? Es kann auch rechtliche Probleme geben: empfindliche Informationen die ausserhalb Ihres Landes gespeichert sind.

Es wurde also wirklich klar, dass die Welt nicht ein einziges Authentisierungssystem wollte, aber mehrere. Man wollte wirklich ein einfaches sichereres konsistentes System haben, das auf Open Standard basiert ist, um die digitale Identitäts darzustellen.

So, Was ist genau die Lösung?

Man spricht von „Identity Metasystem“ und das Konzept die digitale Identität als ein Set von „claims“ daruzustellen. Als Beispiel wenn ich sage „mein Name ist Casada, Ich bin Schweizer, Ich bin ein MS Mitarbeiter, Ich bin 28“ all diese Angaben sind „claims“ über mich, von mir selber gemacht. Es gibt aber auch Angaben welche von Dritten über mich gemacht werden. Zum Beispiel in meinem Passport steht klar geschrieben, dass ich Ken Casada bin. Ein „claim“ is also eine Bestätigung der Wahrheit über etwas. Alle diese „claims“ werden innerhalb einem „Security Token“ platziert.

Wenn wir über das Identity Metasystem sprechen haben wir immer 3 Spieler: der „Subject“ (der Benutzer), einen dritten Teil, genannt „Identity Provider“ die den „Security Token“ erstellt und die Relying Party die es konsumiert. Ein „identity provider“ ist eine Entität die claims über dem Benutzer produziert. Als Beispiel ein „Identity Provider“ könnte eine Regierung sein die claims über Ihre Bürger produziert, oder eine Bank die meine Bankenkoordinaten produziert oder ich selber wenn ich „claim“ über mich selber mache.

Der Identity Provider ist schlussendlich ein Dienst der einen „Security Token“ produziert. Die Relying Party, die der Konsument der Token ist, kann eine Web Seite oder ein Web Dienst sein.

So, was passiert wenn ein Benutzer auf einer Web Seite navigiert und sich authentisieren muss? Der Benutzer muss zuerst einen „Identity Provider“ selektieren, welcher Ihm einen „Security Token“ mit allen „Benutzerclaims“ freigibt und so kann der Benutzer seinerseits den „Security Token“ zu der Relying Party freigeben.

Was wir noch brauchen ist ist ein Stück software auf der client Maschine das den ganzen Prozess managen kann (welche Informationen zu wem geschickt werden) und dem Benutzer die Möglichkeit gibt den „Identity Provider“ zu wählen. Was wir brauchen ist einen sogenannten „Identity Selector“, und Microsoft Identity Selector heisst Windows CardSpace . Aber wie kann der Benutzer einen „Identity Provider“ selektieren? Wenn Sie von der Polizei gefragt werden sich zu identifizieren, werden Sie sehr wahrscheinlich Ihren Führerscheinausweis zeigen, wenn ein Businessman nach Ihnen KontaktInformationen fragt, werden Sie Ihm eine Visitenkarte geben. Der Punkt ist hier, dass wir Karten verwenden, um uns zu identifizieren! Also die offensichtliche Art (klar nicht die Einzige) um sich zu identifizieren ist virtuelle Karten zu benutzen und jede Karte wird ein „Identity Provider“ darstellen.

CardSpace ist Teil von dem .NET Framework 3.0 und bietet eine reiche, konsistente „User Experience“ (funktioniert immer auf die gleiche Weise egal wo sie verwendet wird) und hilft Benutzer besser Ihre Identität zu kontrollieren. Cardspace ist sicher, schützt Benutzer von „Phishing“ und „Phraud“ und ist auf offene Standards basiert. Das bedeutet, dass irgend jemand mit irgend einer Technologie die diesem offenen Standard entspricht, zum Beispiel einen „Identity Provider“ oder eine „Relying Party“ erstellen kann und CardSpace wird ohne Probleme funktionieren (es ist wichtig zu sagen, dass auch andere „Identity Selector“ für andere Platformen wie Linux und Mac existieren).

Bild 1 – Windows CardSpace

Ich habe virtuelle Karten erwähnt, Karten die einen Identity Provider darstellen. Karten können von 2 Typologien sein: persönliche Karten (auch als „self issued card“ bekannt) und managed Karten. Persönliche Karten werden bei einem Benutzer erstellt und beinhalten eine fixe Anzahl von „claims“. Diese Karten werden lokal auf den Client gespeichert. Managed Karten werden von einem Dritten (Bank, Regierung) dem Benutzer im Form einer XML Datei (.CRD File) zur Verfügung gestellt. Managed Karten beinhalten keine „claims“ Werte sondern nur die nötigen Informationen um sich mit dem „Identity Provider“ zu authentisieren.

Wenn Sie auf einer Web Seite navigieren, die Cardspace als Authentifizierungsmethode implementiert, und probieren sich einzuloggen (Sie können selber auf https://sandbox.netfx3.com/login.aspx?ReturnUrl=/default.aspx probieren), wird CardSpace gestarted (CardSpace kann auch via Control Panel lanciert werden). Das erste Mal, wenn Sie sich via CardSpace auf einer bestimmten Web Site authentifizieren, wird Ihnen CardSpace einen Dialog zeigen, wo alle Zertifikatinformationen der Web Site dargestellt werden. Hier hat der Benutzer die Möglichkeit die Entscheidung zu treffen, ob er der spezifischen Web Seite vertrauen möchte und schlussendlich ob er bereit ist, dieser Web Seite vertrauliche Informationen zu schicken. Die Zertifikatinformationen sehen unterschiedlich aus abhängig von der Typlogie der Zertifikate die die Web Seite verwendet. Tatsächlich wenn die Web Seite die letzte Generation von Zertifikate benutzt (die sogenannte „Extended Value“ oder „High Assurance“ Zertifikate), werden zusäzliche Informationen dargestellt, wie zum Beispiel das Logo. EV Zertifikate sind teurer und gleichzeitig sicherer, weil der Prozess um ein solches Zertifikat von einer CA (Certification Authority) zu erhalten komplexer ist. Die alten SSL Zertificate sind natürlich auch immer unterstützt (IE7 erkennt auch die neue EV Typologie von Zertifikaten indem die Adressbar in grün dargestellt wird).

Wenn der Benutzer entscheidet der spezifischen Web Seite zu vertrauen, kann er eine virtuelle Karte selektieren und schicken. Wenn der Benutzer sich schon einmal mit einer spezifischen Karte auf einer spezifischen Web Seite authentifiziert hat, wird diese Karte automatisch selektiert (wird innerhalb der „Cards you’ve sent to this site“ Sektion dargestellt). Das hilft sicher gegen phishing.

Betrachten wir jetzt den ganzen Prozess ein bisschen im Detail und um das zu machen verwende ich folgendes Bild das alle Interaktionen zeigt.

                                                               Bild 2 – Protokoll Drill Down

1. Der Benutzer möchtet eine Resource auf der Relying Party zugreifen: es kann eine Web Seite oder einen Web Dienst sein.
2. Die RP schickt dem Benutzer Client die Identitätsanforderungen: welche „claims“ gebraucht sind, evtl. welcher Identity Provider angefordert ist. Alle diese Anforderungen werden innerhalb eine Relying Party Policy definiert und diese Policy wird mit „WS-Security“ beschrieben. Die Policy wird via „WS-MetadataExchange“ geholt. Im Fall einer Web Seite ist die Policy mit HTML definiert und via HTTPS geholt.
3. Nun wird CardSpace Dialog gezeigt. CardSpace erhält die Anforderungen und kann eine Selektion der Karten machen, die den Anforderungen entsprechen.
4. Der Benutzer selektiert eine Karte (schlussendlich selektiert er ein Identity Provider). Im Fall eines self-issued Karte, sind der Client und der Identity Provider eine einzelne Entität (CardSpace bietet tatsächlich einen built-in identity provider)
5. Eine token Abfrage wird dem Itentity Provider geschickt. Die erste CardSpace Version unterstützt 4 authentisierungs Optionen: mit username/password, kerberos tickets, x.509 v3 Zertifikate oder XAML token (erstellt bei einem self-issued identity provider)

    6-7 Er wird zum Benutzer (client) geschickt (via WS-Trust) der die Herausgabe des Token zur RP bestätigt
          (via WS-Security oder HTTPS im Fall von einer Web Seite)

Was müssen Sie machen um CardSpace innerhalb Ihrer Web Seite zu unterstüzen? Es ist ziemlich einfach: sie müssen im Prinzip einen <object> Tag vom Typ „application/x-informationcard“ innerhalb Ihrer Web Seite definieren. Der Browser erkennt diesen Tag (im Moment nur IE7 und FireFox) und kann deshalb CardSpace starten. Auf der Server Seite müssen Sie dann den erstellte Token entschlüsseln und verifizieren; sodass man auf die „
Claims“ zugreifen kann und schlussendlich mit dem Ziel den Benutzer zu authentisieren. Alles ist in diesem Dokument im Detail beschrieben.

Wenn Sie das Thema Identity/CardSpace vertiefen möchten, hier eine Liste von Links, die Ihnen sicher nütlich sein wird:

Viel Spass,

Ken