Identity & .NET 4.5 - V

En la anterior entrada hablamos sobre las nuevas herramientas de la plataforma de Identity disponibles para .NET 4.5 y como estas nuevas herramientas nos aportaban nuevas mejoras y funcionalidades. De la primera de esas funcionalidades que hablaremos es del Local STS.

Local STSv-1

Cuando decidimos desarrollar un proyecto y delegar la gestión de la identidad a un tercero, en nuestra terminología a un Security Token Service, siempre tenemos la posibilidad de que esa pieza no esté disponible o quizás que no tengamos acceso a la misma. Por ejemplo, si vamos a desplegar el producto en una organización, es casi seguro que la misma disponga de un ADFS sobre el que podamos trabajar, sin embargo, en tiempo de desarrollo probablemente no lo podamos ni tocar. Conscientes de esto, el equipo de Identity, pone a nuestra disposición la posibilidad de que desarrollemos una RP usando un STS local o simulado, que nos permita trabajar como si de un ADFS ( u otro bussiness STS ) se tratara.

Con el fin de mostrar un ejemplo de esto crearemos un nuevo proyecto de MVC 4 en nuestro Visual Studio 2012 al que configuraremos con las herramientas de Identity, vistas en la entrada anterior. Si se fija en la figura 1, en las distintas ‘tabs’ que tenemos en la ventana podemos seleccionar la dedicada a configurar como funcionará nuestro Local STS, desde el protocolo por defecto SAML 1.1 o SAML 2.0 hasta el puerto de nuestro Local STS en la máquina.

Por supuesto a mayores de esto, también podemos configurar las claims que serán devueltas por cualquier petición de un token, WS-Trust, para  cualquier usuario. Esta información de claims es guardada a nivel de proyecto en un archivo llamado LocalSTS.exe.config que contendría algo similar a lo siguiente:

 

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="localSTSConfiguration" type="System.IdentityModel.Tools.LocalSTS.LocalSTSConfiguration, LocalSTS, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  </configSections>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
  <localSTSConfiguration port="13855" signingCertificate="LocalSTS.pfx" signingCertificatePassword="LocalSTS" issuerName="LocalSTS" tokenFormat="Saml11">
    <claims>
      <add type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" displayName="Name" value="Terry" />
      <add type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" displayName="Surname" value="Adams" />
      <add type="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" displayName="Role" value="developer" />
    </claims>
  </localSTSConfiguration>
</configuration>

 

Seguramente, si está desarrollando una solución empresarial, dentro de los distintos escenarios que tendrá, existirán aquellos en los que haga una validación de las claims para algún mecanismo de authorización. Para hacer más agil esto a los desarrolladores, en vez de modificar a mano este archivo para dar soporte a distintos perfiles sería conveniente realizar algún script de power shell que nos facilitara la vida. [Es probable que esto sea una de esas miles de cosas que uno tiene como propósito para hacer en vacaciones]

Una vez que hemos terminado de configurar nuestro Local STS podemos ver como la configuración de nuestro proyecto MVC ha cambiado, para verlo nos iremos a nuestro web.config y observaremos los siguientes elementos.

 

  • Nuevas secciones de configuración: Lo primero que hace es agregarnos las secciones de configuración relativas a System.IdentityModel.

 

<section name="system.identityModel"
         type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"
 />
section name="system.identityModel.services"
        type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" 
/>

 

 

<system.webServer>
  <validation validateIntegratedModeConfiguration="false" />
  <modules>
    <add name="WSFederationAuthenticationModule" 
         type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
     />
    <add name="SessionAuthenticationModule"
         type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
     />
  </modules>
</system.webServer>
<system.identityModel>
  <identityConfiguration>
    <audienceUris>
      <add value="http://localhost:1073/" />
    </audienceUris>
    <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <trustedIssuers>
        <add thumbprint="9B74CB2F320F7AAFC156E1252270B1DC01EF40D0" name="LocalSTS" />
      </trustedIssuers>
    </issuerNameRegistry>
    <certificateValidation certificateValidationMode="None" />
  </identityConfiguration>
</system.identityModel>
<system.identityModel.services>
  <federationConfiguration>
    <cookieHandler requireSsl="false" />
    <wsFederation passiveRedirectEnabled="true" issuer="http://localhost:13855/wsFederationSTS/Issue" realm="http://localhost:1073/" reply="http://localhost:1073/" requireHttps="false" />
  </federationConfiguration>
</system.identityModel.services>

 

Bien, ahora que ya tenemos todo configurado, sin más, podemos iniciar nuestro proyecto y observar las claims del usuario authenticado, para ellov-2 podemos poner el siguiente código en Home/Index y observar el resultado.

 

var claims = ClaimsPrincipal.Current.Claims;

 

Más configuración…

 

Si se fija en la configuración, hay más elementos que podemos configurar, el valor del issuer, la audiencia, la redirección pasiva o si queremos https y cookies validas para una web farm. Por suerte, estos valores no tenemos que tocarlos en nuestro XML directamente sino que támbién son modifcables en la herramienta de gestión de la identidad en la pestaña de Configuración, tal y como podemos ver en la siguiente imagen.

 

v-3

 

 

Saludos

Unai

Published 1/8/2012 10:36 por Unai
Comparte este post:
http://geeks.ms/blogs/unai/archive/2012/08/01/identity-amp-net-4-5-v.aspx

Comentarios

# IdentityModel.Extensions

Estos últimos posts los he dedicado a un tema que muchos sabéis que me gusta, la seguridad de nuestras

Monday, October 1, 2012 11:07 PM por O bruxo mobile