SecurityTokenService Klasse

Definition

public ref class SecurityTokenService abstract

public abstract class SecurityTokenService

type SecurityTokenService = class

Public MustInherit Class SecurityTokenService

Vererbung

Object

SecurityTokenService

Beispiele

Die Codebeispiele, die in den SecurityTokenService Themen verwendet werden, stammen aus dem Custom Token Beispiel. Dieses Beispiel enthält benutzerdefinierte Klassen, die die Verarbeitung einfacher Webtoken (SIMPLE Web Tokens, SWT) ermöglichen und eine Implementierung eines passiven STS enthalten, der ein SWT-Token verarbeiten kann. Ein Beispiel für die Implementierung eines aktiven STS finden Sie im Federation Metadata Beispiel. Informationen zu diesen Beispielen und anderen Beispielen, die für WIF verfügbar sind und wo sie heruntergeladen werden sollen, finden Sie unter WIF Code Sample Index. Der folgende Code zeigt die Implementierung eines passiven STS mithilfe der SecurityTokenService Klasse.

using System;
using System.IdentityModel;
using System.IdentityModel.Configuration;
using System.IdentityModel.Protocols.WSTrust;
using System.IdentityModel.Tokens;
using System.Security.Claims;
using System.Security.Cryptography.X509Certificates;

namespace PassiveSTS
{
    /// <summary>
    /// Overrides the SecurityTokenService class to provide
    /// the relying party related information, such as encryption credentials to encrypt the issued
    /// token, signing credentials to sign the issued token, claims that the STS wants to issue for a 
    /// certain token request, as well as the claim types that this STS is capable
    /// of issuing.
    /// </summary>
    public class CustomSecurityTokenService : SecurityTokenService
    {
        // Certificate Constants
        private const string SIGNING_CERTIFICATE_NAME = "CN=localhost";
        private const string ENCRYPTING_CERTIFICATE_NAME = "CN=localhost";

        private SigningCredentials _signingCreds;
        private EncryptingCredentials _encryptingCreds;
        // Used for validating applies to address, set to URI used in RP app of application, could also have been done via config
        private string _addressExpected = "http://localhost:19851/";
        public CustomSecurityTokenService(SecurityTokenServiceConfiguration configuration)
            : base(configuration)
        {
            // Setup the certificate our STS is going to use to sign the issued tokens
            _signingCreds = new X509SigningCredentials(CertificateUtil.GetCertificate(StoreName.My, StoreLocation.LocalMachine, SIGNING_CERTIFICATE_NAME));

            // Note: In this sample app only a si   ngle RP identity is shown, which is localhost, and the certificate of that RP is 
            // populated as _encryptingCreds
            // If you have multiple RPs for the STS you would select the certificate that is specific to 
            // the RP that requests the token and then use that for _encryptingCreds
            _encryptingCreds = new X509EncryptingCredentials(CertificateUtil.GetCertificate(StoreName.My, StoreLocation.LocalMachine, ENCRYPTING_CERTIFICATE_NAME));
        }

        /// <summary>
        /// This method returns the configuration for the token issuance request. The configuration
        /// is represented by the Scope class. In our case, we are only capable of issuing a token to a
        /// single RP identity represented by the _encryptingCreds field.
        /// </summary>
        /// <param name="principal">The caller's principal</param>
        /// <param name="request">The incoming RST</param>
        /// <returns></returns>
        protected override Scope GetScope(ClaimsPrincipal principal, RequestSecurityToken request)
        {
            // Validate the AppliesTo address
            ValidateAppliesTo( request.AppliesTo );

            // Create the scope using the request AppliesTo address and the RP identity
            Scope scope = new Scope( request.AppliesTo.Uri.AbsoluteUri, _signingCreds );

            if (Uri.IsWellFormedUriString(request.ReplyTo, UriKind.Absolute))
            {
                if (request.AppliesTo.Uri.Host != new Uri(request.ReplyTo).Host)
                    scope.ReplyToAddress = request.AppliesTo.Uri.AbsoluteUri;
                else
                    scope.ReplyToAddress = request.ReplyTo;
            }
            else
            {
                Uri resultUri = null;
                if (Uri.TryCreate(request.AppliesTo.Uri, request.ReplyTo, out resultUri))
                    scope.ReplyToAddress = resultUri.AbsoluteUri;
                else
                    scope.ReplyToAddress = request.AppliesTo.Uri.ToString() ;
            }

            // Note: In this sample app only a single RP identity is shown, which is localhost, and the certificate of that RP is 
            // populated as _encryptingCreds
            // If you have multiple RPs for the STS you would select the certificate that is specific to 
            // the RP that requests the token and then use that for _encryptingCreds
            scope.EncryptingCredentials = _encryptingCreds;

            return scope;
        }
        /// <summary>
        /// This method returns the content of the issued token. The content is represented as a set of
        /// IClaimIdentity intances, each instance corresponds to a single issued token. Currently, the Windows Identity Foundation only
        /// supports a single token issuance, so the returned collection must always contain only a single instance.
        /// </summary>
        /// <param name="scope">The scope that was previously returned by GetScope method</param>
        /// <param name="principal">The caller's principal</param>
        /// <param name="request">The incoming RST, we don't use this in our implementation</param>
        /// <returns></returns>
        protected override ClaimsIdentity GetOutputClaimsIdentity( ClaimsPrincipal principal, RequestSecurityToken request, Scope scope )
        {
            //
            // Return a default claim set which contains a custom decision claim
            // Here you can actually examine the user by looking at the IClaimsPrincipal and 
            // return the right decision based on that. 
            //
            ClaimsIdentity outgoingIdentity = new ClaimsIdentity();
            outgoingIdentity.AddClaims(principal.Claims);

            return outgoingIdentity;
        }
        /// <summary>
        /// Validates the appliesTo and throws an exception if the appliesTo is null or appliesTo contains some unexpected address.
        /// </summary>
        /// <param name="appliesTo">The AppliesTo parameter in the request that came in (RST)</param>
        /// <returns></returns>
        void ValidateAppliesTo(EndpointReference appliesTo)
        {
            if (appliesTo == null)
            {
                throw new InvalidRequestException("The appliesTo is null.");
            }

            if (!appliesTo.Uri.Equals(new Uri(_addressExpected)))
            {
                throw new InvalidRequestException(String.Format("The relying party address is not valid. Expected value is {0}, the actual value is {1}.", _addressExpected, appliesTo.Uri.AbsoluteUri));
            }
        }

    }
}

Der folgende Code zeigt, wie Ein benutzerdefinierter passiver STS aufgerufen wird, um eine WS-Federation Anforderung zu verarbeiten, indem die FederatedPassiveSecurityTokenServiceOperations.ProcessRequest(HttpRequest, ClaimsPrincipal, SecurityTokenService, HttpResponse) Methode aus dem CodeBehind in der default.aspx.cs Datei aufgerufen wird.

using System;
using System.IdentityModel.Services;
using System.Security.Claims;

namespace PassiveSTS
{
    public partial class _Default : System.Web.UI.Page
    {
        /// <summary>
        /// We perform the WS-Federation Passive Protocol processing in this method. 
        /// </summary>
        protected void Page_PreRender( object sender, EventArgs e ) 
        {
            FederatedPassiveSecurityTokenServiceOperations.ProcessRequest( Request, User as ClaimsPrincipal, CustomSecurityTokenServiceConfiguration.Current.CreateSecurityTokenService(), Response );
        }
    }
}

Hinweise

Zum Erstellen eines STS müssen Sie von der SecurityTokenService Klasse abgeleitet werden. In Ihrer benutzerdefinierten Klasse müssen Sie mindestens die GetScope Methoden GetOutputClaimsIdentity außer Kraft setzen. Mit diesen Außerkraftsetzungen kann der STS, der mithilfe der Standardimplementierung aller anderen in der Klasse definierten Methoden erstellt wurde, Sicherheitstoken als Reaktion auf Sicherheitstokenanforderungen (RST) ausstellen. Das heißt, die in der WS-Trust Spezifikation definierte Problembindung wird implementiert. Diese Bindung wird in der Issue Methode implementiert. Keine der anderen WS-Trust Bindungen (Verlängern, Abbrechen und Überprüfen) werden im Standardfall implementiert, und ein entsprechender Fehler wird an den Aufrufer zurückgegeben, wenn ein RST, der einer dieser Bindungen entspricht, gefunden wird. Sie können natürlich die entsprechenden Methoden (Renew, und Cancel) überschreiben, Validateum diese Bindungen in Ihrem STS zu implementieren.

Die folgende Liste enthält eine kurze Übersicht über die Methoden, die für den Entwickler für die Verwendung in einer Test- oder Entwicklungsumgebung von primärer Bedeutung sind.

• Die GetScope-Methode. Diese Methode gibt ein Scope Objekt zurück, das Informationen zum RP enthält. Dieses Objekt wird im Rest der Tokenausstellungspipeline verwendet und enthält Informationen über das Signieren und Verschlüsseln von Anmeldeinformationen, die in der Antwort verwendet werden sollen, sowie die AppliesTo Adressen und ReplyTo (falls erforderlich). Sie müssen diese Methode außer Kraft setzen.

• Die GetOutputClaimsIdentity-Methode. Diese Methode gibt ein ClaimsIdentity Objekt zurück, das die Ansprüche enthält, die an das RP zurückgegeben werden sollen. Sie müssen diese Methode außer Kraft setzen.

• Die Issue-Methode. Diese Methode implementiert die Tokenanforderungspipeline, die eine eingehende Sicherheitstokenanforderung (RST) verarbeitet und eine Antwort (RSTR) an den Aufrufer zurückgibt, der ein Token enthält, das zur Authentifizierung mit einem RP verwendet werden kann. Viele der anderen in der SecurityTokenService Klasse definierten Methoden werden von dieser Methode aufgerufen, einschließlich der Methoden und GetScope Der GetOutputClaimsIdentity Methoden. Sie müssen diese Methode nicht außer Kraft setzen, aber ein Verständnis der implementierten Tokenanforderungspipeline kann hilfreich sein.

Ein STS wird über die SecurityTokenServiceConfiguration Klasse konfiguriert.

Hinweise für Ausführende

Sie müssen sowohl die GetScope(ClaimsPrincipal, RequestSecurityToken) Methoden als auch die GetOutputClaimsIdentity(ClaimsPrincipal, RequestSecurityToken, Scope) Methoden außer Kraft setzen.

Weitere Informationen

• Scope
• SecurityTokenServiceConfiguration
• FederatedPassiveSecurityTokenServiceOperations