Ein Security Token Service (STS) ist ein

Transkript

1 Security Token Services mit dem Geneva-Framework implementieren Bitte ein Security-Token Das Geneva-Framework vereinfacht die Implementierung eines Security Token Service. Es unterstützt Protokolle wie WS-Federation und WS-Trust und bietet eine nahtlose Integration in ASP.NET und WCF. dotnetpro gibt hier eine Übersicht über die Architektur des Frameworks. Ein Leitfaden hilft bei sicherheitsrelevanten Entscheidungen. Auf einen Blick Dominick Baier ist unabhängiger Sicherheitsberater bei thinktecture. Er unterstützt Unternehmen beim Entwickeln von sicheren verteilten Anwendungen, Code Reviews und Content Development. Er leitet Trainings bei DevelopMentor und ist Developer Security Microsoft MVP. Seinen Blog finden Sie unter Inhalt Die Architektur der Geneva Security Token Services kennenlernen. Sicherheitsrelevante Entscheidungen überlegt treffen. Security Token Services in ASP.NET und WCF integrieren. Grundlagen Geneva-Grundlagen, QdnpCodeA0905STS Claimbasierte Anwendungen erstellen, QdnpCodeA0907Geneva dnpcode A0911Geneva Ein Security Token Service (STS) ist ein Dienst, welcher Security-Token erzeugt. Clients können Security-Token anfordern, um sich danach bei den sogenannten Relying Parties damit zu authentifizieren. Die ersten beiden Teile dieser Artikelserie haben bereits ausführlich die Gesamtarchitektur eines solchen Systems sowie die Verarbeitung von Token in Relying Parties beleuchtet, [1] und [2]. Dieser Artikel konzentriert sich ausschließlich auf das Erstellen von Token sowie die Integration von Token-Services in ASP.NET und WCF. Das Geneva-Projekt [3] bietet grundsätzlich zwei Alternativen für Security Token Services. Zum einen den Geneva-Server, ein IT-Infrastrukturprodukt, das Token für Active-Directory-Benutzer erzeugen kann. Zum anderen bietet das Geneva-Framework die gesamte Basisinfrastruktur zur Erstellung eigener Token-Services. Ehe man den Schritt macht, einen eigenen Token-Service zu implementieren (dies ist immerhin eine zentrale, sicherheitskritische Komponente), sollte man genau prüfen, ob der Geneva-Server oder das Produkt eines Drittanbieters nicht bereits die gewünschten Features bieten. Aufgabe eines Security Token Service ist das Erstellen von Security-Token. Diese Token können wiederum Claims enthalten. Die Teilaufgaben können in folgende logische Phasen unterteilt werden: Authentifizierung des Clients, Auswerten der Token-Anfrage, Erzeugen der Claims, Erzeugen des Tokens, Erzeugen der Antwort auf die Token-Anfrage. Authentifizierung des Clients: Ein STS benutzt ein beliebiges Authentifizierungsprotokoll, um die Identität des Clients sicherzustellen. Als typische Vertreter wären hier HTTP-basierte Authentifizierung, Kerberos oder WS-Security zu nennen. Das Ergebnis der Authentifizierung ist eine eindeutige Benutzerkennung, die in den nachfolgenden Phasen für die Erzeugung von Claims und für sicherheitsrelevante Entscheidungen verwendet wird. Auswerten der Token-Anfrage: Die weitaus komplexeste Aufgabe eines Identity-Providers ist die Auswertung der Token-Anfrage. Je nach verwendetem Protokoll kann diese Anfrage mehr oder weniger Detailinformationen über das gewünschte Token beinhalten. Zum einen kann der RST (RequestSecurityToken) technische Details enthalten, zum Beispiel Token-Typ (beispielsweise SAML 1.1 oder SAML 2.0), Schlüsseltypen (symmetrisch oder asymmetrisch), Schlüssellängen. Weiterhin kann der RST auch die ID einer Information Card oder eine Liste erforderlicher und optionaler Claims übermitteln. Im Zusammenspiel mit allen anderen Parametern muss der Security Token Service dann entscheiden, ob diese Anfrage zulässig ist. Einer der wichtigsten Phasen bei der Auswertung der Anfrage ist das Ermitteln der Relying Party, für welche das Token bestimmt ist. Dabei muss der STS grundlegende Entscheidungen treffen: Sind beliebige oder lediglich registrierte Relying Parties zugelassen? Werden anonyme Relying Parties unterstützt? Werden Sicherheitsschlüssel im Voraus ausgehandelt? Wird die Verwendung von SSL beziehungsweise Verschlüsselung von Token erzwungen? WS-Trust erlaubt es zum Beispiel, die Relying Party über ein Zertifikat zu authentifizieren, während WS-Federation typischerweise nur eine Zeichenkette als Identifier verwendet. Hier muss je nach dem vorliegenden Sicherheitsbedürfnis eine entsprechende Richtlinie etabliert werden. Erzeugen der Claims: In dieser (optionalen) Phase werden Claims, welche den Benutzer beschreiben, erzeugt, um später in das Token eingebettet zu werden. Bei der Erzeugung von Claims kommen typische Muster zum Einsatz: fester Satz von Claims, unabhängig von Benutzer und Relying Party, Erzeugung von Claims in Abhängigkeit von der Relying-Party-Identität, Erzeugung von Claims, basierend auf der Liste der gewünschten Claims im RST

2 Erzeugen des Tokens: In dieser Phase werden die Claims sowie etwaige Schlüssel in ein Token verpackt. Verschiedene Faktoren spielen hier eine Rolle: Der angefragte Token-Typ muss von dem Identity-Provider und dem verwendeten Protokoll unterstützt werden. Im Fall von SAML-Token wird der Relying Party Identifier als Audience-URI eingebettet. Damit kann die Relying Party überprüfen, ob das Token auch wirklich für sie bestimmt ist. Token werden typischerweise verschlüsselt. Dadurch wird erreicht, dass das Token, unabhängig vom benutzten Transportmedium, vor Einsicht geschützt ist. Zudem können nur Empfänger mit dem entsprechenden Schlüsselmaterial das Token wieder entschlüsseln. Zuletzt wird das Token vom STS digital signiert. Das gewährleistet die Integrität und erlaubt der Relying Party, den Herausgeber des Tokens zu authentifizieren. Erzeugen der Token-Antwort (RSTR): Das Token wird in dieser Phase in eine Token- Antwortnachricht verpackt und an den Client zurückgesandt. Abhängig vom verwendeten Protokoll geschieht das über eine SOAP-Nachricht oder über einen reinen HTTP-POST-Aufruf. Architektur Security-Token können über diverse Protokolle angefragt (etwa WS-Federation oder WS-Trust) und in verschiedenen Formaten ausgeliefert werden (zum Beispiel SAML 1.1/2.0). Das Geneva-Framework hat den Anspruch, eine Basisarchitektur für Security Token Services bereitzustellen, die von diesen technischen Details abgekoppelt ist. Die Geneva-STS-Infrastruktur besteht aus einer Handvoll erweiterbarer Klassen, die von der Bearbeitung einer Token-Anfrage und der damit verbundenen Erzeugung eines Tokens abstrahieren. Diese Infrastruktur ist hostunabhängig und wird über öffentliche Erweiterungspunkte in einen konkreten Host eingebunden werden.von Haus aus liefert Geneva eine vorgefertigte Integration für ASP.NET und WCF. Abbildung 1 gibt eine Übersicht über die involvierten Klassen und ihre Beziehung untereinander. Im Nachfolgenden wird die Aufgabe der Klassen genauer untersucht. Generell ist zu sagen, dass das gesamte Geneva-Framework auf Erweiterbarkeit hin entworfen wurde. Alle angesprochenen Komponenten sind öffentliche Klassen mit Erweiterungspunkten. Dies macht das Framework [Abb. 1] Die Architektur der Geneva Security Token Services. sehr flexibel. Die Klasse SecurityTokenServiceConfiguration beschreibt alle konfigurierbaren Aspekte des STS, zum Beispiel: Herausgeber-URI, Standard-Signaturzertifikat, Standard- und unterstützte Token-Typen, Standard- und Maximallebensdauer von Token, Standard- und Maximal-Schlüssellängen, die STS-Implementierung. Über die Konfigurationsklasse kann der STS über die statische Methode CreateSecurityTokenService() erzeugt und konfiguriert werden. Die Konfiguration kann sowohl pur in Code als auch auf Basis einer XML-Konfigurationsdatei erzeugt werden. Die Klasse RequestSecurityToken abstrahiert eine Token-Anfrage. Diese Klasse ist bewusst protokollunabhängig gehalten, erlaubt aber direkten Zugriff auf die üblichen WS-Trust-/WS-Federation- sowie Identity- Metasystem-Spezifika, zum Beispiel: AppliesTo/Realm Adresse, RepliesTo-Adresse, Context, AuthenticationType, Token-Typ, Lebensdauer, Verschlüsselungs- und Signaturalgorithmen, Schlüsselarten und -größen, Claims-Anforderungen, Information Card ID, Clientpseudonym, Display-Token. Über Erweiterungspunkte lassen sich auch zukünftige Protokollanforderungen realisieren. Der Benutzer, der die Token-Anfrage initiiert hat, wird über ein Standard-IClaims- Principal modelliert. Diese Identität wird vom STS verwendet, um sicherheitsrelevante Entscheidungen zu treffen und um Claims zu erzeugen. Die Antwort auf eine Token-Anfrage ist in der Klasse RequestSecurityToken94Response abgebildet. Auch hier ist der direkte Zugriff auf die WS-Trust- und WS-Federation-Eigenschaften erlaubt, zum Beispiel: Security-Token, Proof-Token, Display-Token, Token-Referenzen. Die Klasse SecurityTokenService hat die Aufgabe, die Token-Anfrage in eine Token- Antwort umzuwandeln. Dazu existiert eine erweiterbare Verarbeitungspipeline, die es erlaubt, die involvierten Teilschritte für die eigenen Bedürfnisse anzupassen. Diese Klasse wird genauer im Abschnitt über die Token-Erzeugung untersucht. Ein SecurityTokenDescriptor ist eine technologieunabhängige Beschreibung eines Security-Tokens. Der Descriptor wird vom STS erzeugt und an einen SecurityToken- Handler weitergegeben, welcher dann letztendlich einen konkreten Security-Token erzeugt. Security Token Services verwenden SecurityTokenHandler, um Security-Token zu erzeugen. Diese werden vom STS in die Token-Antwort eingebettet. SecurityToken ist die Abbildung eines Security-Tokens im.net Framework. Geneva sowie.net selbst stellen diverse Bibliotheken zur Verfügung, um die Token in diverse Kabelrepräsentierungen zu serialisieren beziehungsweise zu deserialisieren

3 _Security Token Services mit dem Geneva-Framework implementieren [Abb. 2] STS-Integration in ASP.NET. [Abb. 3] STS-Integration in WCF. Der Host Integration Layer besteht aus Modulen und Erweiterungen für ASP.NET und WCF. Hier werden die hostingspezifischen Anfragen in das RST/RSTR-Format umgewandelt. Der Host bedient Clientanfragen und kann eine beliebige.net-anwendung sein. Token-Erzeugung Die benutzerdefinierte Logik in einem STS ist hauptsächlich in der Klasse SecurityTokenService enthalten. Diese Klasse verfügt über vier Einstiegspunkte, die die typischen Token-Anfrage-Operationen abbilden: Issue, Ausstellen eines Tokens, Renew, Verlängern eines bestehenden Tokens, Validate, Überprüfen eines Tokens, Cancel, Invalidieren eines Tokens. Für den häufigsten Fall (Issue) bietet SecurityTokenService eine vorgefertigte Pipeline, die an diversen Stellen durch eigene Logik angepasst werden kann, siehe [4] für eine ausführliche Beschreibung der Pipeline. Zwei Methoden dieser Basisklasse sind abstrakt und müssen implementiert werden. Die Aufgabe der Methode GetScope() ist es, den Request zu analysieren und, darauf basierend, ergänzende Werte wie Adressen und Schlüsselmaterial zu ermitteln. Hierfür verwendet man das RequestSecurity-Token, das in diese Methode reingereicht wird. Typische Aufgaben, die hier erledigt werden müssen, sind: Analysieren der Relying-Party-Identität. DiesenWert finden Sie auf der AppliesTo- Eigenschaft. Sie beinhaltet die Adresse sowie eventuell einen zu verwendenden Schlüssel. Es hängt von den Richtlinien für den STS ab, welche Kombination von Werten hier zulässig ist. Ermitteln von Schlüsselmaterial. Falls das resultierendetoken verschlüsselt werden soll, muss der entsprechende Schlüssel ermittelt werden. Dies geschieht entweder auf Basis einer Konfigurationseinstellung oder mithilfe des vom Client beigelegten Schlüssels. Welche Methode hier zulässig ist, entscheiden die Richtlinien für diesen STS. Protokollspezifische Arbeit. Darunter könnte das Prüfen einer übermittelten Information-Card-ID fallen oder das Setzen derws-federation-replyto-adresse. In der Methode GetOutputClaimsIdentity() wird eine IClaimsIdentity erzeugt, die die Identitätsinformationen im resultierenden Token repräsentiert. Hier muss die Entscheidung getroffen werden, wie die Benutzeridentität modelliert wird und welche Claims erzeugt werden. Dies hängt typischerweise von der Benutzer- und Relying-Party-Identität ab sowie von eventuell vorhandenen Claims-Anforderungen in der Anfrage. Die Aufgabe des Hosts ist es, physikalische Token-Anfragen entgegenzunehmen und diese in das technologieunabhängige RST/RSTR-Format zu konvertieren. Das kann zwar prinzipiell von beliebigen Hosts durchgeführt werden, das Geneva-Framework bietet aber von Haus aus eine direkte Unterstützung für ASP.NET und WCF. Die Details der Integration für die beiden Umgebungen sind sehr unterschiedlich und werden im folgenden Abschnitt genauer untersucht. ASP.NET ASP.NET-basierende Security Token Services bieten sich für passive Token-Anfragen, etwa WS-Federation, an. Hierbei wird der Token-Service in einem normalen ASP.NET- Handler, beispielsweise in einer normalen Webform, gehostet. Als Authentifizierungsmechanismus kommen ASP.NET-Bordmittel zum Einsatz (Windows Integrated, Clientzertifikate, Forms-basiert). Eine Standard- Token-Service-Host-Implementierung findet man im FederatedPassiveTokenService-Webcontrol, das auf einer Seite eingebettet werden kann, siehe Abbildung 2. Das Control benötigt den Namen der Klasse, in der die SecurityTokenServiceConfiguration zu finden ist, um den Token-Service zu aktivieren. Das Standardverhalten des Controls ist wie folgt: Auswerten der WS-Federation-Query- String-Parameter in eine SignInRequest- Message-Klasse. Erzeugen eines IClaimsPrincipals auf Basis des aktuellen von ASP.NET erzeugten IPrincipals. Hierzu wird die statische Methode ClaimsPrincipal.CreateFromPrincipal() verwendet. Diese Methode unterstützt die Konvertierung aller ASP.NET- Standard-Principals. Erzeugen von Serializern, um zwischen denws-federation-spezifischen Klassen SignInRequestMessage / SignInResponse- Message und RequestSecurityToken / RequestSecurityTokenResponsezuübersetzen. Erzeugen des Security Token Service anhand der SecurityToken Service Configuration. Aufrufen der Issue-Methode. Konvertieren des RSTR in eine SignInResponseMessage

4 Rendern der SignInResponseMessage in ein WS-Federation-POST-Formular, um die Token-Antwort zur Relying Party zu übertragen. Auch hier gilt wiederum: Alle diese Vorgänge basieren auf öffentlichen APIs und können nach Belieben angepasst werden. WCF Die Integration des Security Token Service in einen WCF-Dienst wird durch einen speziellen WCF-Service durchgeführt, WSTrustServiceContract. Dieser Service implementiert die WS-Trust-1.3- und -Feb2005-Schnittstellen und serialisiert WS-Trust-Anfragen und -Antworten in RequestSecurityToken / RequestSecurityTokenResponse. Dieser Klasse wird bei der Erzeugung eine Instanz der SecurityToken- ServiceConfiguration übergeben, damit die Token-Anfrage durch die STS-Pipeline geleitet werden kann. Das Hosten dieser Klasse wird von einem speziellen WCF-Service-Host durchgeführt dem WSTrustServiceHost. Dieser Host verlangt eine SecurityTokenServiceConfiguration zur Initialisierung und führt sämtliche Konfigurationsschritte durch, um die STS- Implementierung über SOAP/WS-Trust erreichbar zu machen. Im Vergleich zu einem Standard-WCF-Service-Host werden die folgenden zusätzlichen Schritte durchgeführt: Aktivierung der Metadata-Exchange- Endpunkte für alle verfügbaren Basisadressen. Aktivierung der Geneva-Token-Verarbeitungspipeline via FederatedService- Credentials.ConfigureHost(). Weiterhin existiert eine Service Host Factory (WSTrustServiceHostFactory), die für IIS gehostete Umgebungen den WS- TrustServiceHost erzeugt und initialisiert, siehe Abbildung 3. Ein Beispiel Das Geneva-Framework-SDK enthält diverse einfache Beispiele für Security Token Services. Diese sind zu empfehlen, um den Einstieg in die Klassenbibliothek und die Hostingtechniken zu finden. Die typischen Aufgaben eines richtigen Token-Service werden mit diesen Samples allerdings nicht herausgearbeitet. Der letzte Teil dieses Artikels verwendet den thinktecture Starter STS [5], um die Gesamtarchitektur und Coding-Strategien eines Geneva-basierenden Security Token Service zu verdeutlichen. Listing 1 Sicherheitsrichtlinien spezifizieren. <startersts sitename="thinktecture Security Token Service Starter Sample" issueruri=" issuercontact ="identity@thinktecture.com" claimsbaseuri=" requireencryption="false" requiressl="true" allowknownrealmsonly="false" enablemessagewstrust="false" enablemixedwstrust="true" /> Listing 2 Relevantes Schlüsselmaterial definieren. <certificatereferences> <!-- STS signing certificate --> <add name="signingcertificate" findvalue="58 C2" x509findtype="findbythumbprint" storelocation="localmachine" storename="my" /> <!-- encryption certificates for relying parties --> <!-- starter RP encryption certificate --> <add name=" findvalue="23 B4" x509findtype="findbythumbprint" storelocation="localmachine" storename="my" /> </certificatereferences> Listing 3 Den Service konfigurieren. public class StarterTokenServiceConfiguration : SecurityTokenServiceConfiguration { public StarterTokenServiceConfiguration() : base(sts.configuration.issueruri, STS.SigningCredentials) { SecurityTokenService = typeof(startertokenservice); Listing 4 Den Token-Service in einer ASP.NET-Seite hosten. <%@ Page Title="Issue Token..." Language="C#" %> <form id="form1" runat="server"> <idfx:federatedpassivetokenservice ID="_starterTokenService" runat="server" ServiceConfiguration="StarterTokenServiceConfiguration, App_Code" /> </form> Der Starter STS ist ein einfacher Token- Service für aktive und passive Clients mit Unterstützung fürws-federation,ws-trust, SAML 1.1/2.0 sowie Information Cards. Weiterhin benutzt der STS das ASP.NET- Providermodell (Membership, Roles, Profile) für die Authentifizierung und Claims- Erzeugung. Im Nachfolgenden werden

5 _Security Token Services mit dem Geneva-Framework implementieren Listing 5 WS-Trust-Endpunkte öffnen. public class StarterTokenServiceHostFactory : WSTrustServiceHostFactory { public override ServiceHostBase CreateServiceHost( string constructorstring, Uri[] baseaddresses) { var config = CreateSecurityTokenServiceConfiguration(constructorString); var host = new WSTrustServiceHost(config, baseaddresses); Listing 6 // add and configure a message security endpoint if (STS.Configuration.EnableMessageWSTrust) { host.addserviceendpoint( typeof(iwstrust13synccontract), CreateBinding(SecurityMode.Message), "message"); var credential = new ServiceCredentials(); credential.servicecertificate.certificate = STS.SigningCertificate; host.description.behaviors.add(credential); // add and configure a mixed mode security endpoint if (STS.Configuration.EnableMixedWSTrust) {... return host; Zulässigkeit der Token-Anfrage überprüfen. protected override Scope GetScope( IClaimsPrincipal principal, RequestSecurityToken request) { // analyze RST var options = ScopeOptions.Create(request); // check if realm is allowed if (STS.Configuration.AllowKnownRealmsOnly && (!options.isknownrealm)) { throw new InvalidRequestException("Unknown realm"); // check if token must be encrypted if (STS.Configuration.RequireEncryption && (!options.usesencryption)) { throw new InvalidRequestException("No encryption key available"); // check if SSL is used (for passive only) if (STS.Configuration.RequireSSL &&!options.usesssl) { if (!options.isactive) { throw new InvalidRequestException("SSL is required"); // create scope var scope = new Scope( request.appliesto.uri.absoluteuri, SecurityTokenServiceConfiguration.SigningCredentials); scope.replytoaddress = options.replytoaddress.absoluteuri; if (options.usesencryption) { scope.encryptingcredentials = new X509EncryptingCredentials(options.EncryptingCertificate); return scope; Konfiguration Der Konfigurationsabschnitt für den Starter STS formuliert die Sicherheitsrichtlinie sowie die freigeschalteten Features, siehe Listing 1. Hier wird spezifiziert, ob Relying Parties über SSL mit dem STS kommunizieren müssen (requiressl), ob Token verschlüsselt werden müssen (requireencryption) und ob Relying Parties zuerst explizit registriert werden müssen (allowknownrealmsonly). Weiterhin können hier die aktiven WS-Trust-Endpunkte für Message und Mixed Mode Security aktiviert werden (enablemessagewstrust und enablemixed- WSTrust). Diese Konfiguration wird an diversen Stellen im STS referenziert. Weiterhin existiert einverzeichnis von relevantem Schlüsselmaterial, das für den Betrieb des STS benötigt wird, siehe Listing 2. Hier werden sowohl das Signaturzertifikat als auch Realm-zu-Public-Key-Mappings für das Verschlüsseln von Token eingetragen. Weiterhin muss eine Klasse existieren, die von SecurityTokenServiceConfiguration ableitet. Diese wird verwendet, um die Token-Erzeugungslogik aus ASP.NET und WCF aufzurufen. Im Minimum werden hier der Issuer-URI, das Signaturzertifikat sowie der Security-Token-Service-Typ spezifiziert, siehe Listing 3. Authentifizierung und Hosting Der Token-Service wird sowohl über ASP.NET (passive) als auch WCF (active) gehostet. Im passiven Fall kommt hier eine ganz normale ASP.NET-Seite mit dem FederatedPassiveTokenService-Control zum Einsatz, siehe Listing 4. Dieses Control liest die angegebene STS-Konfiguration aus, um den Token-Service zu instanzieren. Geschützt wird diese Seite mit ganz normalen ASP.NET-Bordmitteln in diesem konkreten Fall mit Forms Authentication, basierend auf dem konfigurierten Membership- Provider. Für das WCF-basierte Hosting ist es am geschicktesten, eine sogenannte Service Host Factory zu verwenden. Die Factory wird durch den Aufruf einer WCF-svc- Datei gestartet und kann die STS-Konfiguration auslesen. <%@ ServiceHost Factory="StarterTokenServiceHostFactory, App_Code" Service="StarterTokenService- Configuration, App_Code" %> einige der STS-Konzepte anhand Implementierungsdetails des Starter STS erläutert. Deswegen wird empfohlen, sich den STS bei Codeplex herunterzuladen und die Screencasts [6] und [7] über das Setup und die Features anzuschauen. Danach werden die entsprechenden WS-Trust-Endpunkte geöffnet, was durch die von Geneva bereitgestellte Klasse

6 WSTrustServiceHost erheblich vereinfacht wird, siehe Listing 5. WCF verwendet die Geneva-Security-Token-Handler-Infrastruktur für die Authentifizierung. Einer der eingebauten Handler basiert wiederum auf einem Membership- Provider, was es komfortabel erlaubt, die gleiche Anmeldelogik für ASP.NET und WCF zu verwenden (und damit auch die gleiche Benutzerdatenbank). Token-Erzeugung Die Claims- und Token-Erzeugung findet in der von SecurityTokenService abgeleiteten Klasse statt. Wie bereits erläutert, unterteilt sich dieser Vorgang in zwei Phasen: Auswerten der Token-Anfrage und Erzeugung der Claims. Das Parsen der Anfrage ist nicht ganz trivial, und es bietet sich an, diesen Vorgang zu abstrahieren. Der Starter STS verwendet eine Klasse mit Namen ScopeOptions, die die gewünschten Werte direkt als Properties zur Verfügung stellt. Weiterhin wertet die statische Methode Create die Token-Anfrage aus und setzt die oben genannten Properties (siehe im Starter STS Source Code für Details). Danach kann ScopeOptions in der Get- Scope()-Methode verwendet werden, um zu entscheiden, ob die Token-Anfrage zulässig ist, siehe Listing 6. In der Methode GetOutputClaimsIdentity werden die Claims für den Benutzer zusammengesucht und als IClaimsIdentity an Geneva zurückgeliefert. Der Starter STS verwendet den Membership-, Roles- und Profile-Provider, um die nötigen Informationen zu ermitteln, siehe Listing 7. Das von dieser Methode zurückgelieferte Claims- Principal wird danach von der Geneva-Infrastruktur in den gewünschten Token-Typ (typischerweise SAML) serialisiert. Das Geneva-Framework verfügt über ein Tool namens FedUtil.exe. Damit können Relying Parties auf einfache Art und Weise an Token-Services angedockt werden (mehr dazu im Geneva-Framework-SDK). Dazu muss der STS ein WS-Federation- Metadatendokument publizieren. Das Geneva-Framework verfügt über alle Klassen, um dieses Metadatendokument zu erstellen, und der Starter STS publiziert ein solches Dokument dynamisch in dem von der Spezifikation beschriebenen Standardverzeichnis ( FederationMetadata/ /Federation- MetaData.xml). Dies bewerkstelligt ein Standard-ASP.NET-HTTP-Handler, siehe Listing 8. Listing 7 Claims für den Benutzer zusammensuchen. protected override IClaimsIdentity GetOutputClaimsIdentity( IClaimsPrincipal principal, RequestSecurityToken request, Scope scope) { // user name and authentication information var claims = new List<Claim> { new Claim( WSIdentityConstants.ClaimTypes.Name, principal.identity.name), new Claim( ClaimTypes.AuthenticationMethod, AuthenticationType.PasswordUri), AuthenticationInstantClaim.Now ; // address string = Membership.FindUsersByName(principal.Identity.Name) [principal.identity.name]. ; if (!String.IsNullOrEmpty( )) { claims.add(new Claim(WSIdentityConstants.ClaimTypes. , )); // roles if (Roles.Enabled) { foreach (var role in Roles.GetRolesForUser(principal.Identity.Name)) { claims.add(new Claim(ClaimTypes.Role, role)); // profile data claims.addrange(getprofiledata(principal)); return new ClaimsIdentity(claims); Fazit Das Geneva-Framework verfügt über alle APIs und Einrichtungen, die für die technische Implementierung von Security Token Services benötigt werden. Wie aber in diesem Artikel gezeigt, entstehen die Schwierigkeiten beim Einsatz eines STS nicht bei der technischen Umsetzung, sondern beim Formulieren der Sicherheitsrichtlinien. Dies muss in jedem Fall vom Entwickler entsprechend implementiert werden. Weiter ist zu bedenken, dass ein STS ein wichtiger Sicherheits-Infrastrukturbaustein ist, der sowohl robust als auch verwaltbar sein sollte. Alle diese Features und noch mehr existieren bereits im Geneva-Server jedoch mit der Einschränkung, dass nur Active-Directory-Benutzer unterstützt werden. Wenn das Listing 8 Relying Parties an Token-Services andocken. kein Problem darstellt, sollte dieses Serverprodukt auf jeden Fall vor dem Schreiben eines eigenen STS evaluiert werden. [ml] [1] Milan Spalek: Wer ist das? Was darf der? dotnetpro 5/2009, Seite 84ff. QdnpCodeA0905STS [2] Dominick Baier: Claims abstecken. dotnetpro 7/2009, Seite 76ff. QdnpCodeA0907Geneva [3] [4] Dominick Baier, (SAML) Token Creation in a Geneva STS, QdnpCodeSL0910Geneva1 [5] thinktecture STS Starter Kit, [6] StarterSTS Setup and Overview, QdnpCodeSL0910Geneva2 [7] StarterSTS Advanced, QdnpCodeSL0910Geneva3 <location path="federationmetadata/ "> <system.webserver><handlers> <add name="metadatagenerator" path="federationmetadata.xml" verb="get" type="metadatagenerator, App_Code" /> </handlers></system.webserver> </location>