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

Identidad federada

Autenticación pasiva para ASP.NET con WIF

Michele Leroux Leroux

El objetivo de seguridad federada es proporcionar un mecanismo para establecer relaciones de confianza entre dominios para que los usuarios pueden autenticarse con su propio dominio al que se concede acceso a las aplicaciones y servicios que pertenecen a otro dominio. Esto posibilita las técnicas de autenticación como el inicio de sesión único, elimina la necesidad de crear y administrar las cuentas duplicadas para los usuarios a través de las aplicaciones y los dominios y significativamente reduce el costo para ampliar las aplicaciones a las partes de confianza.

En un modelo de seguridad federada, un proveedor de identidades (Juniper) realiza la autenticación y proporciona un servicio de tokens de seguridad (STS) a un problema de tokens de seguridad. Estos símbolos (tokens), a su vez, información sobre el usuario autenticado de aserción: su identidad y posiblemente otra información, como las funciones y derechos de acceso más granulares. En un mundo federado, esta información se conoce como solicitudes y control de acceso basado en notificaciones es fundamental para un modelo de seguridad federada. En este modelo, las aplicaciones y servicios de autorizan el acceso a las características y funcionalidad basada en las solicitudes de los emisores de confianza (el STS).

Las herramientas de plataforma, como Windows Identity Foundation (WIF), facilitan en gran medida la compatibilidad de este tipo de federación de identidades. WIF es un marco de modelo de identidad para la creación de aplicaciones basadas en reclamaciones y servicios y para la compatibilidad basada en SOAP (activo) y escenarios de federación de (pasivo) en el explorador. En el artículo “ -based de afirmaciones de autorización con WIF , ” en el número de noviembre de 2009 de MSDN Magazine, me centré en utilizando WIF con Windows Communication Foundation (WCF). En este artículo describe cómo implementar modelos de seguridad basada en solicitudes para los servicios de WCF y cómo migrar a la federación de identidades.

En este artículo seguimiento me centraré en el federación pasiva. I se explican el flujo de comunicación para la federación pasiva, muestran varias técnicas para habilitar la federación en las aplicaciones de ASP.NET, tratan las técnicas de autorización basada en solicitudes de ASP.NET y hablar acerca de los escenarios de cierre de sesión único de sesión y único. Asimismo, explicaré el subyacentes de las características WIF y componentes que admiten escenarios de federación pasivo.

Conceptos básicos de federación pasivo

Escenarios de federación pasivo se basan en la especificación de WS-Federation. Describe cómo solicitar los tokens de seguridad y cómo publicar y obtener documentos de metadatos de la federación, que facilita el establecimiento de relaciones de confianza. WS-Federation también describe los procedimientos de inicio de sesión y cierre de sesión único y otros conceptos de implementación de federación.

Mientras que WS-Federation trata muchos detalles acerca de la federación, hay secciones dedicadas a la federación en el explorador que se basan en HTTP GET y POST, redirecciones del explorador y las cookies para lograr el objetivo.

Algunos aspectos de la mensajería de federación pasiva se basan en estrecha colaboración en la especificación de WS-Trust. Por ejemplo, la federación pasiva emplea un formulario compatible con el Explorador de token de seguridad de solicitud (RST) y la respuesta RST (RSTR) cuando se solicite un token de seguridad de un STS. En el escenario de federación pasivo, llamaré el RST un mensaje de solicitud de inicio de sesión y el mensaje de respuesta RSTR inicio de una sesión en. La especificación de WS-Trust se centra en la federación (activa) basados en SOAP, por ejemplo, entre los clientes de Windows y servicios WCF.

De figura 1 se muestra un escenario sencillo de federación pasivo.

Figura 1 de un escenario de federación pasivo simple

Los usuarios autentican a su dominio y se conceden acceso a una aplicación Web de acuerdo con sus funciones. Los participantes de este esquema de autenticación son el usuario (objeto), un explorador Web (solicitante), una aplicación ASP.NET (la parte confía o punto de reunión), un Juniper responsable de autenticar los usuarios de su dominio y un STS pertenecientes al dominio del usuario (STS de IP). Una secuencia de redirecciones del explorador, se garantiza que el usuario está autenticado en su dominio para tener acceso al punto de reunión.

El usuario se desplaza a la aplicación de punto de reunión (1) y se redirige a su Juniper para ser autenticado (2). Si aún no se ha autenticado el usuario en el Juniper, el STS de IP que constituyen un problema o se le redirige a una página de inicio de sesión para recopilar las credenciales (3). El usuario proporciona sus credenciales (4) y ha sido autenticado por el STS de IP (5). En este momento, el STS de IP emite un token de seguridad de acuerdo con la solicitud de inicio de sesión y la respuesta de inicio de sesión que contiene el símbolo (token) se registra en el punto de reunión a través de la redirección del explorador (6). El punto de reunión, procesa el token de seguridad y autoriza el acceso basándose en las solicitudes lleva a (7). Si la autorización correcta, se presenta al usuario con la página que solicitó originalmente y devuelve una cookie de sesión (8).

La implementación de este escenario de federación pasivo con WIF y ASP.NET consiste en sólo unos pocos pasos:

1. Establecer una relación de confianza entre el punto de reunión y Juniper (STS de IP)
2. Habilitar la federación pasiva de la aplicación de ASP.NET
3. Implementar comprobaciones de autorización para controlar el acceso a las funciones de aplicación en las siguientes secciones que se analizará las características de WIF que admiten la federación pasiva, recorrer los pasos necesarios para este escenario sencillo de configurar y, a continuación, explore otras consideraciones prácticas para éste y otros escenarios.

Características WIF para la federación pasivo

Antes de tratar la implementación, deseo revisar las características de WIF especialmente útil para la federación de identidades dentro de las aplicaciones ASP.NET. WIF proporciona los siguientes módulos HTTP útiles:

• WSFederationAuthenticationModule (FAM): Habilita la federación en el explorador, el control de redirección para el STS adecuado para la autenticación y el símbolo (token) de la emisión y procesar la respuesta del inicio de sesión resultante para tetraboro el token de seguridad emitido a un ClaimsPrincipal que se utilizará para la autorización. En este módulo también trata otros mensajes de federación importantes como, por ejemplo, las solicitudes de cierre de sesión.
• SessionAuthenticationModule (SAM): Administra la sesión autenticada por generar el token de seguridad de sesión que contiene el ClaimsPrincipal, escribirla en una cookie, administrar la duración de la cookie de sesión y rehydrating el ClaimsPrincipal de la cookie cuando se presenta. En este módulo también mantiene una caché de símbolo (token) de sesión local.
• ClaimsAuthorizatonModule: Proporciona un punto de extensibilidad para instalar un ClaimsAuthorizationManager personalizado que puede ser útil para las comprobaciones de acceso centralizado.
• ClaimsPrincipalHttpModule: Crea un ClaimsPrincipal con la identidad del usuario actual asociada al subproceso de solicitud. Además, proporciona un punto de extensibilidad para instalar un ClaimsAuthenticationManager personalizado que puede ser útil para personalizar el ClaimsPrincipal va a asociar al subproceso de solicitud.

ClaimsPrincipalHttpModule es muy útil para las aplicaciones sin la federación pasiva. Se puede considerar como una herramienta útil para implementar un modelo de seguridad basada en solicitudes de la aplicación de ASP.NET antes de pasar a federación pasiva. En mi anterior artículo traté esta técnica para WCF.

Los demás módulos de tres normalmente se utilizan juntos para la federación pasiva, aunque ClaimsAuthorizationModule es opcional. La figura 2, se muestra cómo se ajustan estos módulos principales en la canalización de solicitudes y sus funciones en una solicitud de autenticación federados típico.

La figura 2 de componentes WIF y módulos HTTP que ejerzan federación pasivo

Teniendo en cuenta el flujo de federación de pasivo de de figura 1, cuando el usuario explore una página protegida en el punto de reunión (1), se denegará el acceso a la aplicación. La FAM procesa las solicitudes no autorizadas, produce el mensaje de inicio de sesión y redirige al usuario para el STS de IP (2). El STS de IP, se autentica al usuario (3), se genera una respuesta de inicio de sesión que incluye el símbolo (token) de seguridad emitido y se redirige a la aplicación de punto de reunión (4).

La FAM procesa la respuesta de inicio de sesión, lo que garantiza que la respuesta contiene un símbolo (token) de seguridad válido para el usuario autenticado y hydrates un ClaimsPrincipal desde el inicio de sesión, en la respuesta (5). Esto establecerá a la entidad de seguridad para la solicitud de subproceso y HttpContext. La FAM, a continuación, utiliza el SAM para serializar las reclamaciones ­ principal a una cookie HTTP (6) que se le presentará las peticiones posteriores durante la sesión del explorador. Si está instalado ClaimsAuthorizationModule, éste invocará configurado ClaimsAuthorization ­ Manager, que proporciona una oportunidad para realizar el acceso global comprueba (7) contra la ClaimsPrincipal antes para obtener acceso al recurso solicitado.

Una vez que se presenta el recurso solicitado, IsInRole de control de acceso se puede implementar con controles de inicio de sesión ASP.NET tradicionales, comprueba y otro código personalizado que consulta del usuario afirma (8).

En solicitudes posteriores se presenta el símbolo (token) de sesión de la cookie previamente escrita por el SAM (9). Este tiempo se dedique a SAM para validar el token de sesión y rehidratarse las reclamaciones ­ principal desde el símbolo (token) (10). No está ocupado el FAM a menos que la solicitud es una respuesta inicio de sesión, una solicitud de cierre de sesión, o si se deniega el acceso, lo que puede ocurrir si el símbolo de sesión no existe o ha caducado.

También en estos módulos, hay dos controles ASP.NET, que también son útiles para la federación pasiva:

• Control FederatedPassiveSignIn: Se puede utilizar en lugar de la FAM si la aplicación redirigirá a todas las llamadas no autorizadas a una página de inicio de sesión que aloja este control sólo cuando se requiere autenticación. Se supone que el usuario interactúa con el inicio de sesión, en el proceso, resulta útil en escenarios de autenticación step-up donde se pide al usuario las credenciales, posiblemente más credenciales desde el inicio de sesión original, según lo requiera la aplicación. El control supervisa el redireccionamiento a el STS, procesamiento de la respuesta de inicio de sesión, inicializando la ClaimsPrincipal de la respuesta y el establecimiento de una sesión segura al aprovechar la funcionalidad expuesta por el FAM y SAM.
• Control FederatedPassiveSignInStatus: Este control proporciona una forma interactiva del usuario iniciar la sesión o inicio de sesión fuera de la aplicación de punto de reunión, incluida la compatibilidad con federada de cierre de sesión.

La figura 3, se muestra cómo se cambia el flujo de comunicación cuando se utiliza el control FederatedPassiveSignIn. La aplicación se basa en la autenticación de formularios para proteger los recursos y redirigir a la página de inicio de sesión, que aloja el control (1). El usuario hace clic en el control FederatedPassiveSignIn (o se puede redirigir automáticamente a él), que desencadena una redirección a la STS (2). La página del control recibe la respuesta el STS, depender del FAM y el SAM para procesar la respuesta de inicio de sesión (3), tetraboro la ­ de afirmaciones principal y escribir la cookie de sesión (4). Cuando el usuario se redirige a la página solicitada originalmente (5), el SAM está ocupado para validar la cookie de sesión y tetraboro el ClaimsPrincipal para la solicitud. En este momento, esa página y de la ClaimsAuthorizationModule realizar sus comprobaciones de autorización, como se muestra en de figura 2.

La figura 3 de federación de pasivo con el FederatedPassive ­-control de inicio de sesión

Tanto el FAM el SAM se basan en apropiado seguridad ­ tipo de TokenHandler para procesar los símbolos entrantes. Cuando se reciba una respuesta de inicio de sesión, la FAM recorre en iteración SecurityTokenHandlerCollection buscando el controlador correcto de símbolo (token) para leer el símbolo (token) XML. En un escenario federado normalmente será Saml11Security ­ TokenHandler o Saml2Security ­ TokenHandler, aunque otros formatos de símbolo (token) pueden emplearse si agrega un símbolo (token) de controladores personalizados. El SAM, SessionSecurity ­ TokenHandler se utiliza para procesar el símbolo (token) de sesión asociado con la cookie de sesión.

Diversas opciones de configuración del modelo de identidad son importantes para el flujo de federación de pasivo y se utilizan para inicializar la FAM y SAM y el control FederatedPassiveSignIn (aunque este último también expone las propiedades configurables desde el Diseñador de Visual Studio). Mediante programación, puede proporcionar una instancia de la de servicio ­ tipo de configuración del espacio de nombres Microsoft.IdentityModel.Configuration, o puede proporcionar configuración declarativa en la sección <microsoft.identityModel>. La figura 4 ofrece un resumen de configuración de modelo de identidad, muchos de los cuales se van a tratar en las secciones siguientes.

La figura 4 del Resumen de <microsoft.identityModel> elementos esenciales de la

Sección	Descripción
<issuerNameRegistry>	Especificar una lista de emisores de certificados de confianza. Esta lista es principalmente útil para validar la firma de símbolo (token) para que se rechazarán los símbolos (tokens) firmados por certificados que no se confíe.
<audienceUris>	Especificar una lista de identificadores URI de audiencia válido de tokens SAML de entrada. Se puede desactivar para permitir que cualquier identificador URI, aunque no se recomienda.
<securityTokenHandlers>	Personalizar la configuración de la configuración de los controladores de símbolo (token) o proporcionar controladores personalizados de símbolo (token) para controlar cómo se valida, se autentican y se serializan símbolos (tokens).
<maximumClockSkew>	Ajustar la diferencia de tiempo permitido entre símbolos (tokens) y los servidores de aplicaciones para el símbolo (token) de validez. El sesgo de valor predeterminado es 5 minutos.
<certificateValidation>	Controlar cómo se validan los certificados.
<serviceCertificate>	Proporcione un certificado de servicio para descifrar los entrantes de símbolos (tokens).
<claimsAuthenticationManager>	Proporciona un tipo de ClaimsAuthenticationManager personalizado para personalizar o reemplazar el tipo de IClaimsPrincipal va a asociar al subproceso de solicitud.
<claimsAuthorizationManager>	Proporciona un tipo de ClaimsAuthorizationManager personalizado para controlar el acceso a la funcionalidad de un componente central.
<federatedAuthentication>	Proporcionar valores específicos de federación pasiva.

Habilitar la federación pasivo

WIF facilita la tarea Configurar la federación pasiva para las aplicaciones ASP.NET. Un STS debe proporcionar los metadatos (como se describe en la especificación de WS-Federation) de la federación y WIF proporciona una federación Utility (FedUtil.exe), que utiliza los metadatos de la federación para establecer la confianza entre un punto de reunión y un STS (entre otras características útiles para ambos escenarios de federación activos y pasivos). Se puede invocar FedUtil desde la línea de comandos o desde Visual Studio, con el botón secundario en el proyecto de punto de reunión y seleccione la referencia de STS de agregar.

Con el Asistente FedUtil se llevarán a cabo los siguientes pasos sencillos:

• La primera página del asistente, puede confirmar el archivo de configuración que se debe modificar mediante el asistente y el URI de la aplicación de punto de reunión.
• La segunda página solicita la ruta de acceso al documento XML de metadatos de la federación para el STS con la que el punto de reunión establecer la confianza.
• La tercera página permite proporcionar un certificado que se utilizará para descifrar símbolos (tokens).
• La página final muestra una lista de las solicitudes que ofrece el STS, que se puede utilizar para planear las decisiones de control de acceso, por ejemplo.

Cuando se completen los pasos del asistente, se modifica el proyecto para agregar una referencia al ensamblado Microsoft.IdentityModel FedUtil. También modifica el archivo web.config para instalar los módulos FAM y SAM y proporcionar valores de configuración de modelo de identidad de dichos módulos. La aplicación ahora admite la federación pasiva y redirigirá las solicitudes no autorizadas para el STS de confianza.

Hay una suposición aquí que el STS tiene conocimiento previo de punto de reunión, por tanto, se emitirán símbolos (token) para los usuarios autenticados que intenta obtener acceso al punto de reunión y por supuesto que tiene la clave pública el punto de reunión requiere el STS se utiliza para cifrar los símbolos (tokens). Se trata de una forma sencilla de obtener las aplicaciones de ASP.NET que se configura inicialmente para la federación. Por supuesto, es útil para comprender cómo configurar esto desde el principio en caso de los ajustes necesarios y cómo van más allá de la configuración básica habilitada por el asistente. Me centraré en el enfoque “ desde el principio ” a partir de aquí en de.

Sin utilizar FedUtil, tiene que agregar manualmente una referencia al ensamblado Microsoft.IdentityModel y configurar manualmente la FAM y los módulos de SAM junto con la configuración del modelo de identidad es necesario. Los módulos HTTP se agregan dos secciones: System.Web para servicios de Internet Information Server (IIS) 6 y System.WebServer para IIS 7. Si que la aplicación se aloja en IIS 7, los módulos WIF se configuran del siguiente modo:

<modules>
  <!--other modules-->
  <add name="SessionAuthenticationModule" 
    type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
    preCondition="managedHandler" />
  <add name="WSFederationAuthenticationModule" 
    type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
    preCondition="managedHandler" />
</modules>

De forma predeterminada esta configuración sólo protege los recursos con las extensiones asignadas explícitamente que se controlan en la canalización ASP.NET (.aspx, .asax etc.). Para proteger los recursos adicionales con la autenticación federado, debe asignar las extensiones a la canalización ASP.NET en IIS o runAllManagedModulesForAllRequests se puede establecer en true en los módulos de configuración (sólo en IIS 7) como sigue:

<modules runAllManagedModulesForAllRequests="true">

Para FAM empezar, también debe establecer el modo de autenticación de ASP.NET en ninguno y denegar el acceso a recursos de la aplicación de los usuarios anónimos:

<authentication mode="None" />

<authorization>
  <deny users="?" />
</authorization>

Ambos módulos se basan en valores de configuración de modelo de identidad que se describe en de figura 4, un ejemplo típico de los cuales se muestra en de figura 5. La mayoría de estas opciones es generada por FedUtil, con excepción de certificateValidation y algunos de los parámetros de federatedAuthentication. Normalmente recomiendo usar el modo de validación de certificado PeerTrust, lo que significa que se agregue explícitamente todos los certificados, incluidos los que el emisor de confianza, en el almacén del local del equipo TrustedPeople de confianza.

La figura 5 de la configuración del modelo de identidad para la federación pasivo

<microsoft.identityModel>
  <service>
    <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <trustedIssuers>
        <add thumbprint="EF38A0A6D1274766093D3D78BFE4ECA77C62D5C3" 
          name="http://localhost:60768/STS/" />
      </trustedIssuers>
    </issuerNameRegistry>
    <certificateValidation certificateValidationMode="PeerTrust" 
      revocationMode="Online" trustedStoreLocation="LocalMachine"/>
    <audienceUris>
      <add value="http://localhost:50652/ClaimsAwareWebSite2/" />
    </audienceUris>
    <federatedAuthentication>
      <wsFederation passiveRedirectEnabled="true" 
        issuer="http://localhost:60768/STS/" 
        realm="http://localhost:50652/ClaimsAwareWebSite2/" 
        requireHttps="true" />
      <cookieHandler requireSsl="true" name="FedAuth"  
        hideFromScript="true" path="/ClaimsAwareWebSite2" />
    </federatedAuthentication>
    <serviceCertificate>
      <certificateReference x509FindType="FindByThumbprint" 
        findValue="8A90354199D284FEDCBCBF1BBA81BA82F80690F2" 
        storeLocation="LocalMachine" storeName="My" />
    </serviceCertificate>
  </service>
 </microsoft.identityModel>

Normalmente debe requieren HTTPS/SSL para la federación pasiva proteger el símbolo (token) de portador emitidos frente a ataques de intermediario y requerir HTTPS/SSL para las cookies de sesión. De forma predeterminada, las cookies están ocultas a la secuencia de comandos, pero es una opción importante, motivo por el cual llamar en de figura 5.

El nombre y ruta de acceso de la cookie, el nombre predeterminado es FedAuth, la ruta de acceso al directorio de aplicación. Puede ser útil especificar un nombre único para la cookie, en especial si muchas aplicaciones de punto de reunión en la solución comparten el mismo dominio. Por el contrario, se puede especificar una ruta de acceso genérico cuando se desea que las cookies para compartirse entre varias aplicaciones en el mismo dominio.

Se suelen utilizar FedUtil para configurar las aplicaciones de ASP.NET para la federación pasiva con el FAM y SAM, a continuación, ajustar la configuración apropiada de acuerdo con los requisitos de la solución. También puede utilizar el control PassiveFederationSignIn en lugar de la FAM tal como se muestra en de figura 3. El control o bien puede cargar su configuración de la sección microsoft.identityModel, o puede establecer propiedades directamente en el control.

El método de control es útil si desea que las solicitudes no autorizadas se redirijan a una página de inicio de sesión donde el usuario puede firmar explícitamente al hacer clic en el control, en lugar de tener la FAM redirigir automáticamente a el STS. Por ejemplo, si el usuario puede pertenecer a más de un proveedor de identidades (dominio principal), la página de inicio de sesión no puede proporcionar un mecanismo para ella indicar su territorio principal anterior a redirigir a el STS. Detección del territorio principal se analizará en breve.

Pasivo emisión de token

Como se mencionó anteriormente, federación pasiva se basa en las redirecciones HTTP GET y POST y el explorador para facilitar la comunicación entre el punto de reunión y STS. La figura 6 muestra los parámetros de solicitud primaria necesarios en el inicio de sesión de la solicitud y respuesta de inicio de sesión durante este proceso.

La figura 6 de Inicio de sesión principal de la solicitud y respuesta parámetros involucrado en el pasivo solicitudes de federación

Cuando el STS recibe la solicitud de inicio de sesión, comprobará que sepa sobre el punto de reunión, compruebe el parámetro wtrealm con su lista de conocidos de los territorios de punto de reunión. Probablemente el STS tendrá conocimiento previo de punto de reunión, el certificado necesario para el símbolo (token) de cifrado y las expectativas con respecto a las notificaciones que desee que se incluirán en el token emitido. El punto de reunión puede indicar que afirma que es necesario si proporciona el parámetro opcional wreq con una solicitud de inicio de sesión completa y el STS de manera opcional puede respetar esa lista o decidir forma autónoma que se pretende conceder en función de usuario autenticado.

En un escenario de federación simple como que se describe en del 1 de la figura, hay un único punto de reunión y un STS de IP único responsable de autenticar a los usuarios. Si el STS de IP, se autentica a los usuarios de un dominio de Windows, que puede emitir las solicitudes de funciones como administrador, usuario o invitado. La suposición es que estas funciones tienen significado para el punto de reunión para la autorización. En la siguiente sección, va asumo estas funciones suficiente y tratan las técnicas de autorización. A continuación, trataré la transformación de solicitudes en el punto de reunión para convertir las reclamaciones de STS en algo más útil para la autorización según sea necesario.

Autorización basada en notificaciones

Como se analizó en mi artículo anterior, basada en funciones seguridad en .NET Framework espera que un principal de seguridad está asociado a cada subproceso. La entidad de seguridad, en función de IPrincipal, ajusta la identidad del usuario autenticado en una implementación de IIdentity. WIF proporciona ClaimsPrincipal y ClaimsIdentity tipos basados en IClaimsPrincipal y IClaimsIdentity (que se derivan en última instancia de IPrincipal e IIdentity). Cuando la FAM procesa la respuesta de inicio de sesión, lo hydrates un ClaimsPrincipal el token de seguridad emitido. Del mismo modo, el SAM hydrates un ClaimsPrincipal para la cookie de sesión. Este ClaimsPrincipal es el corazón de WIF la autorización de la aplicación ASP.NET.

Puede utilizar cualquiera de los siguientes métodos de autorización:

• Utilizar configuración de autorización de la ubicación específica para restringir el acceso a directorios o recursos de aplicación individuales.
• Utilizar controles de inicio de sesión ASP.NET, como, por ejemplo, el control LoginView, para controlar el acceso a la funcionalidad.
• Utilice ClaimsPrincipal para realizar comprobaciones de IsInRole dinámicas (por ejemplo, para ocultar o mostrar los elementos de interfaz de usuario dinámicamente).
• Utilice el tipo de PrincipalPermission para realizar las peticiones de permiso dinámico o la clase PrincipalPermissionAttribute si la petición de permiso declarativa parece adecuada en un método concreto.
• Proporcionar un ClaimsAuthorizationManager personalizado para centralizar el acceso se comprueba en un único componente, incluso antes para cargar el recurso solicitado.

Las tres primeras de estas opciones se basan en el método IsInRole expuesto por el tipo de ClaimsPrincipal. Debe seleccionar una función reclamación tipo de conexión para la comprobación de IsInRole para que las solicitudes correctas que se utilizará para controlar el acceso. El tipo de solicitud de funciones predeterminado para WIF es:

https://schemas.microsoft.com/ws/2008/06/identity/claims/role

Si ClaimsPrincipal incluye reclamaciones definidas, el tipo de notificación de la función coincidirá con el valor predeterminado. Más adelante, trataré las solicitudes de permiso en el contexto de la transformación de solicitudes. Cuando éstos se utilizan, debe especificar el tipo de solicitud de permiso como el tipo de notificación de la función para que sea efectivo IsInRole.

Puede controlar el acceso a páginas específicas o directorios globalmente desde el archivo web.config. En la raíz de la aplicación, proporcionar una etiqueta de ubicación que especifica la ruta de acceso para proteger, una lista de funciones aceptables y denegar el acceso a todos los demás usuarios. A continuación, permite sólo los administradores tener acceso a archivos bajo el directorio AdminOnly:

<location path="AdminOnly">
  <system.web>
    <authorization>
      <allow roles="Administrators" />
      <deny users="*"/>
    </authorization>
  </system.web>
</location>

Como alternativa, puede colocar un archivo web.config en cualquier subdirectorio y especificar las reglas de autorización. La colocación de la siguiente configuración en el directorio AdminOnly consigue el mismo resultado:

<configuration>
  <system.web>
    <authorization >
      <allow roles="Administrators" />
      <deny users="*"/>
    </authorization>
  </system.web>
</configuration>

Para ocultar dinámicamente y mostrar los componentes de interfaz de usuario o controlar el acceso a funciones dentro de una página, puede aprovechar las características basadas en funciones de los controles, como el LoginView. Sin embargo, la mayoría de programadores prefiere establecer explícitamente el control de cargan de las propiedades de control de acceso durante la página de un control más granular. Para ello, puede llamar al método IsInRole expuesto por ­ de afirmaciones de identidades. Puede tener acceso al principal actual a través de la propiedad Thread.CurrentPrincipal estática como sigue:

if (!Thread.CurrentPrincipal.IsInRole("Administrators"))
  throw new SecurityException("Access is denied.");

Además de comprobaciones explícitas de IsInRole en tiempo de ejecución, también puede escribir las peticiones de clásico de permisos basada en funciones mediante el objeto principal ­ tipo de permiso. Inicialice el tipo con la notificación de función requerida (el segundo parámetro constructor) y, cuando se llama a la demanda, se llama al método IsInRole de la entidad de seguridad actual. Se arroja una excepción si no se encuentra la notificación:

PrincipalPermission p = 
  new PrincipalPermission("", "Administrators");
p.Demand();

Este método es útil para rechazar una solicitud con una excepción, cuando las funciones necesarias no están presentes.

También es útil centralizar las comprobaciones de autorización comunes a todos los recursos solicitados. A veces, si tiene una directiva de control de acceso, por ejemplo, las reglas que se almacenan en una base de datos, puede utilizar un componente central para leer las reglas para controlar el acceso a las características y funcionalidad. Para ello, WIF proporciona un componente de ClaimsAuthorizationManager que se puede ampliar. En mi artículo anterior, recuerde que puede configurar este tipo de componente personalizado en la sección de modelo de identidad:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <claimsAuthorizationManager 
      type="CustomClaimsAuthorizationManager"/>
  </service>
</microsoft.identityModel>

La figura 7 ilustra un ClaimsAuthorizationManager personalizada que comprueba la presencia de la solicitud de nombre y si el recurso solicitado está en el directorio AdminsOnly requiere la notificación de la función Administradores.

Figura 7 Implementación personalizada de ClaimsAuthorizationManager

public class CustomClaimsAuthorizationManager: 
  ClaimsAuthorizationManager {

  public CustomClaimsAuthorizationManager()
  { }

  public override bool CheckAccess(
    AuthorizationContext context) {

    ClaimsIdentity claimsIdentity = 
      context.Principal.Identity as ClaimsIdentity;
    if (claimsIdentity.Claims.Where(
      x => x.ClaimType == ClaimTypes.Name).Count() <= 0)
      throw new SecurityException("Access is denied.");
        
    IEnumerable<Claim> resourceClaims = 
      context.Resource.Where(x=>x.ClaimType==ClaimTypes.Name);
    if (resourceClaims.Count() > 0) {
      foreach (Claim c in resourceClaims) {
        if (c.Value.Contains("\AdminOnly") && 
          !context.Principal.IsInRole("Administrators"))
          throw new SecurityException("Access is denied.");
      }
    }

    return true;
  }
}

El CustomClaimsAuthorizationManager reemplaza ­ de comprobación de acceso para proporcionar esta funcionalidad. Este método proporciona un parámetro de AuthorizationContext, que proporciona información acerca de la acción de petición (para la federación pasiva es un verbo HTTP como, por ejemplo, GET o POST), el recurso solicitado (URI) y el de afirmaciones ­ principal, que aún no está asociada al subproceso de solicitud.

Transformación de solicitudes

A menudo, las solicitudes emitidas por el STS de IP, aunque es útil para describir el usuario autenticado, no son relevantes para los requisitos de autorización de punto de reunión. No es trabajo del Juniper en el de saber qué tipo de funciones, permisos o de otro tipo de personalización avanzada que es necesario para la autorización en cada punto de reunión. Trabajo del Juniper en el consiste en conceder las solicitudes que son relevantes para el dominio del proveedor de identidades, que se puede afirmar el Juniper acerca del usuario autenticado.

Por tanto, el punto de reunión que necesite transformar las reclamaciones de STS de IP en algo más relevantes para la autorización. Esto implica que el punto de reunión puede asignar la identidad de usuario (quizás por nombre de usuario o el UPN) para un conjunto de solicitudes de punto de reunión. Suponiendo que las solicitudes de funciones de STS de IP subvenciones predeterminado, de figura 8 listas un conjunto posible del permiso se dice que no se puede emitir el punto de reunión basada en cada solicitud entrante de función. El tipo de solicitud de permiso puede ser un tipo de solicitud personalizados definido por el punto de reunión, como:

urn:ClaimsAwareWebSite/2010/01/claims/permission

Un buen lugar para transformar las solicitudes entrantes de STS de IP es un ClaimsAuthenticationManager personalizado. Puede instalar un ClaimsAuthenticationManager personalizado agregando lo siguiente a la sección microsoft.identityModel:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <claimsAuthenticationManager 
      type="CustomClaimsAuthenticationManager"/>
  </service>
</microsoft.identityModel>

La figura 9, se muestra un ejemplo CustomClaimsAuthenticationManager que transforma los concedidos por el STS de IP en las solicitudes de permiso correspondientes al punto de reunión entrantes reclamaciones de función.

La figura 8 de transformación de la función exige a las de afirmaciones de permisos en el punto de reunión

Función de notificación	Permiso de afirmaciones
Administradores	Crear, leer, actualizar, eliminar
Usuarios	Crear, leer, actualizar
Guest	Lectura

La figura 9 de transformación de afirmaciones personalizada en el punto de reunión

public class CustomClaimsAuthenticationManager: 
  ClaimsAuthenticationManager {

  public CustomClaimsAuthenticationManager() { }

  public override IClaimsPrincipal Authenticate(
    string resourceName, IClaimsPrincipal incomingPrincipal) {

    IClaimsPrincipal cp = incomingPrincipal;
    ClaimsIdentityCollection claimsIds = 
      new ClaimsIdentityCollection();

    if (incomingPrincipal != null && 
      incomingPrincipal.Identity.IsAuthenticated == true) {

      ClaimsIdentity newClaimsId = new ClaimsIdentity(
        "CustomClaimsAuthenticationManager", ClaimTypes.Name, 
        "urn:ClaimsAwareWebSite/2010/01/claims/permission");

      ClaimsIdentity claimsId = 
        incomingPrincipal.Identity as ClaimsIdentity;
      foreach (Claim c in claimsId.Claims)
        newClaimsId.Claims.Add(new Claim(
          c.ClaimType, c.Value, c.ValueType, 
          "CustomClaimsAuthenticationManager", c.Issuer));

      if (incomingPrincipal.IsInRole("Administrators")) {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Create"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Update"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Delete"));
      }

      else if (incomingPrincipal.IsInRole("Users")) {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Create"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Update"));
      }

      else {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
      }

      claimsIds.Add(newClaimsId);
      cp = new ClaimsPrincipal(claimsIds);
    }

    return cp;
  }
}

IsInRole controles (como se describió anteriormente) para que funcione, debe proporcionar el tipo de solicitud de permiso como tipo de Reclamación de la función. En del 9 de la figura, se especifica al construir la ClaimsIdentity debido a que el punto de reunión está creando el ClaimsIdentity.

En el caso donde tokens SAML de entrada son el origen de las solicitudes, se puede proporcionar el tipo de función de las solicitudes a la SecurityTokenHandler. A continuación, ilustra cómo configurar el Saml11SecurityTokenHandler para utilizar el tipo de solicitud de permiso, como la función del tipo de reclamaciones de mediante declaración:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <securityTokenHandlers>
      <remove type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
        <samlSecurityTokenRequirement >
          <roleClaimType 
            value= "urn:ClaimsAwareWebSite/2010/01/claims/permission"/>
        </samlSecurityTokenRequirement>
      </add>
    </securityTokenHandlers>
  </service>
</microsoft.identityModel>

Los controladores de tokens SAML tienen una sección samlSecurityTokenRequirement donde se puede proporcionar un valor para el nombre y tipo, junto con otras opciones relacionadas con la validación de certificados y los símbolos (tokens) de Windows de reclamaciones de función.

Detección del territorio principal

Hasta ahora, me he centrado en un escenario sencillo de federación con un STS de IP única. La suposición es que siempre se redirigirá el punto de reunión un STS de IP específico para autenticar a los usuarios.

En el mundo de la federación, sin embargo, el punto de reunión puede confiar en varios de los emisores de símbolo (token) de varios dominios. Un nuevo desafío presenta en este caso porque el punto de reunión debe decidir qué STS de IP deben autenticar los usuarios que solicitan el acceso a los recursos. El dominio en el que se autentican a los usuarios se conoce como territorio principal de usuario y, por tanto, este proceso se denomina detección del territorio principal.

Hay una serie de mecanismos de que una aplicación puede utilizar para la detección del territorio principal:

• Puesto que en el ejemplo actual, se conoce el dominio principal en siempre redirige las solicitudes avanzadas y así a un determinado STS de IP.
• Los usuarios puedan examinar al punto de reunión desde otro portal, que puede proporcionar una cadena de consulta para indicar el dominio principal para los usuarios de ese portal.
• El punto de reunión puede requerir que terrenos de los usuarios en una página de entrada en particular para cada dominio de origen. La página de inicio no puede suponer un territorio de origen determinado.
• El punto de reunión puede ser capaz de determinar el ámbito principal por la dirección IP de la solicitud o algún otro método heurístico.
• Si el punto de reunión no puede determinar el dominio principal de una de las técnicas mencionadas anteriormente, puede presentar una interfaz de usuario, donde el usuario puede seleccionar el dominio principal o proporcionan información que ayuda a que el punto de reunión tomar esta decisión.
• Si el punto de reunión es compatible con las tarjetas de información, la tarjeta seleccionada puede controlar la autenticación para el territorio principal apropiado con la federación de active.
• WS-Federation describe brevemente cómo la uno podría implementar un servicio de detección para resolver el dominio principal, pero existe no una especificación bien definida para este.

Independientemente de cómo se detecta el dominio principal, el objetivo es redirigir al usuario para autenticar con el STS de IP correcto. Hay algunos escenarios posibles. En un escenario, el punto de reunión que necesite establecer dinámicamente el identificador URI del emisor para que se envía la solicitud de inicio de sesión para el STS de IP correcto. En este caso, el punto de reunión debe enumerar todos los confianza-STS de IP en la sección trustedIssuers, por ejemplo:

<trustedIssuers>
  <add thumbprint="6b887123330ae8d26c3e2ea3bb7a489fd609a076" 
    name="IP1" />
  <add thumbprint="d5bf17e2bf84cf2b35a86ea967ebab838d3d0747" 
    name="IP2" />
</trustedIssuers>

Además, puede reemplazar el evento RedirectingToIdentityProvider expuesto por la FAM y, mediante técnicas heurísticas relevantes, determinar el URI correcto para el STS. Para ello, coloque el código siguiente en la implementación de global.asax:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(
  object sender, RedirectingToIdentityProviderEventArgs e) {
  if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP1RealmEntry.aspx")) {
    e.SignInRequestMessage.BaseUri = 
      new Uri("https://localhost/IP1/STS/Default.aspx");
  }
  else if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP2RealmEntry.aspx")) {
    e.SignInRequestMessage.BaseUri = new Uri(
       "https://localhost/IP2/STS/Default.aspx");
  }
}

El otro escenario implica pasar el parámetro de dominio principal (whr) con la solicitud de inicio de sesión para el STS principal. Por ejemplo, el punto de reunión que un recurso STS (STS-R o punto de reunión de STS) responsable de la transformación de solicitudes. El punto de reunión de STS no autenticar los usuarios (no es un Juniper), pero tiene relaciones de confianza con uno o más IdPs.

El punto de reunión tiene una relación de confianza con el punto de reunión de STS y siempre respeta los tokens emitidos por el punto de reunión de STS. El punto de reunión de STS es responsable de la redirección a la correcta Juniper para cada solicitud. El punto de reunión de STS puede determinar el STS de IP correcto para redirigir a como se muestra en el código que acabo de describir, pero la otra opción es para que el punto de reunión proporcionar información sobre el dominio principal, esto pasando el parámetro de dominio principal para el punto de reunión de STS. En este caso, el punto de reunión dinámicamente establece el parámetro de dominio principal:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(
  object sender, RedirectingToIdentityProviderEventArgs e) {
  if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP1RealmEntry.aspx")) {
    e.SignInRequestMessage.HomeRealm = 
      "https://localhost/IP1/STS/Default.aspx";
  }
  else if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP2RealmEntry.aspx")) {
    e.SignInRequestMessage.HomeRealm = 
      "https://localhost/IP2/STS/Default.aspx";
  }
}

El punto de reunión de STS este parámetro se utiliza para redirigir el STS de IP correcto y posteriormente se transforma las reclamaciones de STS de IP en las solicitudes relevantes al punto de reunión.

Un único inicio de sesión y cierre de la sesión de Single

Inicio de sesión único y el único fin de sesión son partes importantes de la federación. Inicio de sesión único es una característica que permite a los usuarios autenticados tener acceso a varias aplicaciones de punto de reunión al autenticar una sola vez. Único fin de sesión, como indica, facilita el cierre de sesión desde todas las aplicaciones de punto de reunión y cualquier cadena de STS relevante con una única solicitud.

En una federación sencilla caso de esta manera muestra en de figura 1, el usuario se autentica en el STS de IP y se autoriza al punto de reunión basada en el símbolo (token) de seguridad emitido. POST-Authentication, el usuario tiene una cookie de sesión para el STS y otro para el punto de reunión. Ahora, si el usuario se desplaza a otro punto de reunión, será redirigida a el STS de IP para la autenticación, siempre y cuando ambas aplicaciones RP confía en el mismo STS de IP. Debido a que el usuario ya tiene una sesión con el STS de IP, el STS va a emitir un símbolo (token) para el segundo punto de reunión sin solicitar las credenciales. Ahora, el usuario tiene acceso para el segundo punto de reunión y tiene una cookie de sesión nuevo para el segundo punto de reunión.

Ya he descrito, WIF suministra el SAM para escribir la cookie de sesión para los usuarios autenticados. De forma predeterminada, se emite esta cookie de sesión para la dirección de la aplicación relativa para el dominio y su nombre de base es FedAuth. Debido a que las cookies de sesión federados pueden ser grandes, el símbolo (token) normalmente se divide en las cookies de dos (o más): FedAuth, FedAuth1 y así sucesivamente.

Si aloja varias aplicaciones en el mismo dominio, como parte del escenario de federación, el comportamiento predeterminado es que el explorador tiene un cookie FedAuth para cada punto de reunión (vea de figura 10). El explorador envía sólo las cookies asociadas con el dominio y la ruta de acceso para la solicitud.

La figura 10 de las cookies de sesión asociados con cada punto de reunión y el STS

Este comportamiento predeterminado es por lo general, bueno, pero a veces es necesario proporcionar un nombre único para cada cookie de sesión de cada aplicación, especialmente si está alojados en el mismo dominio. O varias aplicaciones en el mismo dominio pueden compartir una cookie de sesión, en cuyo caso se puede establecer la ruta de acceso de la cookie en “ / ”.

Si la cookie de sesión caduca, el explorador, quitará de la caché y se redirige al usuario una vez más para el STS para la autenticación. De forma independiente, si el token emitido asociado con la cookie de sesión ha caducado, WIF se redirigirá el STS para un nuevo token.

Cierre de sesión es más explícita, normalmente viene determinada por el usuario. Único fin de sesión es una característica opcional de la especificación de WS-Federation que sugiere al STS también debe notificar a otras aplicaciones de punto de reunión que ha emitido los símbolos de la solicitud de cierre de sesión. De este modo, la cookie de sesión se elimina para todas las aplicaciones que el usuario examinando durante la sesión de inicio de sesión única. En un escenario más complejo, donde intervienen varios STSs, el STS principal recibe la solicitud de cierre de sesión también debe notificar a otros STSs hacer lo mismo.

Con el fin de esta discusión, me centraré en lo que debe hacer en el punto de reunión para facilitar la federados simple de cierre de sesión. Puede colocar el control FederatedPassiveSignInStatus en cualquier página desde la que desea permitir inicio de sesión y cierre de sesión y en el control indicará automáticamente su estado. Una vez firmado de, el control muestra un vínculo, el botón o la imagen de cierre de sesión.

Al hacer clic en el control, controlará cerrar sesión de acuerdo con la propiedad SignOutAction, que se pueden actualizar, redirigir, RedirectToLoginPage o FederatedPassiveSignOut. Los tres primeros elimina la cookie de sesión para la aplicación, pero no se notifican a el STS de la solicitud de cierre de sesión. Cuando se selecciona la opción FederatedPassiveSignOut, el control llamará SignOut en WSFederationAuthenticationModule. Esto garantiza que las cookies de sesión federados se quitan de la aplicación. Además, se envía una solicitud de cierre de sesión para el STS:

GET https://localhost/IP1/STS?wa=wsignout1.0

Si no utiliza el control FederatedPassiveSignInStatus, se puede llamar directamente a WSFederationAuthenticationModule.SignOut para desencadenar una redirección a la STS con la solicitud de cierre de sesión.

Único fin de sesión implica que el usuario está firmado de todas las aplicaciones que ha iniciado sesión con su identidad federada. Si el STS es compatible con esto, debe mantener una lista de las aplicaciones de punto de reunión al usuario que inició la sesión durante su sesión y el problema que se solicita una solicitud de limpieza para cada punto de reunión federada de cierre de sesión:

GET https://localhost/ClaimsAwareWebSite?wa=wsignoutcleanup1.0

En escenarios más complejos, la misma solicitud de limpieza se debe enviar a cualquier otros STS implicada en la sesión federada.Para ello, el STS tiene que tener conocimiento previo de los URI de limpieza para cada punto de reunión y STS.Para admitir un único fin de sesión, el punto de reunión debe ser capaz de procesar estas solicitudes de limpieza.Tanto la FAM y el control FederatedPassiveSignInStatus admiten esto.Si está utilizando la FAM, la solicitud de limpieza se puede registrar en cualquier cadena URI en el punto de reunión y la FAM va a procesar la solicitud y limpiar las cookies de sesión.Si está utilizando el control FederatedPassiveSignInStatus, la solicitud de limpieza debe contabilizarse a una página que contiene el control.

De hecho, la especificación de WS-Federation no detallar cómo implementar el comportamiento de cierre de sesión y la limpieza único más allá de las cadenas de consulta recomendada y el flujo de comunicación.No es fácil de garantizar el único fin de sesión será eficaz a través de todos los socios de federación como resultado, pero si es propietario el entorno y desea lograr este objetivo, es posible que en realidad.

Michele Leroux Bustamante es arquitecto director en IDesign (idesign.net) y el arquitecto de director de seguridad en BiTKOO (bitkoo.com de ).(bitkoo.com). También es un director regional de Microsoft para San Diego y MVP de Microsoft para sistemas conectados. Visite su blog en dasblonde.net de .

Gracias al siguiente experto técnico para este artículo: Govind Ramanathan