Wenn ich mit anderen Entwicklern über CardSpace spreche höre ich leider immer wieder die gleichen Vorurteile über CardSpace. Das kommt wohl daher, dass viele die CardSpace nicht kennen erstmal von Passport ausgehen und vermuten, dass CardSpace wohl so ähnlich sein muss. Dabei haben aber beide Technologien nichts miteinander zu tun, mal abgesehen davon, dass beide von Microsoft sind.
Einige dieser Vorurteile sind:
"Meine Daten werden bei Microsoft gespeichert"
Falsch! Bei CardSpace gibt es keine zentralen Server, die alle Daten des Anwenders speichern. Daten werden entweder lokal auf dem Rechner des Anwenders gespeichert (bei sogenannten selbstausgestellten Karten) oder auf dem Server eines Identitätsanbieters (bei verwalteten Karten). Im Prinzip kann jeder der das möchte ein Identitätsanbieter für CardSpace werden. Mögliche Identitätsanbieter könnten z.B. Banken, Universitäten, Vereine oder vielleicht sogar Behörden sein. Das hängt ganz davon ab, was man mit CardSpace mache möchte.
"CardSpace funktioniert doch nur mit dem Internet Explorer und Windows"
Falsch! CardSpace basiert auf offenen und freien Standards. Jeder der möchte, kann diese Standards selbst implementieren. So gibt es z.B. schon CardSpace Identity-Selektoren ("CardSpace UIs") für Firefox und Safari. Die Standards, auf denen CardSpace basiert sind z.B.: WS-Trust, WS-Security und SAML, um nur einige zu nennen.
"CardSpace funktioniert doch sicher nur mit ASP.NET Web Servern"
Falsch! CardSpace lässt sich problemlos mit beliebigen Web Servern und Webtechnologien nutzen, da es auf freien und offenen Standards basiert. Kim Cameron, einer der Architekten von CardSpace, hat z.B. CardSpace in sein Wordpress (PHP) Blog integriert.
"CardSpace in meine Webseite einbauen ist zu kompliziert"
Falsch! Je nachdem mit welcher Plattform man arbeitet gibt es bereits viele fertige Bibliotheken und Beispiele, die man nutzen kann, um CardSpace in eigene Webseiten zu integrieren. Am einfachsten geht das natürlich mit ASP .NET, dafür gibt es einfach schon die meisten Beispiele. Es gibt aber auch schon CardSpace Bibliotheken für PHP [1], [2] und Java. Mit solchen fertigen Beispielen und Bibliotheken lässt sich CardSpace mit wenigen Zeilen Code in eigene Webseiten integrieren. Auf Plattformen wo es solche Bibliotheken noch nicht gibt ist das natürlich wirklich aufwändiger. In dem Fall hängt es davon ab, wie gut die jeweilige Plattform die von CardSpace verwendeten Technologien unterstützt, insbesondere XML Encryption, XML Signaturen und SAML Tokens. Diese Arbeit muss aber für jede Plattform nur einmal von irgendjemandem gemacht werden. Früher oder später wird es für alle wichtigen Plattformen CardSpace Bibliotheken geben.
"CardSpace ist nicht kostenlos"
Falsch! Zumindest CardSpace selbst basiert auf offenen und frei verfügbaren Standards und kann somit ohne Lizenzgebühren verwendet werden. Allerdings benötigt CardSpace eine verschlüsselte Verbindung über HTTPS und somit SSL Zertifikate. Die sind aber gar nicht so teuer wie man zunächst denkt (was man z.B. daran sieht, dass ich mir eins für mein Blog leisten konnte ;) ). SSL Zertifikate gibt es ab ca. $15 pro Jahr. Für den Einsatz in kommerziellen Projekten also quasi "Peanuts", für den privaten Einsatz aber sicher nicht ganz unproblematisch. Eine mögliche Alternative für den privaten Einsatz sind kostenlose Zertifikate von startssl.com. Diese Zertifikate funktionieren mit CardSpace jedoch nur bei Anwendern, die das CA Root Zertifikat von startssl auf ihrem Rechner installiert haben.
"CardSpace ist nicht interoperabel zu anderen Identitätstechnologien (OpenID, ...)"
Falsch! CardSpace ist sogar so extra konzipiert, dass es wunderbar mit anderen Technologien zusammenarbeiten kann. Die CardSpace-Spezifikation schreibt z.B. nicht vor, welches Sicherheitstokenformat für die Authentifizierung mit CardSpace verwendet werden soll. Selbstausgestellte Karten arbeiten mit SAML Tokens, die auch in anderen ID-Technologien wie z.B. Shibboleth oder Liberty Alliance und natürlich SAML selbst verwendet werden. Bei verwalteten Karten kann ein beliebiges Securitytokenformat verwendet werden. Solange der Identitätsanbieter und die Relying Party (= z.B. die Webseite, gegenüber der man sich authentifiziert) beide eine gemeinsame "Sprache" sprechen und das Token verstehen ist das Format vollkommen egal.
Auch mit OpenID kann man CardSpace wunderbar verwenden. Im xmldap CardSpace Identity Selector kann man z.B. eine OpenID als "verwalte Karte" nutzen. Eine weitere sinnvolle Anwendungsmöglichkeit ist der Einsatz von CardSpace als Authentifizierungsmöglichkeit gegenüber einem OpenID-Identitätsanbieter. OpenID selbst ist anfällig gegenüber Phishing. Diese Schwäche lässt sich vermeiden, wenn man beide Technologien kombiniert. Ich bin gerade dabei, diese Idee von Kim umzusetzen und einen OpenID-Server zu schreiben, der CardSpace als Authentifizierung nutzen kann - mehr dazu später in einem eigenen Eintrag.
"Durch CardSpace kann ein Profil über die Seiten die ich besuche erstellt werden"
Falsch! Bei CardSpace authentifiziert man sich nicht mit nur einer Identität, sondern man besitzt beliebig viele Karten und somit auch Identitäten. Selbst wenn die gleiche Karte auf mehreren Seiten eingesetzt wird, enthält die Karte für jede Seite eine eigene PPID (private personal identifier). Wenn ich z.B. eine Karte auf Seite A und Seite B verwende, so hat Seite A keine Möglichkeit, die Daten aus der Karte zu verwenden, um sich unter meinem Namen auf Seite B anzumelden.
Ein Identitätsanbieter sieht (in der Standardeinstellung) auch nicht, auf welchen Seiten ich mich mit der Identität dieses Anbieters authentifiziere. Er kann also kein Profil über mich erstellen. Für Anwendungsfälle, in denen diese Information dennoch notwendig ist, ist das möglich, dann wird der Benutzer bei der Verwendung der Karte darauf hingewiesen, dass der Identitätsanbieter diese Information erhält.
"Wenn mein Computer gestohlen/gehackt wird hat der Dieb/Hacker zugriff auf alle meine Identitäten"
Falsch! Um auf die Karten eines Benutzeraccounts zugreifen zu können müsste jemand, der den Computer gestohlen hat, zumindest das Benutzerkennwort kennen. Karten können außerdem zusätzlich mit einer eigenen PIN pro Karte versehen werden, in dem Fall kommt also auch ein angemeldeter Nutzer ohne die PIN nicht an die Karten. Die Karten werden besonders geschützt auf dem Rechner gespeichert und sind doppelt verschlüsselt (mit einem Schlüssel des jeweiligen Benutzers und mit dem des Systems). Selbst ein Administrator hat so ohne das Kennwort des Nutzers keinen Zugriff auf die Karten. Selbst wenn er das Nutzerkonto ändert hat er keinen Zugriff, der Schlüssel wäre in dem Fall zerstört (wie z.B. auch bei Verschlüsselung im Dateisystem). Verwaltete Karten können zusätzlich geschützt werden, z.B. über SmartCards oder ein zusätzliches Passwort. Die Daten von verwalteten Karten sind ja außerdem sowieso beim Identitätsanbieter gespeichert, der sie ausgestellt hat.
Das CardSpace User Interface wird in einem eigenen, abgeschotteten Desktop angezeigt. Andere Prozesse haben auf diesen Desktop keinen Zugriff. Ein Trojaner hätte also keine Möglichkeit, CardSpace fernzusteuern und den Benutzer irgendwo anzumelden oder seine Daten aus der CardSpace Benutzeroberfläche zu stehlen.
Ich hoffe ich konnte mit diesem Artikel einige Vorurteile beseitigen. Wer neugierig geworden ist und jetzt mehr über CardSapce erfahren möchte sollte auf der CardSpace Seite und in Kims IdentityBlog beginnen.