Cambios en el acceso a mi sitio web al implementar Autenticación y Autorización por ADFS

Este post es parte de una serie de artículos complementarios a la VAN sobre Identity Providers.

Escenario

A continuación veremos el flujo de request que ocurren en el browser cuando ingresamos a nuestro sitio web después de implementar la seguridad con ADFS, pero antes voy a hacer un cuadro con los actores que intervienen en este ejemplo.

Actores

testigoadfs.neluz.int	Es nuestra aplicación web, en la cual queremos delegar la autenticación y autorización a ADFS.
testigomvc.neluz.int	Es otra aplicación que utiliza ADFS, en este caso para ejemplificar el single sign on.
adfs.neluz.int	Es el sitio web de ADFS, que cumple el rol de emisor de confianza (Issuer).
starter-sts.neluz.int	Es el Identity Provider, encargado de autenticar al usuario mediante credenciales (usuario y password).

 

Flujo del primer ingreso

De nuestro sitio web a la pantalla de login

Cuando ingresamos al sitio web testigoadfs.neluz.int sucede lo siguiente:

El HttpModule de WIF redirecciona a adfs.neluz.int (Issuer) ya que no encuentra la información emitida por ADFS que autorice el ingreso al sitio. Este, a su vez redirecciona a issue.aspx de starter-sts.neluz.int (el IP-STS) ya que no encuentra información de autenticación. Issue.aspx no tiene información de que el usuario esté autenticado (Single Sign On) por lo que redirecciona a login.aspx dentro de starter-sts para que el usuario ingrese su username y password.

De la pantalla de login a nuestro sitio web

Luego de ingresar las credenciales correctamente, sucede lo siguiente:

Hacemos un post en login.aspx de starter-sts el cual valida el usuario y password ingresados y, como en este caso son válidos, redirecciona a issue.aspx, es decir que empieza a “desandar” el camino. Luego issue.aspx emite la información correspondiente a la autenticación para ADFS y hace un POST a este donde se genera la información de autorización para el módulo de WIF en nuestra aplicación que la recibe en el POST de nuestro sitio y ahora si podemos ingresar (es decir que el httpModule de WIF nos deja pasar).

Flujo visto como un diagrama de secuencia

Navegando a otra página dentro del mismo sitio

Cuando intentamos acceder a otra página de nuestro sitio web vemos lo siguiente

Vemos que no ocurre nada de los anterior, porque el HttpModule de WIF encuentra la información correspondiente a la autorización emitida por ADFS y directamente nos deja pasar.

Contenido del mensaje emitido por ADFS

Segunda aplicación (SSO)

Cuando ingresamos a otra aplicación que delega la autenticación y autorización a ADFS vemos lo siguiente:

Como podemos observar se repite el camino casi como el primer ingreso, es decir, WIF no encuentra la información de autorización para ingresar a la aplicación y redirecciona a adfs.neluz.int, este a issue.aspx de starter-sts pero, a diferencia del primer ingreso, este si encuentra que el usuario está autenticado por lo que directamente emite la información de autenticación necesaria para ADFS. Ahora si ADFS encuentra la información y realiza la autorización para ingresar a la aplicación, finalmente WIF nos deja pasar. En este caso no tuvo que intervenir el usuario, a lo sumo notó algún cambio en las url del browser.

Flujo visto como un diagrama de secuencia

Seguir leyendo otros artículos de la serie

Manejando Roles por aplicación mediante ADFS

Este post es parte de una serie de artículos complementarios a la VAN sobre Identity Providers.

Escenario

Comúnmente, en asp.net, utilizamos la siguiente sintaxis para preguntar si una persona tiene asignado un determinado rol:

HttpContext.Current.User.IsInRole("Administrators")

o, en MVC, con el atributo:

[Authorize(Roles = "Administrators")]

Configurando ADFS

Con ADFS hacemos lo mismo. El tema está en configurar correctamente el issuer (ADFS) para que emita los claims correspondientes, para esto debemos configurar una “Claim Rule” que genere tantos claims con el Type “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name” como roles tenga la persona en la aplicación, en el Value de cada uno de estos claims irá el nombre de cada rol.

Ejemplo de Claim Rule

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]
=> issue(store = "AttributeStore", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "SELECT Role FROM Roles WHERE UserName = {0} AND RelyingParty = {1}", param = c.Value, param = "https://aplicacionweb.neluz.int/");

Con la siguiente Claim Rule estamos haciendo un select sobre una tabla llamada Roles donde tenemos un registro por cada Rol (Role) que tiene asignado el usuario (UserName) en la aplicación a la que está queriendo ingresar (RelyintParty), todo esto sobre la base de datos configurada en AttributeStore.

Nota: una ventaja que nos da ADFS en este esquema es que los roles son por Usuario y por Aplicación, por sobre el caso de usar los grupos de AD donde los roles son solo por Usuario.

Seguir leyendo otros artículos de la serie

Controlando el acceso a mi sitio web con autorizaciones mediante ADFS

Este post es parte de una serie de artículos complementarios a la VAN sobre Identity Providers.

Escenario

Para decidir cual usuario ingresa y cual no a una aplicación debemos configurarlo en ADFS, es decir que si el usuario no tiene autorización para ingresar a la aplicación, ADFS nunca va a redireccionar nuevamente al sitio que lo invocó.

Configurando ADFS

Lo que debemos configurar se llama “Issuance Authorization Rule” y lo encontramos entre las “Claims Rule” en la consola de ADFS. debemos crear una que emita un token de cuyo type debe ser: “http://schemas.microsoft.com/authorization/claims/permit” y, en caso de que tenga el acceso permitido, el valor de dicho claim debe ser “true”.

Ejemplo de Authorization Rule

  

Si vemos un caso donde se permita la entrada a todos los usuarios (el valor por defecto), veremos que se trata de una rule como la siguiente:

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

mientras que si controlamos el acceso, vamos a tener algo mas parecido a:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]
=> issue(store = "AttributeStore", types = ("http://schemas.microsoft.com/authorization/claims/permit"), query = "EXEC sp_Is_Allow_Access {0}, {1}", param = c.Value, param = "https://testigomvc.neluz.int/");

en este caso estamos invocando al stored procedure “sp_Is_Allow_Access” mediante la conexión configurada en “AttributeStore” con el nombre del usuario autenticado (c.value) y con el identificador de la aplicación en cuestión: “https://testigomvc.neluz.int/” como parámetros. Si este stored procedure devuelve un registro con el valor “true” entonces se permitirá el acceso, en caso contrario se denegará.

De esta manera y sin cambiar nada en nuestra aplicación controlamos quien puede ingresar y quien no.

Seguir leyendo otros artículos de la serie

Login y Logout explícitos en un sitio web con ADFS

Este post es parte de una serie de artículos complementarios a la VAN sobre Identity Providers.

Escenario

Hay veces que podemos querer que manejar el login y logout del usuario independientemente de la página que esté navegando, es decir que una misma página se comporta de una manera si el usuario está autenticado y de otra cuando no lo está, pero la página es la misma.

El ejemplo que vamos a ver es en una aplicación MVC, por lo que a continuación veremos las acciones de Login y Logout, pero fácilmente se podría adaptar a otros escenarios con asp.net.

Actions

public void Logout()
{
    WSFederationAuthenticationModule authModule = FederatedAuthentication.WSFederationAuthenticationModule;
    string signoutUrl =
        (WSFederationAuthenticationModule.GetFederationPassiveSignOutUrl(authModule.Issuer, authModule.Realm, null));

    WSFederationAuthenticationModule.FederatedSignOut(new Uri(signoutUrl),
                                                      new Uri(authModule.Realm));
}

public ActionResult Login()
{
    WSFederationAuthenticationModule authModule = FederatedAuthentication.WSFederationAuthenticationModule;
    var signinUrl = authModule.CreateSignInRequest("passive", authModule.Realm, false);
    return Redirect(signinUrl.RequestUrl);
}

Breve explicación

Para hacer en forma explícita el login y logout tenemos que redireccionar a otro sitio web (con ciertos parámetros en la url), justamente al sitio de ADFS y una buena forma de determinar la url completa a la que redireccionar es usas los servicios que nos provee WIF para tal fin, estos servicios armarán la url según la configuración en la sección microsoft.IdentityModel.

Un detalle aquí es que debemos permitir el acceso a usuarios no autenticados a nuestro sitio, es decir, debemos modificar la configuración por defecto que crea Federation Utility respecto a:

<authorization>
    <allow users="*"/>
</authorization>

De esta forma, el login y logout del sitio no queda atado a las páginas sino a la intención manifiesta del usuario.

Seguir leyendo otros artículos de la serie

Identity Providers

El Sábado 18 de junio del 2011, junto a @carlospeix, estuvimos como presentadores en una VAN sobre delegación de Autenticación y Autorización en aplicaciones web en la comunidad altnet hispano.

En la primer parte, Carlos habló sobre autenticación con Identity Providers públicos como twitter, facebook y OpenID y sobre el acceso a recursos en dichos servicios como la lista de contactos de GMail. También revisó el protocolo OAuth 1.0a.

En la segunda parte yo mostré ejemplos de otro escenario, el de Identity Providers privados o empresariales como una suerte de continuación de los temas tratados en la VAN sobre ADFS y WIF que presentaron Eugenio Pace y Carlos Peix el 18 de Septiembre del 2010.

En la presentación nos quedamos cortos de tiempo, por lo que escribí esta serie de artículos como complemento, con temas que quedaron fuera de la presentación o que pasamos muy rápido en la misma. Si no tienen conocimientos de ADFS es recomendable que vean las grabaciones de dichos eventos como base para esta serie.

Artículos de la serie:

• Pasos para delegar la autenticación de mi sitio web a ADFS.
• Sección pública y sección privada en un sitio web con autenticación mediante ADFS.
• Login y Logout (explícitos) en un sitio web con ADFS.
• Controlando el acceso a mi sitio web con autorizaciones mediante ADFS.
• Manejando Roles por aplicación mediante ADFS.
• Cambios en el acceso a mi sitio web al implementar Autenticación y Autorización por ADFS.

Otros recursos online

Adfs content map: http://social.technet.microsoft.com/wiki/contents/articles/2735.aspx

Starter STS: http://startersts.codeplex.com/ este es el IP-STS usado en la presentación y en estos ejemplos, contiene una serie de muy buenos videos de como implementarlo.

WIF: www.microsoft.com/wif y http://msdn.microsoft.com/en-us/security/aa570351

WIF - White paper for developers: http://download.microsoft.com/download/7/D/0/7D0B5166-6A8A-418A-ADDD-95EE9B046994/WindowsIdentityFoundationWhitepaperForDevelopers-RTW.pdf

Claims–based Identity and Access Control: http://msdn.microsoft.com/en-us/library/ff423674.aspx

Implementando OAuth en:
Google: http://code.google.com/intl/es-419/apis/accounts/docs/OAuth2.html
Facebook: http://developers.facebook.com/docs/authentication/
Twitter: http://dev.twitter.com/
LinkedIn: http://developer.linkedin.com/docs/DOC-1008

OpenID Foundation website: http://openid.net/
OAuth Community Site: http://oauth.net/ y http://hueniverse.com/oauth/

Implementaciones de OAuth: http://www.dotnetopenauth.net/ y http://code.google.com/p/socialauth-net/