Compartir a través de

  • Artículo

Este artículo proviene de un motor de traducción automática.

AD FS 2.0 en soluciones de identidad

Uso de los Servicios de federación de Active Directory 2.0 en soluciones de identidad

Zulfiqar Ahmed

Descargar el ejemplo de código

Como programador, probablemente sabe algo acerca de Windows Identity Foundation (WIF), anteriormente denominado “ Geneva Framework ”, que proporciona una API eficaz para reclamaciones habilitar sus aplicaciones y crear servicios de tokens de seguridad personalizado. Quizás sea menos familiar para Active Directory Federation Services versión 2.0 (AD FS 2.0), código originalmente “ Geneva servidor con nombre, ” que es una federación preparadas para la empresa y la solución único de sesión (SSO). AD FS 2.0 es una evolución de AD FS 1.0 y admite (WS-Trust) activo y pasivos escenarios (WS-Federation y SAML 2.0).

En este artículo, he iniciar con una descripción general de AD FS 2.0 y, a continuación, proporcionar información sobre cómo los programadores pueden utilizar AD FS 2.0 en sus soluciones de identidad. El foco está en la funcionalidad de token de emisión de AD FS 2.0, basándose en la versión Beta 2. Como puede ver desde de figura 1, este token de emisión es sólo una pequeña porción de AD FS 2.0, pero es de particular interés para los desarrolladores de .NET moverse hacia la identidad federada. Desde el punto de vista de la arquitectura, AD FS 2.0 está integrado en la parte superior de WIF y Windows Communication Foundation (WCF), por lo tanto, si está familiarizado con estas tecnologías, debe sentirse derecho en casa con AD FS 2.0.


Figura 1 de arquitectura de AD FS 2.0

Información general de AD FS 2.0

En un nivel alto, AD FS 2.0 es una colección de los servicios que se muestra en de figura 2.

En el núcleo de AD FS 2.0 es un servicio de tokens de seguridad (STS) que utiliza Active Directory como su almacén de identidades y Protocolo ligero de acceso a directorios (LDAP), SQL o un almacén personalizado como un almacén de atributo. El STS en AD FS 2.0 puede emitir tokens de seguridad al llamador mediante varios protocolos, incluidos WS-Trust, WS-Federation y lenguaje de marcado de aserción de seguridad (SAML) 2.0. El STS de AD FS 2.0 también admite formatos de tokens SAML 1.1 y 2.0 SAML.

AD FS 2.0 está diseñado con una separación limpia entre protocolos de cable y el mecanismo interno emisión de token. Protocolos de cable diferente se transforman en un modelo de objetos estandarizado a la entrada del sistema mientras AD FS 2.0 utiliza internamente el mismo modelo de objetos para cada protocolo. Esta separación permite AD FS 2.0 ofrecer un modelo de extensibilidad limpio, independientemente de las complejidades de protocolos de cable distintas. Más detalles de AD FS 2.0 extensibilidad se ofrece en el SDK de AD FS 2.0 anteriores a RTM.


Figura 2 de componentes de AD FS 2.0

AD FS 2.0 como un proveedor de identidades

Puede utilizar AD FS 2.0 en varios escenarios comunes. El escenario más sencillo y más común es utilizar AD FS 2.0 como proveedor de identidad para que pueda emitir tokens SAML para las identidades que administra. Para, es necesario crear una nueva entidad de usuario de confianza. Una fiesta confiar en AD FS 2.0 es una representación de una aplicación (un sitio Web o un servicio Web) y contiene toda la información relacionada con la seguridad, como certificado de cifrado, las reclamaciones de reglas de transformación y así sucesivamente.

Configurar una entidad de usuario de confianza

Configurar una nueva entidad confiar a través de AD FS 2.0 es fácil. El Asistente para agregar entidades de confianza puede tener acceso a través del nodo de directiva de AD FS 2.0 Management console. Una vez allí, usted o el administrador del sistema debe especificar los orígenes de datos apropiado en la página Seleccionar origen de datos del asistente, que se muestra en de figura 3.


Figura 3 de página de origen de datos SELECT agregar confiar elemento

Las dos primeras opciones permiten configurar automáticamente la entidad de usuario de confianza utilizando metadatos de federación. Si tiene acceso a los metadatos de federación del receptor confiar en una red o en un archivo local, seleccione una de estas dos opciones porque son menos propensas a error, automatizar todo el proceso y actualización automática si cambian los detalles de la fiesta confiar en el futuro. Estas opciones son una mejora importante sobre AD FS 1.0, no ofrece tales procesos automatizados.

La tercera opción requiere que escriba manualmente todos los detalles de configuración. Utilice esta opción sólo cuando no tiene acceso a los metadatos de la federación o desea controlar los detalles de la configuración de otro fabricante confiar.

Es instructivo ejecutar mediante la opción “ introduzca manualmente la configuración fiesta confiar ” simplemente para que pueda ver todos los pasos necesarios para configurar una nueva entidad de usuario de confianza. En las páginas del asistente, se le pedirá que elija un perfil, elija AD FS 2.0 perfil si desea admitir clientes tanto en el explorador y basados en WCF o AD FS 1.x perfil si sólo necesita AD FS 1.x interoperabilidad y no admiten los clientes de activo (WCF, CardSpace); configurar el certificado que se utiliza para cifrar el símbolo (token) para que pueda descifrar sólo la parte de usuario de confianza con la clave privada correspondiente y utilice el token emitido; y configurar el identificador que se utilizará para identificar esta fiesta confiar en todas las solicitudes de emisión de token.

Cuando finalice al Asistente para agregar entidades de confianza, se abrirá una herramienta Editor de reglas. En esta herramienta, configurar reglas de emisión y transformación de reclamaciones. Figura 4 muestra la herramienta Editor de reglas configurada para emitir un token con una única notificación cuyo valor se recuperará desde el almacén principal atributo. Observe que el atributo displayName se asigna a la notificación de nombre. AD FS 2.0 introduce un nuevo lenguaje específico del dominio textual que permite definir reglas sencillas para derivar el proceso de emisión y transformación de reclamaciones. Cada regla consta de una condición y una acción y termina, como en [c] = >; con un punto y coma. La lógica de transformación es una serie de reglas que se ejecutan secuencialmente durante el proceso de emisión de token. En de figura 4, la ficha de vista simple proporciona una interfaz de usuario para definir estas reglas. La ficha de vista avanzada le permite reglas autor directamente mediante el lenguaje de dominio específico.


Figura 4 de Herramienta Editor de reglas

Este ejemplo se han explicado lo fácil que es configurar una entidad de usuario de confianza de confianza en AD FS 2.0. En este momento, cuando AD FS 2.0 recibe una solicitud de token de emisión, extrae un identificador del protocolo alámbrico (por ejemplo, el elemento appliesTo en el caso de WS-Trust) y lo utiliza para buscar una fiesta de usuario de confianza de destino. Una vez que se encuentra una fiesta de usuario de confianza, la configuración especificada en el asistente se utiliza para derivar la lógica de token de emisión.

Ahora examine cómo puede usar WCF para solicitar un token para esta fiesta confiar desde AD FS 2.0 let’s.

Solicitar un token con WCF

Hay dos opciones para interactuar con AD FS 2.0 STS mediante WCF:

  • Adquirir explícitamente un símbolo (token) que actúa como un cliente de WS-Trust
  • Configurar a un cliente WCF para que la infraestructura implícitamente adquiere un símbolo (token) como parte de la llamada

En la opción explícita, la clase WSTrustClient proporciona una API simple y directa a símbolos (tokens) de solicitud de un STS mediante el protocolo WS-Trust, tal como se muestra aquí.

string baseUri = "https://bccoss.com/";

WindowsWSTrustBinding binding = new WindowsWSTrustBinding(SecurityMode.Transport);

WSTrustClient tokenClient = new WSTrustClient(binding,
    new EndpointAddress(baseUri + "Trust/2005/WindowsTransport/"),
    TrustVersion.WSTrustFeb2005,
    new ClientCredentials());

//create a token issuance issuance
RequestSecurityToken rst =
    new RequestSecurityToken(WSTrustFeb2005Constants.RequestTypes.Issue);
//Relying Party’s identifier
rst.AppliesTo = new EndpointAddress("http://local.zamd.net/");
//call ADFS STS
SecurityToken token = tokenClient.Issue(rst);

Este código solicita un símbolo (token) utilizando la autenticación de Windows con seguridad de transporte. Como puede ver, en modo explícito, obtener acceso al símbolo (token sin formato), que puede utilizar para llamar a servicios más adelante. Por ejemplo, en una aplicación cliente inteligente, podría adquirir tokens para distintos servicios en tiempo de inicio o inicio de sesión de aplicación, guardarlos en una caché de tokens y utilizarlas a lo largo del período de duración de la aplicación llamar a servicios de fondo diferentes. Además, en un escenario donde viven muchos servicios en el mismo límite de seguridad lógico, compartir el mismo certificado, puede utilizar el modo explícito para adquirir un único símbolo (token) y, a continuación, utilice al llamar a todos esos servicios.

 En un entorno de prueba, en el que normalmente tiene acceso a la clave privada de la parte usuario de confianza, puede utilizar el código siguiente para extraer una aserción SAML de símbolo (token) devuelto.

//Private Key certificate of RP (local.zamd.net)
X509Certificate2 rpCertificate = new X509Certificate2("zamd.net.pfx", "pwd");
string assertion = Util.ExtractSAMLAssertion(token, rpCertificate);

<saml:Attribute AttributeName="givenname" AttributeNamespace="https://schemas.xmlsoap.org/ws/2005/05/identity/claims">
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue>
</saml:Attribute>

El token SAML contiene sólo las solicitudes configuradas para esta fiesta particular de usuario de confianza. Consulte de figura 4 , que muestra cómo se configuró el símbolo (token) de salida del receptor confiar para devolver un solo atributo. Puede editar la configuración de la parte usuario de confianza para incluir las reclamaciones más en la salida y debería ver todos ellos reflejan aquí. También puede utilizar el idioma de la directiva de reclamaciones directamente para definir la transformación enriquecido y lógica de filtrado.

La API de WSTrustClient y los nuevos enlaces de WSTrust forman parte de WIF, por lo que para que funcione el código anterior, WIF debe estar instalado en el cliente. También puede utilizar la API de WCF directamente a adquirir explícitamente un símbolo (token), pero la simplicidad y facilidad de uso WIF ofertas puede tardar una tarea fuera de la lista de tareas pendientes.

En el código en de figura 5, IssuedSecurityTokenProvider es el equivalente WCF de WSTrustClient y se utiliza normalmente wsFederationBinding al solicitar testigos en su nombre. Porque es una API pública, si lo desea, puede utilizar en el código si necesita acceso a un símbolo (token) sin formato. El enlace CustomBinding es equivalente a WindowsWSTrustBinding.

Figura 5 de Using IssuedSecurityTokenProvider para tener acceso a un token RAW

sstring baseUri = "https://bccoss.com/";

//Limited edition of WSTrustClient:)
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider();
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer();

//Relying Party's identifier
provider.TargetAddress = new EndpointAddress(new Uri("http://local.zamd.net"));
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri + "Trust/2005/WindowsTransport/"));

provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
provider.MessageSecurityVersion = MessageSecurityVersion.
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

HttpsTransportBindingElement tbe = new HttpsTransportBindingElement();
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate;
CustomBinding stsBinding = new CustomBinding(tbe);

provider.IssuerBinding = stsBinding;
provider.Open();
//Request a token from ADFS STS
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));

En la opción implícita, puede utilizar el estándar wsFederationHttpBinding, en cuyo caso la infraestructura WCF forma transparente adquiere el símbolo (token) y lo envía como parte de la llamada al servicio. Siempre que cree a un nuevo proxy WCF y utilizarlo para llamar a un servicio, la infraestructura de búsquedas en un nuevo token. Obviamente, esto sería una exageración en algunos escenarios. El código en de figura 6 configura un EmployeeService ficticio para requerir tokens desde AD FS 2.0.

Figura 6 de wsFederationHttpBindingto Using adquirir un token implícitamente

<system.serviceModel>
  <services>
    <service name="EmployeeService.EmployeeService">
      <endpoint address="http://localhost:9990/ES"
        binding="ws2007FederationHttpBinding"
        contract="EmployeeServiceContract.IEmployeeService"
        bindingConfiguration="adfsFed"/>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="adfsFed">
        <security mode="Message">
          <message negotiateServiceCredential="false" >
            <issuer address="https://bccoss.com/Trust13/KerberosMixed"
               binding="customBinding" bindingConfiguration="MixedKerberos"/>
          </message>
        </security>
      </binding>
     </ws2007FederationHttpBinding>
     <customBinding>
       <binding name="MixedKerberos">
         <security authenticationMode="KerberosOverTransport"/>
         <httpsTransport/>
       </binding>
     </customBinding>
   </bindings>
</system.serviceModel>
Asignación AD FS 2.0 conceptos a WCF

La responsabilidad de principales de AD FS 2.0 es emitir tokens a los usuarios autenticados. Los usuarios pueden autenticarse mediante mecanismos de autenticación diferentes (como autenticación de Windows). Puede ver todos los mecanismos de autenticación compatibles seleccionando el nodo de extremos en la consola de administración.

Observará dos conceptos familiares de seguridad WCF como encabezados de columna dentro del nodo extremos:

  • Tipo de autenticación es AD FS 2.0 equivalente de la terminología WCF clientCredentialType.
  • Opciones del modo de seguridad son transporte, Message o mixto. Mixto es la 2.0 AD FS equivalente de TransportWithMessageCredentials de WCF.

Se exponen distintas combinaciones de estos dos valores utilizando diferentes extremos y elija un extremo específico según sus necesidades de autenticación. Por ejemplo, si necesita autenticarse con el nombre de usuario y contraseña, elegiría el extremo de la autenticación de borrar contraseña.

Para AD FS 2.0 STS, asignación de estos conceptos a dirección, enlace y contrato (ABC) en WCF, obtendrá los equivalentes siguientes:

  • Dirección = AD FS 2.0 dirección base + dirección URL del extremo del
  • Enlace = del extremos modo de seguridad + tipo de autenticación
  • Contrato = protocolo de WS-Trust estándar

Federación AD FS 2.0 con otro STS

Además de crear partes de usuario de confianza, puede establecer una relación de confianza entre AD FS 2.0 y su STS personalizados o otro AD FS 2.0. Por ejemplo, si ya tiene un STS que autentica los usuarios y emite tokens, puede simplemente agregar él como un proveedor de identidad de confianza dentro de AD FS 2.0, que aceptará tokens emitidos desde el STS.

Configurar un proveedor de identidades

Configurar un proveedor de confianza, nueva identidad en AD FS 2.0 es similar a configurar una nueva entidad de usuario de confianza. El asistente Agregar proveedor de identidades utiliza busca y mucho actúa como el Asistente para agregar entidades de confianza (hacer referencia a de figura 3).

Para obtener la página Configurar identificador, seleccione la opción de configuración manual nuevo (como hizo en de figura 3) y seleccione AD FS 2.0 perfil en la página Elegir perfil. Deje la configuración predeterminada en la página Configurar dirección URL. A continuación, elija un identificador y un certificado de clave pública para su proveedor de identidades y finalizar el Asistente para registrar el nuevo proveedor de identidad.

Solicitar un token con WCF

Una vez registrar un proveedor de identidad adicional con AD FS 2.0, la arquitectura lógica se parece a la configuración que se muestra en de figura 7.


Figura 7 de arquitectura de AD FS 2.0 con un proveedor de identidades adicionales

El código en de figura 8 le permite adquirir un símbolo (token) de forma explícita, lo que proporciona la flexibilidad para almacenar en caché el símbolo (token) localmente y enviar al servicio según sea necesario.

Figura 8 de Using IssuedTokenWSTrustBinding para adquirir un token explícitamente

string adfsStsUri = "http://bccoss.com/Trust/2005/IssuedTokenAsymmetricBasic256";

//binding for local STS(IP-STS)
WSHttpBinding localStsBinding = new WSHttpBinding(SecurityMode.Message);

localStsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
localStsBinding.Security.Message.EstablishSecurityContext = false;
localStsBinding.Security.Message.NegotiateServiceCredential = false;

EndpointAddress localStsEpr = new EndpointAddress(
   new Uri("http://localhost:9000/STS/"),
   new X509CertificateEndpointIdentity(new X509Certificate2(@"MyCustomSTSPublicKey.cer")));

//This binding will transparently acquire all the intermediate tokens as part of the call. (R-STS)
IssuedTokenWSTrustBinding fedBinding = new IssuedTokenWSTrustBinding(localStsBinding, localStsEpr);
fedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;

EndpointAddress adfsStsEpr = new EndpointAddress(
    new Uri(adfsStsUri),
    new X509CertificateEndpointIdentity(new X509Certificate2("AdfsStsPubicKeyOnly.cer")));

WSTrustClient trustClient = new WSTrustClient(fedBinding, adfsStsEpr, TrustVersion.WSTrustFeb2005,
null);

//Create a security token request
RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);
//Set Relying Party's identifier accordingly
rst.AppliesTo = new EndpointAddress("http://local.zamd.net");

SecurityToken finalToken = trustClient.Issue(rst);

Es muy similar a wsFederationHttpBinding IssuedTokenWSTrustBinding en que se oculta toda la complejidad de intermedio símbolos (tokens) de forma transparente hablando con el STS de IP para adquirir un símbolo (token) intermedio que se envía a STS-R como un símbolo de autenticación.

El código de de figura 9 utiliza wsFederationHttpBinding para habilitar un cliente WCF implícitamente adquirir un símbolo (token) como parte de una llamada al servicio.

Observe que Estoy utilizando un customBinding cuando hablando al extremo /IssuedTokenMixedSymmetricBasic256. El estándar wsFederationHttpBinding no funciona aquí porque se intenta establecer una sesión segura, que es incompatible con esta AD FS 2.0 extremo. Para federarse a clientes WCF con AD FS 2.0, tiene que utilizar un customBinding o uno de los enlaces en WS-Trust nuevos que se incluye con WIF.

Figura 9 de wsFederationHttpBinding using para adquirir un token implícitamente

<system.serivceModel>
   <bindings>
      <wsFederationHttpBinding>
         <binding name="R-STS">
            <security mode="Message">
               <message>
                  <issuer address="https://bccoss.com/Trust/2005/IssuedTokenMixedSymmetricBasic256" binding="customBinding" bindingConfiguration="IP-STS"/>
               </message>
            </security>
         </binding>
      </wsFederationHttpBinding>

      <customBinding>
         <binding name="IP-STS">
            <security authenticationMode="IssuedTokenOverTransport">
               <issuedTokenParameters>
                  <issuer address="http://localhost:9000/CustomSTS" binding="wsHttpBinding"/>
               </issuedTokenParameters>
            </security>
            <httpsTransport/>
         </binding>
      </customBinding>
   </bindings>

   <client>
      <endpoint address="http://localhost:9990/ES" binding="wsFederationHttpBinding" bindingConfiguration="R-STS"
contract="ServiceReference1.IEmployeeService" name="WSFederationHttpBinding_IEmployeeService"/>
      </client>
</system.serviceModel>

Clientes de explorador y AD FS 2.0

AD FS 2.0 tiene soporte de primera clase para Web sesión único (WebSSO) y federación mediante protocolos WS-Federation y SAML 2.0.

Conceptualmente, WS-Federation y el protocolo SAML son similares aunque tienen las representaciones de cable distintas. El formato de telegrama de WS-Federation está estrechamente relacionado con protocolo de WS-Trust, por lo que es la elección lógica cuando está atendiendo a clientes activos y pasivos (basada en explorador). El protocolo SAML tiene una mejor interoperabilidad entre diferentes proveedores. AD FS 2.0 admite de forma nativa ambos de estos protocolos. Es una buena idea ceñirse a un único protocolo (por ejemplo, WS-Federation) dentro de su límite de seguridad y utilizar AD FS 2.0 como un concentrador del broker de protocolo para SSOs entrantes o salientes.

Considere un ejemplo de Let’s. Supongamos que tiene una aplicación ASP.NET sencilla que proporciona funcionalidad sólo a los usuarios autenticados. Como aplicación independiente, lógica de autenticación se implementa como parte de la aplicación y una interacción con esta aplicación debe seguir los pasos que se muestran en de figura 10.


Figura 10 de autenticación Direct en una aplicación ASP.NET simple

Aquí se están implementando los mecanismos de autenticación ASP.NET habituales, como autenticación de formularios. Nuestro objetivo es extraer la funcionalidad de autenticación de esta aplicación y utilice AD FS 2.0 en su lugar.

En AD FS 2.0 instalación, que se muestra en de figura 11, la aplicación se convierte en una entidad de usuario de confianza de confianza dentro de AD FS 2.0 y, por tanto, confía tokens emitidos por AD FS 2.0. La aplicación utiliza WIF para realizar todo el trabajo pesado de símbolo (token) de análisis, extrayendo reclamaciones y así sucesivamente. Se proporciona información de identidad a la aplicación mediante las abstracciones de IPrincipal/IIdentity estándar.

La autenticación distribuida en AD FS 2.0 es mucho más flexible que autenticación directa, y ofrece algunas ventajas principales:

  • Autenticación es externalized desde la aplicación, por lo que se puede cambiar el mecanismo de autenticación (por ejemplo, de nombre de usuario Kerberos) sin afectar a la aplicación.
  • La flexibilidad de un modelo basado en notificaciones puede proporcionar toda la información necesaria para la aplicación (como parte del testigo) directamente en vez de la aplicación en Sí recuperar esa información desde distintos orígenes.

La versión Beta 2 de WIF introdujo nuevas plantillas de proyecto que facilitan la lógica de autenticación de la aplicación para un STS externalize. En el momento de escribir este documento, estas plantillas están disponibles sólo en C#.


Figura 11 distribuidas autenticación en AD FS 2.0

Lógica de autenticación externalizing

Para externalize lógica de autenticación de la aplicación, utilice el cuadro de diálogo nuevo sitio Web de Microsoft Visual Studio. Seleccione la plantilla Claims-aware Web Site para crear un sitio de ASP.NET Web estándar que está preconfigurado con WIF.

Para iniciar al Asistente para utilidad de federación, que se muestra en de figura 12, haga clic con el botón secundario en el nodo sitio Web en el Explorador de soluciones y seleccione Modificar STS referencia en el menú.


Figura 12 de la utilidad de federación

En este ejemplo, vamos a elegir la opción “ usar a un STS existente ” y especifique AD FS 2.0 como el STS. El Asistente requiere la dirección URL del documento de metadatos automatizar todas las configuraciones necesarias. La dirección URL del documento de metadatos está disponible como un extremo dentro de AD FS 2.0.

Metadatos de federación contienen información esencial, como el certificado, las notificaciones que ofrece y la dirección URL de emisión de token de firma de STS. Tener un formato estándar para esta información permite herramientas automatizar el establecimiento de confianzas entre un STS y confiar partes.

La página Resumen del asistente resume los cambios que se van a realizarse en el archivo web.config.

El Asistente federación utilidad configura WIF en su sitio Web para proporcionar la funcionalidad siguiente:

  • Todas las solicitudes no autenticadas se redirigirá a AD FS 2.0.
  • Cualquier solicitud que contiene un símbolo (token) se procesarán y se presentará la información de identidad a la aplicación en forma de ClaimsIdentity/ClaimsPrincipal. La aplicación continuará tener acceso a información de identidad mediante las abstracciones estándar de IPrincipal/IIdentity independientemente del origen de esa información.

Antes de probar la aplicación, deberá realizar una última configuración cambiar en AD FS 2.0. Debe agregar un extremo adicional a la entidad de usuario de confianza para clientes de explorador. Este extremo es necesaria porque una vez que AD FS 2.0 ha procesado una solicitud de token de emisión, son necesarios dos fragmentos de información antes de que el testigo puede enviar al explorador:

  • La dirección donde debe enviarse el símbolo (token)
  • El protocolo (SAML o WS-Federation) a través de la que se debe enviar el símbolo (token)

Puede agregar un extremo pasivo a la fiesta confiar en la ficha extremos del cuadro de diálogo Propiedades de RP Test. Por ejemplo, si selecciona el tipo de extremo WS-Federation, AD FS 2.0 enviará tokens volver a la entidad de usuario de confianza mediante el protocolo WS-Federation. Dentro de la fiesta confiar, WIF, que comprende el protocolo de WS-Federation, de forma nativa procesa estos símbolos (tokens).

Ahora cuando intenta explorar a la aplicación, se le redirige automáticamente a AD FS 2.0 para la autenticación, donde puede elegir el método de autenticación que desea utilizar: Autenticación integrada de Windows, la autenticación de certificados o el formulario de nombre de usuario y contraseña.

Una vez que la autenticación es correcta,, junto con un token emitido por AD FS 2.0, se le redirige a la aplicación. WIF procesa este token y pone a disposición de la aplicación utilizando los mecanismos estándar de ASP.NET (por ejemplo, Page.User) la identidad final (en el formulario de solicitudes).

Federación basada en explorador

Puede extender un escenario básico autenticación externa en un escenario de federación agregando un proveedor de la identidad de confianza adicional. Se muestran las opciones de proveedor de identidad durante el proceso de autenticación.

Puede autenticar con AD FS 2.0 o de otro proveedor de identidades de confianza. Si selecciona un proveedor de identidades diferentes, se le redirige a ese proveedor de identidades y, tras la autenticación correcta, redirige de nuevo a AD FS 2.0, que a continuación, podría autenticar basándose en el token emitido por el proveedor de la identidad de confianza.

Combinación eficaz

Como ha visto en este artículo, AD FS 2.0 STS proporciona un simplemente solución ya preparada para reclamaciones habilitar sus servicios WCF y aplicaciones basadas en explorador para y. STS propio es sólo una pequeña porción de AD FS 2.0, que también incluye un aprovisionamiento del sistema, un motor de transformación basado en reglas de reclamaciones, servicios de infraestructura, administración y configuración de administración de la confianza automática y sus herramientas respectivos de CardSpace. Junto con WIF, AD FS 2.0 crea una combinación eficaz a soluciones de identidad del programa en la plataforma Windows.

Zulfiqar Ahmed es consultor senior en el equipo de consultoría de desarrollo de aplicaciones de Reino Unido (ADC) y puede ponerse en http://zamd.net de.