MSDN Magazin > Home > Ausgaben > 2007 > April >  Identität: Sichern von ASP.NET-Anwendungen...
Identität
Sichern von ASP.NET-Anwendungen und WCF-Diensten mit Windows CardSpace
Michèle Leroux Bustamante

Themen in diesem Artikel:
  • Windows CardSpace und Informationskarten
  • Webbrowser und Identitätsauswahl
  • Sicherheitstoken
  • Integration mit WSFederationHttpBinding und ASP.NET-Mitgliedschaft
In diesem Artikel werden folgende Technologien verwendet:
.NET Framework 3.0
Laden Sie den Code für diesen Artikel herunter: CardSpace2007_04.exe (462 KB)
Code online durchsuchen
Im Mai 2005 hat Microsoft seine Vision eines Identitätsmetasystems eingeführt, das die mit der Verwaltung und dem Austausch von digitalen Identitäten verbundenen Komplexitäten und Risiken verringern soll. Diese Vision wurde im Artikel Die Version von Microsoft für ein Identitätsmetasystem besprochen. Es werden Interaktionen erklärt, die auf Interoperabilitätsstandards basieren, wie z. B. WS-Security, WS-Trust, WS-MetadataExchange, WS-SecurityPolicy und andere WS-*-Protokolle. Diese Protokolle versetzen Anwendungen und Dienste in die Lage, ihre Sicherheitsanforderungen über Sicherheitsrichtlinien zu kommunizieren und digitale Identitäten sicher und zuverlässig zu übertragen. Das Identitätsmetasystem beschreibt eine einfache und konsistente Vorgehensweise, mit der sich Benutzer gegenüber Anwendungen und Diensten identifizieren können. Gleichzeitig wird die Zielsite für den Benutzer identifiziert, um Risiken zu verringern, die mit dem Senden von privaten Informationen an nicht autorisierte oder schädliche Websites verbunden sind.
Windows CardSpace™ (früher als „InfoCard“ bekannt) wurde mit Windows Vista™ und Microsoft® .NET Framework 3.0 veröffentlicht und spielt in diesem Identitätsmetasystem eine wichtige Rolle. Windows CardSpace ersetzt die traditionelle Authentifizierung über Benutzername und Kennwort durch ein Tool, mit dem Benutzer ihre digitalen Identitäten einfacher verwalten können. Darüber hinaus wird ein verbesserter Schutz vor verschiedenen Formen von Identitätsangriffen (z. B. Phishing) geboten.
In diesem Artikel werden zunächst die Rollen aller Parteien innerhalb des Identitätsmetasystems untersucht. Windows CardSpace wird vorgestellt, und es werden sowohl persönliche als auch verwaltete Informationskarten erörtert. Anschließend wird anhand einiger Szenarios für ASP.NET-Webanwendungen und Windows Communication Foundation-Dienste erläutert, wie Windows CardSpace für diese Szenarios als Authentifizierungsmechanismus integriert werden kann.
In diesem Artikel wird vorausgesetzt, dass Sie bereits etwas Erfahrung mit ASP.NET sowie Windows Communication Foundation haben und mit Windows CardSpace-Features vertraut sind. Eine ausführliche und empfehlenswerte Übersicht über Windows CardSpace enthält der Artikel Einführung in Windows CardSpace von David Chappell. Zusätzliche Hintergrundinformationen enthalten die beiden Artikel von Keith Brown mit den Titeln Ein erster Einblick in InfoCard und Ausführlichere Informationen über InfoCard.

Windows CardSpace und Informationskarten
Im Identitätsmetasystem gibt es drei Hauptteilnehmer: Relying Party (RP), Subjekt und Identitätsprovider (IP). Die Relying Party kann im Prinzip alles sein (in der Regel eine Anwendung oder ein Dienst), was zum Ausführen bestimmter Aufgaben, wie z. B. zum Anmelden und zum Angeben von Mitgliedschaftsdetails, Token akzeptiert. In diesem Artikel wird aufgezeigt, wie ein Subjekt die Windows CardSpace-Identitätsauswahl verwenden kann, um die für die Authentifizierung zu verwendenden Anmeldeinformationen zu wählen und anzugeben.
Das Subjekt ist eine Person, die der Relying Party Informationen (wie z. B. Identifizierungsinformationen) sicher anzeigen möchte. Diese Informationen werden in Form eines Sicherheitstokens übermittelt, das von einem Identitätsprovider, wie z. B. einer Bank, einem Arbeitgeber oder einer Regierung, ausgestellt wird.
Der Identitätsprovider ist für das Ausstellen des Sicherheitstokens für das Subjekt verantwortlich. Er verbürgt sich für die Subjektinformationen, die von den Ansprüchen im Token beschrieben werden. Der Identitätsprovider wird in der Regel als Security Token Service (STS) implementiert. Dabei handelt es sich um einen Webdienstendpunkt, der das WS-Trust-Protokoll implementiert. Ziel ist es, die ein Subjekt beschreibenden Sicherheitstoken auszustellen, zu erneuern, zu überprüfen oder abzubrechen.
Abbildung 1 Teilnehmer des Identitätsmetasystems (Klicken Sie zum Vergrößern auf das Bild)
Abbildung 1 veranschaulicht die Beziehung zwischen den drei Parteien. Die Relying Party verwendet für die Autorisierung von Aufrufen einen besonderen Sicherheitstokentyp. Der Identitätsprovider authentifiziert das Subjekt und stellt ihm ein Sicherheitstoken in dem Format aus, das von der Relying Party angefordert wird. Das Subjekt überträgt anschließend das Token, das Ansprüche für das Subjekt enthält, an die Relying Party. Die Trennung dieser Rollen und die für die Kommunikation verwendeten Interoperabilitätsprotokolle sind Teil der Vision des Identitätsmetasystems. Jeder Teilnehmer kann auf einer anderen Technologie oder Plattform implementiert werden, die mit den entsprechenden Web- und WS-*-Protokollen kompatibel ist, um eine interoperable Kommunikation zu ermöglichen.
Im Kontext dieses Identitätsmetasystems nimmt Windows CardSpace zwei Rollen ein. Erstens ist Windows CardSpace eine Clienttechnologie, die für die sichere und konsistente Erstellung, Verwaltung und Auswahl digitaler Identitäten verwendet wird. (In der letzteren Kapazität dient Windows CardSpace als Identitätsauswahl). Zweitens besitzt Windows CardSpace einen lokalen Identitätsprovider für persönliche digitale Identitäten und kann Sicherheitstoken für diese Identitäten generieren.
Eine digitale Identität wird als Informationskarte dargestellt. Windows CardSpace ermöglicht es Benutzern, persönliche Karten zu erstellen oder verwaltete Karten zu importieren, die von anderen Identitätsprovidern ausgestellt werden. Die Benutzer können dann zu einem späteren Zeitpunkt eine Karte auswählen, wenn eine Relying Party die Kartenauthentifizierung anfordert. Der Benutzer kann nur Karten auswählen, die die Anforderungen der Relying Party erfüllen, oder er kann eine persönliche Karte auswählen und die notwendigen Ansprüche dynamisch hinzufügen. Der zugeordnete Identitätsprovider stellt dann das Sicherheitstoken mit den entsprechenden Subjektansprüchen aus.
Karten werden von einem Identitätsprovider ausgestellt, um die Ansprüche zu beschreiben, für die sich der Identitätsprovider verbürgen kann, und zwar im Namen eines authentifizierten Subjekts. Jede Karte stellt wichtige Informationen über den ausstellenden Identitätsprovider bereit, einschließlich der folgenden:
  • Die URL (oder URLs) des Identitätsprovider-Security Token Service (STS), der die Sicherheitstoken ausstellt. Wenn der Benutzer eine Karte für die Authentifizierung gegenüber einer Relying Party auswählt, ist Windows CardSpace bekannt, wo das Sicherheitstoken mit den entsprechenden Ansprüchen angefordert wird.
  • Die der Karte zugeordneten Anspruchsarten. Da der Identitätsprovider die Karte ausstellt, definiert er die Ansprüche der Karte. Die Relying Party gibt die benötigten Ansprüche an, und die Benutzer können nur Karten mit diesen Ansprüchen auswählen.
  • Die Sicherheitstokentypen, die der Identitätsprovider ausstellen kann. Die Relying Party zeigt das unterstützte Token an, sodass nur Karten für die Auswahl aktiviert werden können, die diese Token unterstützen.
Eine von einem Identitätsprovider ausgestellte Karte kann als signiertes XML-Dokument mit einer CRD-Dateierweiterung serialisiert werden. Die CRD-Datei enthält einen Abschnitt mit dem Namen <InformationCard>, der diese und andere Informationen für Windows CardSpace enthält. Abbildung 2 stellt ein Beispiel für eine signierte verwaltete Karte dar, die in Windows CardSpace importiert wurde.
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
  <dsig:SignedInfo>...</dsig:SignedInfo>
  <dsig:SignatureValue>...</dsig:SignatureValue> 
  <dsig:KeyInfo>...</dsig:KeyInfo>
  <dsig:Object Id="_Object_InfoCard">
    <ic:InformationCard xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity" 
xmlns:mex="http://schemas.xmlsoap.org/ws/2004/09/mex" 
xmlns:wsa="http://www.w3.org/2005/08/addressing" 
xmlns:wsid="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" 
xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xml:lang="en-us">
      <ic:InformationCardReference>
        <ic:CardId>http://www.thatindigogirl.com/card/
            ED18504F-40B9-5A58-C200-761DC886DF29</ic:CardId> 
        <ic:CardVersion>1</ic:CardVersion> 
      </ic:InformationCardReference>
      <ic:CardName>thatindigogirl</ic:CardName> 
      <ic:CardImage MimeType="image/png">[base64 encoded image]
          </ic:CardImage> 
      <ic:Issuer>http://www.thatindigogirl.com/tokenissuer.svc</ic:Issuer> 
      <ic:IssuerName>That Indigo Girl</ic:IssuerName> 
      <ic:TimeIssued>2006-12-29T22:32:17Z</ic:TimeIssued> 
      <ic:TimeExpires>9999-12-31T23:59:59.9999999Z</ic:TimeExpires> 
      <ic:TokenServiceList>
        <ic:TokenService>
          <wsa:EndpointReference>
            <wsa:Address>http://www.thatindigogirl.com/sts/tokenissuer.svc

                </wsa:Address> 
            <wsa:Metadata><mex:Metadata><mex:MetadataSection>
                  <mex:MetadataReference><wsa:Address>
                        http://www.thatindigogirl.com/sts/mex</wsa:Address> 
                  </mex:MetadataReference>
            </mex:MetadataSection></mex:Metadata></wsa:Metadata>
            <wsid:Identity>
              <ds:KeyInfo><ds:X509Data>
                  <ds:X509Certificate>[base64 encoded 
                       certificate of the IP]</ds:X509Certificate> 
              </ds:X509Data></ds:KeyInfo>
            </wsid:Identity>
          </wsa:EndpointReference>
          <ic:UserCredential>
            <ic:UsernamePasswordCredential>
              <ic:DisplayCredentialHint>Please enter your 
                   password</ic:DisplayCredentialHint>
              <ic:Username>thatindigogirl</ic:Username> 
            </ic:UsernamePasswordCredential>
          </ic:UserCredential>
        </ic:TokenService>
      </ic:TokenServiceList>
      <ic:SupportedTokenTypeList>
        <wst:TokenType>urn:oasis:names:tc:SAML:1.0:assertion
            </wst:TokenType> 
      </ic:SupportedTokenTypeList>
      <ic:SupportedClaimTypeList>
        <ic:SupportedClaimType Uri=
            "http://schemas.xmlsoap.org/ws/2005/05/identity/ 
                claims/personalprivateidentifier">
          <ic:DisplayTag>PPID</ic:DisplayTag> 
          <ic:Description>Unique identifier for the card</ic:Description> 
        </ic:SupportedClaimType>
        ...other claim types
      </ic:SupportedClaimTypeList>
      <ic:PrivacyNotice>http://www.thatindigogirl.com/PrivacyPolicy.txt 
      </ic:PrivacyNotice> 
    </ic:InformationCard>
  </dsig:Object>
</dsig:Signature>
Es gibt zwei Arten von Karten: Persönliche Karten und verwaltete Karten. Persönliche Karten (auch als selbst ausgestellte Karten bezeichnet) werden vom Benutzer in Windows CardSpace erstellt und vom lokalen Windows CardSpace-Identitätsprovider ausgestellt. Verwaltete Karten können von einem anderen Identitätsprovider ausgestellt werden und müssen explizit in Windows CardSpace importiert werden.
Die Interaktion zwischen dem Subjekt, der Relying Party, den Karten sowie den zugehörigen Identitätsprovidern und Windows CardSpace wird in Abbildung 3 dargestellt. Wenn eine Website oder ein Dienst (die Relying Party) ein Token benötigt, das von Windows CardSpace ausgestellt wird, gibt sie die erforderlichen Ansprüche an. Die Clientanwendung (ein Browser oder ein Webdienstclient) ruft Windows CardSpace auf (1) und gibt diese Informationen weiter. Windows CardSpace verwendet diese Informationen, um die entsprechenden Karten anzuzeigen, die diese Ansprüche an den Benutzer erfüllen (2). Wenn der Benutzer eine Karte auswählt (3), authentifiziert Windows CardSpace den Benutzer mithilfe einer vom Identitätsprovider definierten Methode. Der entsprechende Identitätsprovider wird dem Verweis auf der Karte gemäß aufgefordert (4), ein Sicherheitstoken auszustellen, das die Ansprüche der Relying Party (5) enthält. Jedoch obliegt es dem Identitätsprovider zu bestimmen, welche Ansprüche das Token enthält (ein Superset oder ein Subset der Ansprüche in der Richtlinie der Relying Party). Schließlich wird ein signiertes und verschlüsseltes Sicherheitstoken zurück an die Anwendung oder den Webbrowser (6) übergeben, die bzw. der es an die Relying Party (7) weiterleitet.
Abbildung 3 Auswahl von Karten und ihre Verwendung für die Ausstellung von Sicherheitstoken (Klicken Sie zum Vergrößern auf das Bild)
Karten werden auf dem lokalen Computer in einer Datei gespeichert und gesichert, die zweimal verschlüsselt ist. Zudem werden sie durch einen Computerschlüssel, Ihre Windows-Anmeldung und optional durch eine PIN-Nummer geschützt, die von Ihnen für einen sicheren Zugriff auf die Karte zur Verfügung gestellt wird. Wenn Sie mehrere Computer verwenden, können Sie die Karten in eine verschlüsselte Datei exportieren und anschließend auf einen anderen vertrauenswürdigen Computer importieren.

Persönliche Karten
Persönliche Karten werden über die Windows CardSpace-Systemsteuerung erstellt. Wenn Sie eine persönliche Karte erstellen, werden eigentlich zwei Dinge erstellt: Ein Satz an Ansprüchen, die persönliche Informationen darstellen, und eine Karte, die diese Ansprüche auflistet. Der lokale Windows CardSpace-Identitätsprovider stellt in erster Linie persönliche Karten über die von Ihnen angegebenen Ansprüche aus. Darüber hinaus werden Ihre Ansprüche während des Wartens auf eine Anforderung für ein Sicherheitstoken gespeichert. Abbildung 4 stellt dar, wie eine persönliche Karte dem Windows CardSpace-Identitätsprovider anzeigt, welche Ansprüche in ein angefordertes Sicherheitstoken eingefügt werden sollen.
Abbildung 4 Generieren eines Sicherheitstokens von einer persönlichen Karte (Klicken Sie zum Vergrößern auf das Bild)
Beim Erstellen einer persönlichen Karte können Sie nur Informationen für einige oder alle Ansprüche aus einem vordefinierten Satz aus 15 Ansprüchen eintragen. Dazu gehören u. a. Vor- und Nachname, E-Mail-Adresse und Postadressinformationen. Die Ansprüche werden von einem URI aus dem WS-Identitätsnamespace dargestellt: schemas.xmlsoap.org/ws/2005/05/identity. Abbildung 5 führt den URI für die Ansprüche auf, die eine persönliche Karte speichern kann (die URIs werden aus Gründen der Übersichtlichkeit abgekürzt).
http://schemas.xmlsoap.org/.../identity/claims/privatepersonalidentifier
http://schemas.xmlsoap.org/.../identity/claims/name
http://schemas.xmlsoap.org/.../identity/claims/givenname
http://schemas.xmlsoap.org/.../identity/claims/surname
http://schemas.xmlsoap.org/.../identity/claims/emailaddress
http://schemas.xmlsoap.org/.../identity/claims/streetaddress
http://schemas.xmlsoap.org/.../identity/claims/locality
http://schemas.xmlsoap.org/.../identity/claims/stateorprovince
http://schemas.xmlsoap.org/.../identity/claims/postalcode
http://schemas.xmlsoap.org/.../identity/claims/country
http://schemas.xmlsoap.org/.../identity/claims/homephone
http://schemas.xmlsoap.org/.../identity/claims/otherphone
http://schemas.xmlsoap.org/.../identity/claims/mobilephone
http://schemas.xmlsoap.org/.../identity/claims/dateofbirth
http://schemas.xmlsoap.org/.../identity/claims/gender
http://schemas.xmlsoap.org/.../identity/claims/webpage
Das Erstellen von persönlichen Karten unterscheidet sich nicht wesentlich vom Erstellen eines Benutzernamens und eines Kennworts für eine Website. Websites und Webdienste können Ihrem Benutzerkonto persönliche Karten zuordnen, sodass Sie mithilfe von Windows CardSpace Ihre Identität mit wenigen Mausklicks auswählen können, anstatt den Benutzernamen und das Kennwort eingeben zu müssen. Ein eindeutiger Bezeichner, der auf dem persönlichen privaten Bezeichner der Karte (PPID) basiert, wird für das Zuordnen einer Karte zu einem Konto verwendet. Dieser Bezeichner ist für jede Kombination aus Karte und Relying Party eindeutig. Wenn folglich die gleiche Karte für mehrere Relying Partys verwendet wird, erhält jede Relying Party eine andere PPID, um die Datensicherheit der Verwendungsmuster des Benutzers zu gewährleisten.

Verwaltete Karten
Im Unterschied zu den persönlichen Karten können verwaltete Karten alle Ansprüche darstellen, die der Identitätsprovider über ein Subjekt bestätigen möchte. (Die eigentlichen Kartendaten sind innerhalb der Systeme des Identitätsproviders und nicht auf dem lokalen Computer gespeichert). Sie können verwaltete Karten nicht in der Windows CardSpace-Schnittstelle erstellen, weil der lokale Identitätsprovider für Windows CardSpace nur Karten für einen festgelegten Satz an Ansprüchen ausstellen kann. Jeder Identitätsprovider kann verwaltete Karten mit denjenigen Ansprüchen ausstellen, für die er Sicherheitstoken generieren kann. Da eine Beziehung zwischen der Relying Party und dem Identitätsprovider existieren muss, können die beiden z. B. im Besitz des gleichen Unternehmens sein.
Wenn Sie beispielsweise ein Konto bei einer Bank haben, die Ihre Kontonummer und den Typ kennt, kann der Identitätsprovider eine Karte ausstellen, die angibt, dass ein Sicherheitstoken mit den Ansprüchen ausgestellt werden kann. Um die Risiken einer Anmeldung über den Benutzernamen und das Kennwort an dem Konto zu vermeiden, kann die verwaltete Karte in Windows CardSpace installiert werden, sodass der Benutzer sie für die Authentifizierung bei Bankingwebsites auswählen kann. Dies setzt voraus, dass die Bank Ihrem Konto die Karte während der Ausstellung zugeordnet hat. Andernfalls müssen Sie einen zusätzlichen Schritt durchführen, um die Karte nach der Installation zuzuordnen.
Wenn der Benutzer diese Karte für die Authentifizierung bei der Banking-Relying Party auswählt, können nur kompatible verwaltete Karten ausgewählt werden, die diese Ansprüche erfüllen. Verwaltete Karten enthalten die eigentlichen Anspruchstypen nicht. Windows CardSpace kennt jedoch den Speicherort des Identitätsproviders, um das verschlüsselte Token auszustellen, das diese Ansprüche enthält. Abbildung 6 illustriert, wie die verwaltete Karte dem verwalteten Identitätsprovider anzeigt, welche Inhalte das angeforderte Sicherheitstoken benötigt.
Abbildung 6 Generieren eines Sicherheitstokens von einer verwalteten Karte (Klicken Sie zum Vergrößern auf das Bild)
Alle Relying Partys und Identitätsprovider, die eine Beziehung haben, sollten sich auf die Ansprüche einigen, die im Sicherheitstoken enthalten sein sollen. Diese Ansprüche können durch eindeutige URIs identifiziert werden. Bedenken Sie beispielsweise die folgenden CRUD-Ansprüche (Create/Read/Update/Delete – Erstellen, Lesen, Aktualisieren, Löschen):
http://www.thatindigogirl.com/2006/06/claims/create
http://www.thatindigogirl.com/2006/06/claims/read
http://www.thatindigogirl.com/2006/06/claims/update
http://www.thatindigogirl.com/2006/06/claims/delete
Eine Anwendung oder ein Dienst könnte diese Ansprüche verwenden, um eine anspruchsbasierte Autorisierung anhand von Features und Ressourcen durchzuführen.
Obwohl verwaltete Karten vom lokalen Computer gesichert werden und auf andere Computer exportiert werden können, sind die eigentlichen Ansprüche beim Identitätsprovider gespeichert. Sie werden niemals ohne ein verschlüsseltes Sicherheitstoken übertragen. Der Identitätsprovider verschlüsselt das Sicherheitstoken mit dem öffentlichen Schlüssel der Relying Party, sodass die Ansprüche innerhalb des Tokens auf keinen Fall eingesehen werden können, noch nicht einmal von Windows CardSpace. (Wenn der Benutzer die an die Relying Party zu sendenden Ansprüche in der Vorschau anzeigen möchte, kann ein zusätzliches und optionales Anzeigetoken angefordert werden. Dieses ist so verschlüsselt, dass es in Windows CardSpace entschlüsselt und dem Benutzer angezeigt werden kann.)

Browser und Identitätsauswahl
Es werden andere Identitätsauswahlen erstellt, die die gleiche Funktion wie Windows CardSpace in Windows durchführen. Windows CardSpace oder eine andere beliebige Identitätsauswahl kann für das Auswählen von persönlichen oder verwalteten Karten verwendet werden, um eine Authentifizierungsanforderung zu erfüllen.
Damit Webanwendungen eine persönliche oder verwaltete Kartenauthentifizierung unterstützen können, müssen sie zuerst eine Webseite mit einem Objekttag oder XHTML-Binärverhalten mit einer Beschreibung der Anforderungen für die Informationskarten bereitstellen. Browser, die diese Tags unterstützen und über eine Informationskartenerweiterung verfügen, können die entsprechende Identitätsauswahl auf dem Clientcomputer starten, sodass die Benutzer eine Karte auswählen können. Wie Sie Abbildung 7 entnehmen können, existiert keine bestimmte Verbindung zu Windows CardSpace als Identitätsauswahl, zu Internet Explorer® als Browser oder zu ASP.NET als die Websitetechnologie. Andere Browser besitzen für die Behandlung dieser und anderer Objekttags und Verhalten ihre eigenen Erweiterungen. Zudem kann jedes Betriebssystem seine eigene Identitätsauswahl haben, die Informationskarten unterstützt. Alle aufgeführten Elemente sind plattformunabhängig.
Abbildung 7 Auslösen einer Identitätsauswahl von einem Objekttag oder Binärverhalten (Klicken Sie zum Vergrößern auf das Bild)
Jede beliebige Webanwendungsplattform, einschließlich ASP.NET, kann Seiten verfügbar machen, die das erforderliche Objekttag oder XHTML-Binärverhalten enthalten, mit dem die Identitätsauswahl ausgelöst wird. Das Objekttag verwendet die folgende MIME-Typanwendung/x-informationCard:
<object id="informationCard" name="informationCard" 
        type="application/x-informationCard">
    ...
</object>
Das Informationskarten-Binärverhalten kann in XHTML mithilfe eines #default#informationCard-Verhaltens im <informationCard>-Element angegeben werden.
  <ic:informationCard name="xmlToken" 
      style="behavior:url(#default#informationCard)" ... >
      ...
  </ic:informationCard>
Innerhalb dieser <object>- und <informationCard>-Elemente befinden sich Parameter, mit denen die Anforderungen einer Website an eine Informationskartenauthentifizierung beschrieben werden. Diese Einzelheiten werden unten eingehender erläutert.
Obwohl frühere Versionen von Internet Explorer Objekttags und XHTML unterstützen, unterstützt nur Internet Explorer 7.0 Informationskarten mithilfe einer MIME-Handlererweiterung mit dem Namen „Microsoft IE-Hilfsfunktionen für Informationskarten“, die von icardie.dll bereitgestellt wird. (Es steht eine Erweiterung für die Unterstützung von Windows CardSpace in Mozilla Firefox zur Verfügung.) Der folgende Registrierungsschlüssel verknüpft den MIME-Typ für Informationskarten mit dem Handler:
HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/x-informationCard
Dieser MIME-Handler wird anschließend mit Objekttag- und Verhaltenskonfigurationen für den Browser verknüpft. Der Handler ist für das Aufrufen der Identitätsauswahl verantwortlich und übergibt Parameter, die vom Objekttag oder XHTML-Binärverhalten angegeben werden. Für Internet Explorer 7.0 wird von der Identitätsauswahl standardmäßig Windows CardSpace festgelegt, was durch den folgenden Registrierungseintrag angezeigt wird:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\InformationCard Token Provider
Für die Objekttagsyntax wird der MIME-Handler durch die InformationCardSigninHelper-Klasse ausgelöst, die standardmäßig im Add-Ons-Dialogfeld in Internet Explorer 7.0 aktiviert ist (siehe Abbildung 8). (Sie können auf dieses Dialogfeld zugreifen, indem Sie die Internetoptionen öffnen und auf der Registerkarte „Programme“ die Option „Add-Ons verwalten“ auswählen.) Wenn dieses Add-On deaktiviert ist, löst das Objekttag die Identitätsauswahl nicht aus. Diese Einstellung hat jedoch keinen Einfluss auf die XHTML-Syntax. Das XHTML-Informationskartenverhalten wird in einem Zeichenfolgeneintrag mit der Bezeichnung INFORMATIONCARD unter dem Registrierungsschlüssel konfiguriert:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Default Behaviors 
Abbildung 8 Informationskarten-MIME-Handler in Internet Explorer 7.0 (Klicken Sie zum Vergrößern auf das Bild)
Dieses Verhalten führt auch dazu, dass der MIME-Handler die Identitätsauswahl aktiviert.
Leider erfolgt die konsistente Erkennung von Browserunterstützung für Informationskarten in verschiedenen Browsern auf unterschiedliche Weise. Sie können für Internet Explorer eine vorläufige Überprüfung durchführen, in der UserAgent nach einer CLR-3.0-Unterstützung (Common Language Runtime, gemeinsame Sprachlaufzeit) für Internet Explorer 7.0 und .NET sucht. Diese Vorgehensweise wird allerdings nicht unbedingt empfohlen. Hier ein Beispiel einer UserAgent-Zeichenfolge, die diesen Support anzeigt:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
.NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)
In ASP.NET können Sie möglichen Support auf dem Server überprüfen, indem Sie die UserAgent-Eigenschaft vom Request-Objekt folgendermaßen verwenden:
string userAgent = Request.UserAgent;
if (userAgent.Contains("MSIE 7.0") &&
    userAgent.Contains(".NET CLR 3.0"))
    { Response.Write(
        "Information cards are supported, but might not be enabled."); }
else
    { Response.Write("Information cards may not be supported."); }
Diese Vorgehensweise weist viele Mängel auf. Andere Browser als Internet Explorer unterstützen Windows CardSpace ebenfalls, und selbst bei Unterstützung von Windows CardSpace könnte der MIME-Handler deaktiviert sein. Eine bessere Lösung bietet die Verwendung eines clientbasierten Skripts, mit dem zu erkennen ist, ob der Browser Windows CardSpace unterstützt und ob dieser Support aktiviert ist. Ein Beispiel hierfür finden Sie unter www.fearthecowboy.com/2006/12/detecting-cardspace-support-including.html.
Internet Explorer 7.0 und die entsprechenden MIME-Handlerkonfigurationen sind für das Auslösen von Windows CardSpace über Objekttags und XHTML entscheidend. Darüber hinaus muss die Website SSL-aktiviert sein, um die Kommunikation zu sichern. Zertifikate für die erweiterte Überprüfung (Extended Validation, EV), die von einer vertrauenswürdigen Stammzertifizierungsstelle wie z. B. VeriSign oder Thawte ausgestellt wurden, benötigen keine besondere Konfiguration. Falls Sie jedoch Testzertifikate verwenden, müssen Sie das Test-SSL-Zertifikat als vertrauenswürdigen Stamm installieren und die Website in Internet Explorer 7.0 zu den vertrauenswürdigen Websites hinzufügen. Die Anweisungen hierfür finden Sie in den Codebeispielen für diesen Artikel.

Objekt- und XHTML-Parameter
Wie oben erwähnt, können Sie mithilfe von Objekttags oder XHTML-Binärverhalten eine Identitätsauswahl von unterstützenden Browsern auslösen. Mit jeder Syntax müssen Sie der Informationskartenbrowser-Erweiterung einen Basissatz an Eigenschaften bereitstellen, wie in Abbildung 9 dargestellt.

Eigenschaft Beschreibung
requiredClaims (obligatorisch) Sie können alle persönlichen in Abbildung 5 aufgelisteten oder benutzerdefinierten Ansprüche von einem verwalteten Identitätsprovider anzeigen. Wenn einer der Ansprüche nicht von einer persönlichen Karte erfüllt werden kann, muss zur Erfüllung der Ansprüche eine verwaltete Karte installiert werden.
Aussteller (optional) Zeigt den Identitätsprovider an, von dem ein Sicherheitstoken angefordert wird. Standardmäßig handelt es sich um den URI für persönliche Token: schemas.xmlsoap.org/ws/2005/05/identity/issuer/self. Verwenden Sie diese Einstellung für das Auslösen von Windows CardSpace als Standard.
issuerPolicy (optional) Zeigt die URL für die Sicherheitsrichtlinie des Identitätsproviders an. Für den lokalen Identitätsprovider für Windows CardSpace muss diese Eigenschaft nicht festgelegt werden.
tokenType (optional) Wenn diese Eigenschaft ausgelassen wird, erfolgt eine standardmäßige Einstellung auf den URI für SAML 1.0-Token: urn:oasis:names:tc:SAML:1.0:assertion. Für persönliche Karten können Sie entweder SAML 1.0- oder SAML 1.1-Tokenformate angeben: http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1. Alle anderen Angaben implizieren eine verwaltete Karte.
optionalClaims (optional) Sie können alle persönlichen oder benutzerdefinierten Ansprüche als optional angeben. Dadurch erhält der Benutzer die Möglichkeit, die Informationen an die Website zu senden.
privacyVersion (optional) Gibt die Version der Datenschutzrichtlinie an. Bei Änderungen wird der Benutzer benachrichtigt und erhält die Möglichkeit, diese Änderungen zu überprüfen.
Konfigurieren Sie diese Eigenschaften mithilfe des Objekttags gemäß Abbildung 10. Jeder <param> stellt jeweils den Namen einer Informationskarteneigenschaft dar. Die Werte für requiredClaims und optionalClaims sind durch Leerzeichen begrenzte Listen von Anspruchs-URIs. Wenn die Standardwerte für die Anwendung akzeptabel sind, könnten Sie optional die Aussteller- und tokenType-Parameter unterdrücken.
<object id="informationCards" name="informationCards" 
  type="application/x-informationCard" >
  <param name="issuer" 
    value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self"/>
  <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"/>
  <param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/
        2005/05/identity/claims/privatepersonalidentifier 
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"/>
  <param name="optionalClaims" value="http://schemas.xmlsoap.org/ws/
        2005/05/identity/claims/dateofbirth"/>
</object>
Konfigurieren Sie die Eigenschaften der Informationskarte mithilfe von XHTML gemäß Abbildung 11. In diesem Fall werden Attribute verwendet, um den Verhaltensstil, Aussteller und tokenType anzugeben. Jeder Anspruch wird mit einer <add>-Anweisung angegeben, die den Anspruchs-URI anzeigt und ob er optional ist. Mindestens ein Anspruch muss angegeben werden.
<ic:informationCard name="informationCards"
  style="behavior:url(#default#informationCard)"
  issuer="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self"
  tokenType="http://docs.oasis-open.org/wss/
      oasis-wss-saml-token-profile-1.1#SAMLV1.1">
  <ic:add claimType="http://schemas.xmlsoap.org/ws/2005/05/
       identity/claims/privatepersonalidentifier" optional="false" />
  <ic:add claimType="http://schemas.xmlsoap.org/ws/2005/05/
       identity/claims/emailaddress" optional="false" />
  <ic:add claimType="http://schemas.xmlsoap.org/ws/2005/05/
       identity/claims/dateofbirth" optional="true" />
</ic:informationCard>
In jedem Fall ruft der Browser den MIME-Handler auf und übergibt die Parameter an die Identitätsauswahl, wenn die Schaltfläche „Submit“ (Absenden) auf einer Seite ausgewählt ist, die einen Auslöser für Informationskarten enthält. Wenn eine Karte ausgewählt wurde, wird das signierte und verschlüsselte Token auf der Website in Form eines Parameters bereitgestellt, der nach dem <object>- oder <informationCard>-Bezeichner benannt wurde. In den Abbildungen 10 und 11 ist der Bezeichner informationCards.
Wenn im Browser Informationskarten deaktiviert wurden oder die Website nicht SSL-aktiviert ist, enthält die Formularparametersammlung kein informationCards-Element. Wenn Windows CardSpace gestartet und anschließend vom Benutzer aus irgendeinem Grund beendet wird, wird der informationCards-Formularparameter als leere Zeichenfolge bereitgestellt. Dies trifft auch zu, wenn die Parameter ungültig sind und beim Laden von Windows CardSpace einen Fehler verursachen. In dem Fall muss nichts unternommen werden, es sei denn, der informationCards-Formularparameter enthält ein <encryptedData>-Element.
Wenn Sie entweder die Syntax für <object> oder <informationCard> verwenden, können Sie Windows CardSpace von einer beliebigen ASP.NET-Seite Ihrer Wahl auslösen. Sie müssen jedoch ein paar zusätzliche Schritte ausführen, um sicherzustellen, dass Windows CardSpace nur bei bestimmten Submit-Schaltflächen auf der Seite ausgelöst wird. ASP.NET-Seiten haben ein einzelnes aktives <form>-Objekt. Wenn Sie folglich das <object>- oder <informationCard>-Tag innerhalb des einzigen <form>-Objekts platzieren, löst jede Schaltfläche, die Daten zum Server zurückgibt, Windows CardSpace aus.
Um dies zu verhindern, können Sie das Informationskartenobjekt in den HTML-Header-Abschnitt einfügen und mithilfe des Skripts explizit aufrufen, wenn auf die entsprechende Schaltfläche geklickt wird. Abbildung 12 zeigt eine einfache ASP.NET-Seite. Sie enthält das <object>-Tag im Header sowie eine SelectInformationCard-Funktion, die das Objekt aktiviert und den Rückgabewert in ein ausgeblendetes Eingabefeld einfügt. Innerhalb des <form>-Tags befindet sich ein standardmäßiges ASP.NET-Anmeldesteuerelement sowie ein ImageButton.
<%@ Page Language="C#" AutoEventWireup="true" 
    CodeFile="Login.aspx.cs" Inherits="Login" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html  >
<head runat="server">
  <title>Login</title>
  <!--Declaration of information card object -->
  <object declare id="informationCards" name="informationCards" 
    type="application/x-informationCard" > ... </object>

  <script type="text/javascript" language="javascript">
  function SelectInformationCard()
  {
    var infoCardObject =document.getElementById("informationCards");
    var hiddenToken = document.getElementById("hiddenXmlToken");
    hiddenToken.value = infoCardObject.value;
  }
  </script>
</head>
<body>
  <form id="standardLogin" name="standardLogin" method="post" 
        runat="server">
    <asp:Login ID="Login1" runat="server" />
    <asp:ImageButton ID="cardSpaceSubmit" runat="server" 
        ImageUrl="cardspacelogin.jpg"  
        OnClientClick="SelectInformationCard()" 
        OnClick="CardSpaceLogin" />
    <input id="hiddenXmlToken" type="hidden" name="hiddenXmlToken" 
           value="empty"/> 
  </form>
</body>
</html>
Wenn das Anmeldesteuerelement die Übermittlung durchführt, wird Windows CardSpace nicht aufgerufen, da sich das Objekttag im Headerabschnitt befindet. Wenn der ImageButton die Übermittlung durchführt, wird Windows CardSpace aufgerufen, weil das OnClientClick-Attribut SelectInformationCard aufruft. Sie könnten auch ein benutzerdefiniertes ASP.NET-Steuerelement erstellen, mit dem das Objekttag und das zugeordnete Skript ausgesendet werden. Wichtig ist die Unterscheidung jeder Submit-Schaltfläche, sodass Windows CardSpace nur zum richtigen Zeitpunkt aktiviert wird.

Verarbeiten des Sicherheitstokens
Wie oben erwähnt, wird beim Aufrufen von Windows CardSpace ein signiertes und verschlüsseltes Token bereitgestellt. In dem in Abbildung 12 dargestellten Fall enthält das hiddenXmlToken-Eingabefeld diesen <encryptedData>-Abschnitt, wenn ein Token erfolgreich ausgestellt wird. Wenn Windows CardSpace aktiviert, jedoch vom Benutzer abgebrochen wurde, enthält das Feld eine leere Zeichenfolge. Wenn Windows CardSpace nicht aktiviert werden konnte, ist der anfängliche Wert „empty“ enthalten. Die Windows CardSpaceLogin-Methode wird aufgerufen, wenn die Windows CardSpace-Anmeldeoption auf dieser Seite ausgewählt wurde. Folglich können Sie den Wert des ausgeblendeten Felds überprüfen und von dort aus fortfahren.
Wenn ein verschlüsseltes Token Daten an die Website zurückgibt, besteht zunächst das Problem, dass ASP.NET die Bereitstellung von XML- und HTML-Daten zur Reduzierung der Anfälligkeit für Skripterstellungsangriffe nicht zulässt. Sie empfangen eine HttpRequestValidationException wie die folgende:
System.Web.HttpRequestValidationException: A potentially dangerous 
Request.Form value was detected from the client 
(informationCards="<enc:EncryptedData T...").
Sie können dieses Feature für die ganze Website deaktivieren, indem Sie Folgendes zum <system.web>-Abschnitt Ihrer web.config hinzufügen:
<pages validateRequest="false"/>
In diesem Fall empfiehlt es sich, die Einstellung nur für die Seiten vorzunehmen, die ein Postback mit einem Sicherheitstoken empfangen. Glücklicherweise können Sie diese Einstellung für jede einzelne Seite folgendermaßen festlegen:
<%@ Page Language="C#" AutoEventWireup="true" 
         CodeFile="Login.aspx.cs" Inherits="Login" 
         ValidateRequest="false" %>
Das nächste Problem besteht darin, dass der Tokenverarbeitungscode nicht in ASP.NET integriert ist. Sie müssen das <encryptedData>-Element manuell verarbeiten, das Token entschlüsseln, die Tokensignatur überprüfen und die Ansprüche entnehmen, bevor Sie eine Authentifizierung oder Autorisierung durchführen können. Erfreulicherweise stellt Microsoft eine Beispiel-TokenProcessor-Klasse für die Windows CardSpace-Beispiele zur Verfügung, die mit dem Windows SDK für Windows Vista und .NET Framework 3.0 geliefert werden (Verweis unter msdn2.microsoft.com/aa967562.aspx). Das Codebeispiel für diesen Artikel enthält eine leicht veränderte Version von TokenProcessor.
Um die TokenProcessor-Klasse mit den ASP.NET-Anwendungen zu verwenden, müssen Sie nur den Typ mit dem <encryptedData>-Element erstellen und auf die Ansprüche zugreifen, die im Sicherheitstoken übergeben wurden. Beispiel: Dieser Code sucht die PPID-, emailaddress- und dateofbirth-Ansprüche, die vom oben besprochenen Objekttag benötigt werden:
using Microsoft.IdentityModel.TokenProcessor;

string token = Request.Form["hiddenXmlToken"] as string;
if (!String.IsNullOrEmpty(token)) {
  Token tokenProcessor = new Token(token);
  string ppid = tokenProcessor.Claims[ClaimTypes.PPID];
  string emailaddress = tokenProcessor.Claims[ClaimTypes.Email];
  string dateofbirth = tokenProcessor.Claims[ClaimTypes.DateOfBirth];
}
Auf sehr hoher Ebene funktioniert TokenProcessor folgendermaßen. Das Token wurde mithilfe des SSL-Zertifikats für die Website verschlüsselt. TokenProcessor verwendet den Fingerabdruck dieses Zertifikats, um den zugeordneten privaten Schlüssel zu finden, und setzt standardmäßig den My/LocalMachine-Speicher ein. Der Hostidentität der Webanwendung (in der Regel ASPNET oder NETWORK SERVICE) muss Zugriff auf diesen privaten Schlüssel gewährt werden, ansonsten enthält die Entschlüsselung Fehler. Das entschlüsselte Ergebnis wird anschließend in ein SamlToken konvertiert. Es wird zudem überprüft, dass der Inhalt des Tokens seit der Erstellung des Tokens nicht manipuliert wurde. Nach der Überprüfung stehen Ihrem Code ein Verweis auf das Token und seine Ansprüche zur Verfügung.
Bei persönlichen Karten ist der Schlüssel für die Signatur des SAML-Tokens Ihrer Anwendung nicht bekannt, da er bei der ersten Verwendung auf Ihrer Website dynamisch generiert wird. Folglich können Sie die Signatur für persönliche Karten nicht anhand eines vertrauenswürdigen öffentlichen Schlüssels prüfen. Sie können jedoch ein Hash der PPID in Anspruch nehmen, wenn Sie vorher die Karte einem Benutzerkonto zugeordnet haben.
Da eine Beziehung zwischen der Relying Party und dem Identitätsprovider existiert, sollten Sie für verwaltete Karten einen zusätzlichen Schritt zum Tokenverarbeitungscode der Relying Party hinzufügen. Dies dient der Überprüfung, ob das Token von einem von Ihnen akzeptierten Identitätsprovider signiert wurde. Sie können in diesem Schritt zum Überprüfen der Signatur den öffentlichen Schlüssel des Identitätsproviders verwenden.

Zuordnen von Karten zu einem Konto
Bisher haben wir uns darauf konzentriert, wie Windows CardSpace von ASP.NET ausgelöst wird und wie das resultierende Sicherheitstoken verarbeitet werden kann. Im Folgenden soll erklärt werden, was mit den Ansprüchen innerhalb des Tokens geschieht. Diese Vorgänge hängen vom Kartentyp ab, den Sie auf der Website benötigen: Persönliche Karten oder verwaltete Karten.
Websites, die größtenteils persönliche Karten unterstützen, bieten ihren Benutzern ein verbessertes Anmeldeverfahren. Die unterstützten Anspruchsarten sind bekanntermaßen begrenzt. Die zugehörigen demografischen Informationen könnten jedoch für die Website nützlich sein. Trotz dieser Ansprüche ist weiterhin eine rollenbasierte Autorisierung erforderlich. Eine Methode, die Ihnen das Ausnutzen aller Vorteile ermöglicht, besteht darin, Benutzern die Zuordnung einer persönlichen Karte zu ihrem vorhandenen Konto zu erlauben und die Karte während der Anmeldung zu verwenden, um die Rollen des Benutzers abzurufen.
Abbildung 13 illustriert zu diesem Zweck die Interaktion zwischen dem Benutzer, der Website und Windows CardSpace. Der Benutzer kann die persönliche Karte vorab erstellen und sich anschließend an einem vorhandenen Konto anmelden, um die Karte zuzuordnen. Es ist auch möglich, die Karte während des Zuordnungsvorgangs zu erstellen, wenn nicht bereits eine Karte vorhanden ist, die den Anforderungen der Website entspricht. Nach der Auswahl einer persönlichen Karte für die Zuordnung zur Website wird das resultierende Sicherheitstoken der Website zur Verarbeitung bereitgestellt. Die Ansprüche im Sicherheitstoken müssen ausreichen, um das Benutzerkonto beim Anmelden eines Benutzers mit der Karte aufzurufen.
Abbildung 13 Zuordnen einer persönlichen Karte zu einem Websitekonto (Klicken Sie zum Vergrößern auf das Bild)
Der folgende Code ordnet dem aktuellen Benutzerkonto nur eine Karte zu, wenn der mit den Tokenentsprechungen bereitgestellte E-Mail-Adressanspruch der E-Mail des angemeldeten Benutzers entspricht.
MembershipUser user = Membership.GetUser(this.User.Identity.Name);
if (user.Email == emailaddressClaim) {
    user.Comment = ppidClaim;
    Membership.UpdateUser(user);
}
Dieser Code verwendet das Comment-Feld des Benutzerdatensatzes, um dem Benutzerkonto die PPID der Karte zuzuordnen. Der PPID-Anspruch ist für die Karte und die Empfänger-Relying Party eindeutig und identifiziert folglich den Benutzer eindeutig. (Beachten Sie jedoch, dass Sie die PPID nur verwenden können, wenn die Signatur des Tokens zuerst überprüft und anschließend kryptografisch validiert wurde.)
Wenn sich der Benutzer mithilfe der persönlichen Karte anmeldet, kann der E-Mail-Adressanspruch zum Abrufen des Benutzerkontos mithilfe der ASP.NET Mitgliedschafts-API verwendet werden. Eine passende PPID im Kommentarfeld zeigt an, dass der richtige Benutzer gefunden wurde:
MembershipUserCollection matchingUsers = 
    Membership.FindUsersByEmail(emailaddressClaim);
if (matchingUsers.Count > 0) {
    foreach (MembershipUser user in matchingUsers) {
        if (user.Comment == ppid) {
            authenticatedUser = user;
            break;
        }
    }
}
Wenn das Benutzerkonto gefunden wurde, können die üblichen Schritte zum Erstellen eines Authentifizierungstickets für den Benutzer abgeschlossen werden. Ein einfacher Aufruf von RedirectFromLoginPage kann dies erleichtern:
FormsAuthentication.RedirectFromLoginPage(
    authenticatedUser.UserName, true);
Interessanterweise wird hiermit der Benutzer auch auf traditionelle Weise für die Dauer einer ASP.NET-Sitzung authentifiziert. Folglich funktionieren traditionelle rollenbasierte Sicherheitsprüfungen ebenso anwendungsübergreifend.
Verwaltete Karten führen einen leicht abweichenden Workflow für die Zuordnung von Karten zu Konten ein. Die verwalteten Karten können an die Endbenutzer auf unterschiedliche Art und Weise verteilt werden. So kann Benutzern beispielsweise erlaubt werden, eine Karte nach der Anmeldung an der Website anzufordern. Die Karte wird dann zur späteren Verwendung von der Anmeldeseite der Website in Windows CardSpace importiert. Abbildung 14 stellt diesen Datenverkehr dar.
Da verwaltete Karten jeden beliebigen Satz an Ansprüchen enthalten können, der für den Identitätsprovider und die Relying Party von Bedeutung sein könnte, sind sie möglicherweise für den Autorisierungsprozess sogar noch wichtiger. Ein von einer Relying Party empfangener Satz an Ansprüchen kann der Anwendung eine Liste mit Rechten anzeigen. Aufgrund der rollenbasierten Sicherheit und des fehlenden Konzepts für Ansprüche können in diesem Fall die ASP.NET-Mitgliedschaft und der Rollenanbieter gänzlich umgangen werden.
Abbildung 14 Anfordern und Importierten einer verwalteten Karte zum Anmelden (Klicken Sie zum Vergrößern auf das Bild)

Integrieren von Windows CardSpace in WCF
Browserbasierte Anwendungen eignen sich gut für die Integration in die Windows CardSpace-Authentifizierung. Webdienste benötigen möglicherweise ebenso eine Windows CardSpace-Authentifizierung, sodass Clientanwendungen Windows CardSpace aufrufen, um Sicherheitstoken auf ähnliche Weise auszustellen.
Im Fall von Windows Communication Foundation werden hierfür die Dienstendpunkte für die Verwendung von WSFederationHttpBinding konfiguriert. Dadurch wird eine Sicherheitsrichtlinie für den Dienst generiert, die im WSDL-Dokument (Web Service Description Language) enthalten ist und anzeigt, dass persönliche Token erforderlich sind. Wenn SvcUtil aus dieser WSDL einen Proxy für Windows Communication Foundation generiert, werden entsprechende Clientendpunkte generiert, die eine gleichwertige WSFederationHttpBinding-Konfiguration verwenden. Clientanwendungen verwenden diesen Proxy, um einen Kanal zum Aufrufen des Diensts zu erstellen. Der Proxy behandelt Aufrufe an Windows CardSpace und erfasst ein Sicherheitstoken, das die Ansprüche des Zieldiensts erfüllt. Die entstehende Interaktion entspricht der in Abbildung 3. Hier ist die Relying Party der Windows Communication Foundation-Dienst anstatt einer Webanwendung. Anstelle eines Browsers ist die Clientanwendung der Windows Communication Foundation-Client und -Proxy.
Mithilfe von WSFederationHttpBinding können Sie Windows Communication Foundation-Dienste über HTTP verfügbar machen, die auf einem von einem Identitätsprovider ausgestellten Token beruhen. Der Identitätsprovider kann Windows CardSpace sein. Dies setzt voraus, dass eine persönliche oder verwaltete Karte bereitgestellt wird, um den entsprechenden Identitätsprovider für die Ausstellung des Tokens zu suchen. Der Identitätsprovider kann außerdem explizit konfiguriert werden. Als Folge findet die Tokenanforderung nicht über Windows CardSpace statt. Das Schwerpunkt in diesem Artikel liegt bei der Konfiguration von Windows CardSpace.
Die für WSFederationHttpBinding erforderlichen Parameter sind mit den Anforderungen des Objekttags oder der XHTML-Konfiguration vergleichbar, die zum Auslösen von Windows CardSpace von einer Webseite verwendet werden. Sie müssen einen Aussteller, einen Tokentyp und eine Liste erforderlicher oder optionaler Ansprüche angeben. Der Aussteller muss auf schemas.xmlsoap.org/ws/2005/05/identity/issuer/self eingestellt sein, um Windows CardSpace auszulösen. Das Tokenformat kann ein beliebiges Format sein, das von einer persönlichen oder verwalteten Karte unterstützt wird. Die Ansprüche können ebenso persönlich oder verwaltet sein. Diese Einstellungen bestimmen, ob eine persönliche oder verwaltete Karte die Anforderung für ein Sicherheitstoken erfüllen kann.
Abbildung 15 enthält einen vollständigen <system.serviceModel>-Abschnitt für einen einfachen Windows Communication Foundation-Dienst, der einen WSFederationHttpBinding-Endpunkt bereitstellt. Der <wsFederationHttpBinding>-Abschnitt beschreibt die oben besprochenen Eigenschaften für die Bindungskonfiguration. In diesem Fall müssen SAML 1.1-Token einen PPID- und E-Mail-Adressanspruch enthalten. Der Dienst muss ebenso ein Zertifikat bereitstellen, mit dem ein sicherer Austausch mit Clients ermöglicht wird. Dieses Zertifikat wird im <serviceBehavior>-Abschnitt innerhalb des <serviceCertificate>-Elements angegeben.
<system.serviceModel>
  <services>
    <service name="HelloIndigo.HelloIndigoService" 
        behaviorConfiguration="serviceBehavior">
    <endpoint address="http://localhost:8000/HelloIndigo" 
        contract="HelloIndigo.IHelloIndigoService" 
        binding="wsFederationHttpBinding" 
        bindingConfiguration="wsFed" />
    </service>
  </services>
  <bindings>
    <wsFederationHttpBinding>
      <binding name="wsFed">
        <security mode="Message">
          <message issuedTokenType="http://docs.oasis-open.org/wss/oasis-
wss-saml-token-profile-1.1#SAMLV1.1" negotiateServiceCredential="false" >
            <claimTypeRequirements>
              <add claimType="http://schemas.xmlsoap.org/ 
                    ws/2005/05/identity/claims/privatepersonalidentifier"
                    isOptional="false"/>
              <add claimType="http://schemas.xmlsoap.org/ 
            ws/2005/05/identity/claims/emailaddress" isOptional="false"/>
            </claimTypeRequirements>
            <issuer address=
          "http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self" />
          </message>
        </security>
      </binding>
    </wsFederationHttpBinding>
  </bindings>
  <behaviors>
    <serviceBehaviors>
      <behavior name="serviceBehavior" >
        <serviceCredentials>
          <issuedTokenAuthentication 
            allowUntrustedRsaIssuers="true" />
          <serviceCertificate findValue="RPKey" 
            storeLocation="LocalMachine" storeName="My" 
            x509FindType="FindBySubjectName" />
        </serviceCredentials>
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>
Die allowUntrustedRsaIssuers-Einstellung im <issuedTokenAuthentication>-Element ist wichtig, wenn persönliche Karten in Anspruch genommen werden. Standardmäßig lautet diese Einstellung „false“. Jedoch muss sie für persönliche Karten auf „true“ gesetzt werden, da das entstehende Token mit einem unbekannten privaten Schlüssel signiert ist. Für verwaltete Karten besteht diese Anforderung nicht, da der Dienst wahrscheinlich den öffentlichen Schlüssel eines beliebigen Identitätsproviders installiert, den Sie im Zertifikatspeicher vertrauenswürdiger Personen akzeptieren. Bei verwalteten Karten wird die Signatur des ausgestellten Tokens anhand dieser Liste vertrauenswürdiger öffentlicher Schlüssel geprüft. Darüber hinaus sind benutzerdefinierte Autorisierungsoptionen vorhanden.
Die generierte Clientkonfiguration, die zum Initialisieren des Proxy verwendet wird, entspricht – mit wenigen Ausnahmen – der Dienstkonfiguration. Der Client benötigt Zugriff auf den öffentlichen Dienstschlüssel, um das Token und seine Kommunikation mit dem Dienst zu verschlüsseln. Glücklicherweise generiert SvcUtil eine Base64-codierte Version des öffentlichen Schlüssels mit der Clientendpunktkonfiguration unter <identity>. Dadurch braucht der öffentliche Schlüssel nicht in den Zertifikatspeicher des Clientcomputers installiert zu werden. Diese Konfiguration wird in Abbildung 16 dargestellt. Der <wsFederationHttpBinding>-Abschnitt ist in dieser Abbildung reduziert, da er bereits in Abbildung 15 dargestellt ist. Der Clientproxy wird während der Erstellung mit diesen Informationen initialisiert. Mithilfe der Informationen wird bestimmt, wie das Sicherheitstoken für die Authentifizierung beim Dienst abgerufen werden kann. Der Code zum Aufrufen des Diensts kann ganz einfach sein:
HelloIndigoContractClient proxy = new HelloIndigoContractClient();
string s = proxy.HelloIndigo("Hello");
<system.serviceModel>
  <bindings>
    <wsFederationHttpBinding>...</wsFederationHttpBinding>
  </bindings>
  <client>
    <endpoint address="http://localhost:8000/HelloIndigo" 
        binding="wsFederationHttpBinding"      
        bindingConfiguration="wsFed"
        contract="Client.localhost.HelloIndigoContract" 
        name="wsFed">
      <identity>
        <certificate encodedValue="base64 encoded public key" />
      </identity>
    </endpoint>
  </client>
</system.serviceModel>
Windows CardSpace wird von Windows Communication Foundation beim Client ausgelöst, weil die Ausstellereinstellung vorschreibt, den persönlichen Tokenanbieter zu verwenden. Die angezeigte Identitätsauswahlschnittstelle enthält nur die Karten, die die erforderlichen Ansprüche in der dargestellten Bindung erfüllen. Verwaltete Karten sind erforderlich, wenn der Tokentyp oder die erforderlichen Ansprüche nicht durch persönliche Karten befriedigt werden können.
Bei der Verarbeitung der Ansprüche am Server bestehen jedoch in Bezug auf die Windows CardSpace-Authentifizierung zwischen Windows CardSpace und ASP.NET erhebliche Unterschiede. Im Unterschied zu ASP.NET wird das von Windows CardSpace ausgestellte Sicherheitstoken als Teil der Sicherheitsheader in der SOAP-Nachricht verpackt, die an den Dienst gesendet wird. Vor Aufruf des Dienstvorgangs wird dieses Sicherheitstoken entschlüsselt und überprüft. Außerdem werden die Ansprüche in den Dienstsicherheitskontext extrahiert. Diese extrahierten Ansprüche werden einer Abstraktion hinzugefügt, die als ClaimSet bekannt ist. Sie enthält eine Liste von Ansprüchen und Informationen über den Aussteller der Ansprüche. Für persönliche Karten werden die Ansprüche selbst ausgestellt. Dies bedeutet, dass Sie den öffentlichen Schlüssel des Ausstellers nicht autorisieren. Deshalb ist es wichtig, den PPID-Anspruch der Karte (der eindeutig und geheim ist) einem Konto im System zuzuordnen. Sie können die an AuthorizationContext angehängten Anspruchssätze prüfen und nach einem entsprechenden PPID-Anspruch suchen. Prüfen Sie anschließend die Werte anderer erwarteter Ansprüche auf weitere Autorisierungen, wie in Abbildung 17 gezeigt.
AuthorizationContext authContext = 
    ServiceSecurityContext.Current.AuthorizationContext;

DateTime? birthDate = null;
string ppid = null;

foreach (ClaimSet cs in authContext.ClaimSets)
{
    IEnumerable<Claim> claims = cs.FindClaims(ClaimTypes.PPID, 
        Rights.PossessProperty);

    ppid = ValidatePPID(claims);
    if (ppid!=null)
    {
        claims = cs.FindClaims(ClaimTypes.DateOfBirth, 
            Rights.PossessProperty);
        foreach (Claim c in claims)
            birthDate = Convert.ToDateTime(c.Resource);
    }
}
if (birthDate == null)
    throw new FaultException("Missing date of birth claim.");
if (birthDate.Value.AddYears(13) > DateTime.Now)
    throw new FaultException(
        "User is too young to access this operation.");
Der Code in Abbildung 17 sucht nach PPID- und Geburtsdatumsansprüchen von jedem ClaimSet. Es wird davon ausgegangen, dass das Token von einer persönlichen Karte ausgestellt wurde. Anschließend wird das Alter des Aufrufers über den Geburtsdatumsanspruch überprüft. Wenn die verschiedenen Sicherheitstoken aus der Nachricht extrahiert und von den Dienstautorisierungsrichtlinien verarbeitet werden, können ein oder mehrere Sätze an Ansprüchen an AuthorizationContext angefügt werden. Wenn der Aussteller bekannt ist und identifiziert werden kann, wäre es möglich, von einem bestimmten Aussteller vor der Verarbeitung von Ansprüchen das richtige ClaimSet auszuwählen.
Verwaltete Karten stellen einen erweiterten Satz an Möglichkeiten zur Verfügung, da die Ansprüche einen identifizierbaren Aussteller haben. Der Aussteller wird auch von einem ClaimSet beschrieben, das häufig einen Identitätsanspruch mit dem öffentlichen Schlüssel des von Ihnen akzeptierten Identitätsproviders enthält. Sie können folgendermaßen nach einem Identitätsanspruch suchen und überprüfen, ob es sich um einen gültigen RSA-Anspruch handelt:
ClaimSet csIssuer = cs.Issuer;
IEnumerable<Claim> issuerClaims = csIssuer.FindClaims(
    ClaimTypes.Rsa, Rights.Identity);
foreach (Claim c in issuerClaims)
{
    System.Security.Cryptography.RSACryptoServiceProvider rsa = 
        c.Resource as RSACryptoServiceProvider;
    if (rsa != null)
    {
        ... // claim exists; check the public key to identify the IP
    }
}
Wenn Sie sich sicher sind, dass Sie das richtige ClaimSet haben, können Sie anspruchsbasierte Sicherheitsüberprüfungen durchführen. Wenn beispielsweise die Ansprüche auf den oben erwähnten CRUD-Ansprüchen basieren, können Sie Überprüfungen auf Create-, Read-, Update- und Delete-Ansprüche für die entsprechenden Vorgänge durchführen. Auf diese Weise erleichtern verwaltete Karten einem Benutzer nicht nur die Auswahl seiner Identität, sondern sie gestalten auch die Generierung eines umfassenden Satzes an Ansprüchen einfacher, mit denen die Benutzerrechte identifiziert werden können. Dienstentwickler können sich auf anspruchsbasierte Autorisierungsprüfungen statt traditioneller rollenbasierter Sicherheitsüberprüfungen konzentrieren. Ein vollständiges Beispiel, das anspruchsbasierte Sicherheit illustriert, kann unter msdn.microsoft.com/msdnmag/code07.aspx heruntergeladen werden.

Schlussbemerkung
Durch die Integration von Windows CardSpace in Ihre ASP.NET-Anwendungen und Windows Communication Foundation-Dienste wird die Verwendung benutzerfreundlicher, indem ein einfacher und konsistenter Identitätsauswahlprozess für die Authentifizierung bei vertrauenswürdigen Anwendungen und Diensten bereitgestellt wird. Persönliche und verwaltete Karten stellen zwar ein gleichwertiges Anmeldeverfahren zur Verfügung, jedoch haben verwaltete Karten den Vorteil, dass ein Identitätsprovider einen bestimmten Satz an Ansprüchen bietet. Diese können von Anwendungen und Diensten verwendet werden, um die Benutzerrechte im System besser zu identifizieren. Die in diesem Artikel erörterten und im Beispielcode für diesen Artikel implementierten Themen sollen Sie dabei unterstützen, Windows CardSpace von ASP.NET oder Windows Communication Foundation auszulösen. Viel Erfolg!

Michèle Leroux Bustamante ist leitende Architektin für IDesign Inc., Microsoft Regional Director und MVP für Connected Systems sowie eine international bekannte Referentin und Autorin. Michèle Leroux Bustamante war am Entwurf und an der Implementierung von Windows CardSpace in den frühen Beta-Phasen beteiligt. Vor kurzem erschien ihr Buch Learning WCF (O'Reilly, 2007; Buchblog: www.thatindigogirl.com). Sie können sie unter www.idesign.net erreichen oder ihren Hauptblog unter www.dasblonde.net besuchen.

Page view tracker