SecurityTokenService Clase

Definición

public ref class SecurityTokenService abstract

public abstract class SecurityTokenService

type SecurityTokenService = class

Public MustInherit Class SecurityTokenService

Herencia

Object

SecurityTokenService

Ejemplos

Los ejemplos de código que se usan en los SecurityTokenService temas se toman del Custom Token ejemplo. Este ejemplo proporciona clases personalizadas que permiten el procesamiento de tokens web simples (SWT) e incluye una implementación de un STS pasivo capaz de atender un token SWT. Para obtener un ejemplo de cómo implementar un STS activo, puede ver el Federation Metadata ejemplo. Para obtener información sobre estos ejemplos y otros ejemplos disponibles para WIF y sobre dónde descargarlos, consulte Índice de ejemplo de código de WIF. En el código siguiente se muestra la implementación de un STS pasivo mediante la SecurityTokenService clase .

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));
            }
        }

    }
}

En el código siguiente se muestra cómo invocar un STS pasivo personalizado para procesar una solicitud de WS-Federation mediante una llamada al FederatedPassiveSecurityTokenServiceOperations.ProcessRequest(HttpRequest, ClaimsPrincipal, SecurityTokenService, HttpResponse) método desde el código subyacente en el default.aspx.cs archivo.

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 );
        }
    }
}

Comentarios

Para crear un STS, debe derivar de la SecurityTokenService clase . En la clase personalizada debe, como mínimo, invalidar los GetScope métodos y GetOutputClaimsIdentity . Con estas invalidaciones, el STS creado con la implementación predeterminada de todos los demás métodos definidos en la clase es capaz de emitir tokens de seguridad en respuesta a las solicitudes de token de seguridad (RST). Es decir, se implementa el enlace issue definido en la especificación WS-Trust. Este enlace se implementa en el Issue método . Ninguno de los demás enlaces de WS-Trust (Renovar, Cancelar y Validar) se implementa en el caso predeterminado y se devuelve un error adecuado al autor de la llamada si se encuentra un RST que corresponde a uno de estos enlaces. Por supuesto, puede invalidar los métodos adecuados (Renew, Cancely Validate) para implementar estos enlaces en el STS.

En la lista siguiente se proporciona una breve descripción de los métodos de importancia principal para el desarrollador para su uso en un entorno de prueba o desarrollo.

• El método GetScope . Este método devuelve un Scope objeto que contiene información sobre el RP. Este objeto se usa en el resto de la canalización de emisión de tokens e incluye información sobre la firma y el cifrado de credenciales que se usarán en la respuesta, así como las AppliesTo direcciones y ReplyTo (si es necesario). Debe invalidar este método.

• El método GetOutputClaimsIdentity . Este método devuelve un ClaimsIdentity objeto que contiene las notificaciones para volver al RP. Debe invalidar este método.

• El método Issue . Este método implementa la canalización de solicitud de token, que procesa una solicitud de token de seguridad entrante (RST) y devuelve una respuesta (RSTR) al autor de la llamada que contiene un token que se puede usar para autenticarse con un RP. Muchos de los otros métodos definidos en la SecurityTokenService clase se llaman desde este método, incluidos los GetScope métodos y GetOutputClaimsIdentity . No es necesario invalidar este método, pero una comprensión de la canalización de solicitud de token que implementa puede resultar útil.

Un STS se configura a través de la SecurityTokenServiceConfiguration clase .

Notas a los implementadores

Debe invalidar los GetScope(ClaimsPrincipal, RequestSecurityToken) métodos y GetOutputClaimsIdentity(ClaimsPrincipal, RequestSecurityToken, Scope) .

Constructores

Propiedades

Métodos

Se aplica a

Consulte también

• Scope
• SecurityTokenServiceConfiguration
• FederatedPassiveSecurityTokenServiceOperations