Escenario de delegación de identidades con AD FS
[A partir de .NET Framework 4.5, Windows Identity Foundation (WIF) se ha integrado por completo en .NET Framework. La versión de WIF de la que trata este tema, WIF 3.5, está obsoleta y solo debe utilizarse cuando se desarrolle con .NET Framework 3.5 SP1 o .NET Framework 4. Para obtener más información sobre WIF en .NET Framework 4.5, también conocido como WIF 4.5, consulte la documentación de Windows Identity Foundation en la guía de desarrollo de .NET Framework 4.5.
En este escenario se describe una aplicación que necesita acceder a los recursos de back-end que requieren la cadena de delegación de identidades para realizar comprobaciones de control de acceso. Normalmente, una cadena de delegación de identidad simple consta de la información sobre el llamador inicial y la identidad del llamador inmediato.
Con el modelo de delegación de Kerberos en la plataforma Windows hoy en día, los recursos de back-end solo tienen acceso a la identidad del llamador inmediato y no a la del llamador inicial. Este modelo se conoce normalmente como modelo de subsistema de confianza. WIF mantiene la identidad del llamador inicial así como del llamador inmediato en la cadena de delegación mediante la propiedad Actor.
En el diagrama siguiente se muestra un escenario típico de delegación de identidad en el que un empleado de Fabrikam accede a los recursos expuestos en una aplicación de Contoso.com.
Los usuarios ficticios que participan en este escenario son:
- Frank: empleado de Fabrikam que quiere acceder a los recursos de Contoso.
- Daniel: desarrollador de aplicaciones de Contoso que implementa los cambios necesarios en la aplicación.
- Adam: administrador de TI de Contoso.
Los componentes implicados en este escenario son:
- web1: aplicación web con vínculos a recursos de back-end que requieren la identidad delegada del llamador inicial. Esta aplicación se compila con ASP.NET.
- Un servicio web que accede a un servidor SQL Server, que requiere la identidad delegada del llamador inicial junto con la del llamador inmediato. Este servicio se crea con WCF.
- sts1: STS que está en el rol del proveedor de notificaciones y emite notificaciones esperadas por la aplicación (web1). Ha establecido confianza con Fabrikam.com y también con la aplicación.
- sts2: STS que está en el rol del proveedor de identidades para Fabrikam.com y proporciona un punto final que el empleado de Fabrikam usa para autenticarse. Ha establecido confianza con Contoso.com para que los empleados de Fabrikam puedan acceder a los recursos en Contoso.com.
Nota
El término "Token actAs", que se usa a menudo en este escenario, hace referencia a un token emitido por STS y contiene la identidad del usuario. La propiedad Actor contiene la identidad del STS.
Como se muestra en el diagrama anterior, el flujo en este escenario es:
- La aplicación Contoso está configurada para obtener un token actAs que contiene la identidad del empleado de Fabrikam y la identidad del llamador inmediato en la propiedad Actor. Daniel ha implementado estos cambios en la aplicación.
- La aplicación Contoso está configurada para pasar el token ActAs al servicio de back-end. Daniel ha implementado estos cambios en la aplicación.
- El servicio web Contoso está configurado para validar el token actAs mediante una llamada a sts1. Adam ha habilitado sts1 para procesar solicitudes de delegación.
- El usuario de Fabrikam Frank accede a la aplicación Contoso y se le concede acceso a los recursos de back-end.
Configuración del proveedor de identidades (IP)
Hay tres opciones disponibles para el administrador de Fabrikam.com, Frank:
- Comprar e instalar un producto STS, como servicios de federación de Active Directory® (AD FS).
- Suscribirse a un producto STS en la nube, como LiveID STS.
- Crear un STS personalizado mediante WIF.
En este escenario de ejemplo, se supone que Frank selecciona option1 e instala AD FS como IP-STS. También configura un punto de conexión denominado \windowsauth para autenticar a los usuarios. Al hacer referencia a la documentación del producto de AD FS y hablar con Adam, el administrador de TI de Contoso, Frank establece la confianza con el dominio de Contoso.com.
Configuración del proveedor de notificaciones
Las opciones disponibles para el administrador de Contoso.com, Adam, son las mismas que se describen anteriormente para el proveedor de identidades. En este escenario de ejemplo, se supone que Adam selecciona la opción 1 e instala AD FS 2.0 como RP-STS.
Configuración de la confianza con la dirección IP y la aplicación
Al hacer referencia a la documentación de AD FS, Adam establece la confianza entre Fabrikam.com y la aplicación.
Configuración de la delegación
AD FS proporciona procesamiento de delegación. Al hacer referencia a la documentación de AD FS, Adam habilita el procesamiento de tokens actAs.
Cambios específicos de la aplicación
Se deben realizar los siguientes cambios para agregar compatibilidad con la delegación de identidades a una aplicación existente. Daniel usa WIF para realizar estos cambios.
- Almacenamiento en caché del token de arranque que web1 recibió de sts1.
- Uso de CreateChannelActingAs con el token emitido para crear un canal en el servicio web de back-end.
- Llamada al método del servicio de back-end.
Almacenamiento en caché del token de arranque
El token de arranque es el token inicial emitido por el STS, y la aplicación extrae notificaciones de él. En este escenario de ejemplo, sts1 emite este token para el usuario Frank y la aplicación la almacena en caché. En el ejemplo de código siguiente se muestra cómo recuperar un token de arranque en una aplicación de ASP.NET:
// Get the Bootstrap Token
SecurityToken bootstrapToken = null;
IClaimsPrincipal claimsPrincipal = Thread.CurrentPrincipal as IClaimsPrincipal;
if ( claimsPrincipal != null )
{
IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity;
bootstrapToken = claimsIdentity.BootstrapToken;
}
WIF proporciona un método, CreateChannelActingAs, que crea un canal del tipo especificado que aumenta las solicitudes de emisión de tokens con el token de seguridad especificado como un elemento ActAs. Puede pasar el token de arranque a este método y, a continuación, llamar al método de servicio necesario en el canal devuelto. En este escenario de ejemplo, la identidad de Frank tiene la propiedad Actor establecida en la identidad de web1.
El siguiente fragmento de código muestra cómo llamar al servicio web con CreateChannelActingAs y, a continuación, llamar a uno de los métodos del servicio, ComputeResponse, en el canal devuelto:
// Get the channel factory to the backend service from the application state
ChannelFactory<IService2Channel> factory = (ChannelFactory<IService2Channel>)Application[Global.CachedChannelFactory];
// Create and setup channel to talk to the backend service
IService2Channel channel;
lock (factory)
{
// Setup the ActAs to point to the caller's token so that we perform a
// delegated call to the backend service
// on behalf of the original caller.
channel = factory.CreateChannelActingAs<IService2Channel>(callerToken);
}
string retval = null;
// Call the backend service and handle the possible exceptions
try
{
retval = channel.ComputeResponse(value);
channel.Close();
} catch (Exception exception)
{
StringBuilder sb = new StringBuilder();
sb.AppendLine("An unexpected exception occurred.");
sb.AppendLine(exception.StackTrace);
channel.Abort();
retval = sb.ToString();
}
Cambios específicos del servicio web
Dado que el servicio web se compila con WCF y está habilitado para WIF, una vez configurado el enlace con IssuedSecurityTokenParameters con la dirección del emisor adecuada, la validación de ActAs se administra automáticamente por WIF.
El servicio web expone los métodos específicos necesarios para la aplicación. No se necesitan cambios de código específicos en el servicio. En el ejemplo de código siguiente se muestra la configuración del servicio web con IssuedSecurityTokenParameters:
// Configure the issued token parameters with the correct settings
IssuedSecurityTokenParameters itp = new IssuedSecurityTokenParameters( "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" );
itp.IssuerMetadataAddress = new EndpointAddress( "http://localhost:6000/STS/mex" );
itp.IssuerAddress = new EndpointAddress( "http://localhost:6000/STS" );
// Create the security binding element
SecurityBindingElement sbe = SecurityBindingElement.CreateIssuedTokenForCertificateBindingElement( itp );
sbe.MessageSecurityVersion = MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10;
// Create the HTTP transport binding element
HttpTransportBindingElement httpBE = new HttpTransportBindingElement();
// Create the custom binding using the prepared binding elements
CustomBinding binding = new CustomBinding( sbe, httpBE );
using ( ServiceHost host = new ServiceHost( typeof( Service2 ), new Uri( "http://localhost:6002/Service2" ) ) )
{
host.AddServiceEndpoint( typeof( IService2 ), binding, "" );
host.Credentials.ServiceCertificate.SetCertificate( "CN=localhost", StoreLocation.LocalMachine, StoreName.My );
// Enable metadata generation via HTTP GET
ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
smb.HttpGetEnabled = true;
host.Description.Behaviors.Add( smb );
host.AddServiceEndpoint( typeof( IMetadataExchange ), MetadataExchangeBindings.CreateMexHttpBinding(), "mex" );
// Configure the service host to use WIF
ServiceConfiguration configuration = new ServiceConfiguration();
configuration.IssuerNameRegistry = new TrustedIssuerNameRegistry();
FederatedServiceCredentials.ConfigureServiceHost( host, configuration );
host.Open();
Console.WriteLine( "Service2 started, press ENTER to stop ..." );
Console.ReadLine();
host.Close();
}