Hola! Vamos con la segunda parte del artículo que había prometido.
De momento ADFS provee funcionalidad únicamente para aplicaciones web. Para poder autenticar aplicaciones web utilizando ADFS, la instalación nos provee de dos componentes muy importantes:
- El servicio de autenticación: Este servicio web se encargará de comrpobar los derechos del usuario actual y hacer el mapeo con los derechos que tengamos definidos en nuestro directorio activo. Es el servicio web al que se redirigen las peticiones cuando van acompañadas de una lista de derechos (claims). Es el servicio FederationServerService.asmx que podemos encontrar en la carpeta fs de la instalación.
- Dos Agentes Web de autenticación: Son dos HttpModule que proveen diferente funcionalidad. Hemos de escoger el que se ajuste más a nuestras necesidades, y deberemos incluirlo en nuestra aplicación para que procese la lista de derechos, de manera que cuando nosotros ejecutemos el código de nuestra aplicación, tengamos disponibles los datos de ADFS a través de la propiedad Identity del objeto User.
Los dos Agentes Web que provee ADFS son los siguientes:
Web Agent for Windows NT® Token-based Applications: Este agente crea una sesión de windows para que la aplicación web se pueda impersonar utilizando las credenciales de la sesión creada. Genera un login a partir del nombre de usuario utilizando las extensiones S4U de Kerberos. Las ventajas que nos provee este agente es que podemos utilizar las credenciales del login para pasárselas a diferentes sistemas que requieran autenticación integrada (como por ejemplo un sistema de archivos o SQL Server™). Eso sí, si los recursos son remotos, hemos de habilitar la transición de protocolos en el directorio activo.
Web Agent for Claims-Aware Applications: Este agente no intenta crear una nueva sesión. Lo «único» que hace es pasarnos la lista de derechos del usuario actual dentro del objeto HttpContext.User.
El problema que tiene el primer agente es que tenemos que crear una cuenta en el directorio activo local para cada usuario de los dominios en los que confiamos, con lo que perderemos las ventajas que comentábamos en el artículo anterior. La única ventaja es que los usuarios de los dominios «confiables» no conocen la clave de esta cuenta. De hecho, ni siquiera saben que esa cuenta existe. Pero tendremos que gestionar dichas cuentas, y llegaremos a la inevitable situación de tener usuarios que ya no son necesarios, o de no dar de alta usuarios nuevos de los dominios confiables.
Por lo tanto, la configuración que vamos a ver es la del agente que nos proporciona la lista de derechos (el segundo, vaya). En este escenario, nuestra aplicación impersonará un usuario genérico (el que nosotros le asignemos, o por defecto NetworkService). Por lo tanto, para dar acceso a los recursos, o para permitir realizar operaciones, tendremos que controlar el acceso explícitamente. Como un ejemplo vale más que mil palabras, vamos a ver cómo podemos acceder a la identidad del usuario actual en nuestra página web. Además, veremos como obtener el valor de un derecho en concreto:
string GetTitle() {SingleSignOnIdentity id = (SingleSignOnIdentity)User.Identity;
SecurityPropertyCollection c =
id.SecurityPropertyCollection.GetCustomProperties(«IdResponsable»);return (1 == c.Count) ? c[0].Value : string.Empty;
}
Si nuestra aplicación está basada en Roles, también podemos utilizar ADFS para comprobar si el usuario actual posee un derecho de grupo (group claim). Estos derechos de grupos se pueden consultar utilizando IsInRole, como los roles estándar.
Por último, cómo configurar la aplicación para que utilice ADFS. Un ejemplo de configuración sería el siguiente:
<configuration>
<!– Añadimos la sección necesaria para la configuración de Single Sign On de ADFS –><configSections>
<sectionGroup name=»system.web»>
<section name=»websso» type=
«System.Web.Security.SingleSignOn.WebSsoConfigurationHandler,
System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null»/>System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null»/></sectionGroup>
</configSections>
<system.web>
<!– No utilizamos ninguna de las técnicas estandar de autenticación de ASP.NET, usamos ADFS –><authentication mode=»None» />
<customErrors mode=»Off»/>
<sessionState mode=»Off» />
<!– Referencias a los assemblies de ADFS –><compilation debug=’true’ defaultLanguage=’c#’>
<assemblies>
<add assembly=»System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null»/>
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null»/><add assembly=»System.Web.Security.SingleSignOn.ClaimTransforms,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, Custom=null»/>
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, Custom=null»/></assemblies>
</compilation>
<!– Cargamos el módulo del agente web de ADFS –><httpModules>
<add name=»ADFS Web Agent» type=
«System.Web.Security.SingleSignOn.WebSsoAuthenticationModule,
System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null» />System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null» /></httpModules>
<!– Configuración del agente web de ADFS –><websso>
<authenticationrequired />
<eventloglevel>55</eventloglevel>
<auditsuccess>2</auditsuccess>
<urls>
<returnurl>https://localhost/miWeb/</returnurl>
</urls>
<cookies writecookies=»true»>
<path>/miWeb</path>
<lifetime>240</lifetime>
</cookies>
<!– Aquí le indicamos donde está instalado el servicio de ADFS –><fs>https://localhost/adfs/fs/federationserverservice.asmx</fs>
</websso>
</system.web>
<!– Configuramos las trazas para que sean lo más explícitas posible –><system.diagnostics>
<switches>
<add name=»WebSsoDebugLevel» value=»255″ />
</switches>
<trace autoflush=»true» indentsize=»3″>
<listeners>
<!– Para que funcione esto, hemos de crear un directorio C:logs, y hemos de dar permisos de escritura a la cuenta de sistema NetworkService –><add name=»MyListener»
type=»System.Web.Security.SingleSignOn.BoundedSizeLogFileTraceListener,
System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null»
System.Web.Security.SingleSignOn, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Custom=null»
initializeData=»c:logsAgenteADFS.log» />
</listeners>
</trace>
</system.diagnostics>
</configuration>