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

Sección pública y sección privada en un sitio web con autenticación mediante ADFS

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

Para manejar partes de un sitio web como una zona pública y otra para usuario autenticados es que podemos usar el tag location en el web.config, de la misma manera que se hace sin ADFS.

<location path="Styles">
    <system.web>
        <authorization>
            <allow users="*" />
        </authorization>
    </system.web>
</location>
<location path="Scripts">
    <system.web>
        <authorization>
            <allow users="*" />
        </authorization>
    </system.web>
</location>
<location path="Default.aspx">
    <system.web>
        <authorization>
            <allow users="*" />
        </authorization>
    </system.web>
</location>

mientras que el default sigue siendo:

<system.web>
    <authorization>
        <deny users="?" />
    </authorization>
    <authentication mode="None" />
</system.web>

Seguir leyendo otros artículos de la serie

Pasos para delegar la autenticación de mi sitio web a ADFS

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

El siguiente artículo trata de sitios web desarrollados con ASP.NET (WebForms, MVC, etc)

Pre-requisitos:

• Disponer de una instancia de ADFS donde delegar la autenticación.
• Tener instalado WIF SDK en el ambiente de desarrollo.

Pasos:

1. Abrir nuestro proyecto web en Visual Studio.
2. Sobre el proyecto, hacemos clic derecho y elegimos la opción: “Add STS reference” que tendremos disponible si hemos instalado WIF SDK. Esto nos abre la pantalla de Federation Utility donde debemos completar los datos de la aplicación:
3. En el siguiente paso, elegimos la opción “Use an existing STS” e indicamos la url de la FederationMetadata de dicho ADFS.
4. El resto de los valores los aceptamos por defecto.

Cambios realizados

Esto va a haber realizado varios cambios en nuestra aplicación, cambios que si no tenemos instalado WIF SDK los tendríamos que hacer manualmente. Ahora vamos a analizar dichos cambios.

• Agregó un archivo FederationMetadata.xml con la información necesaria para agregar el Relying Party en ADFS con un simple Import y sin necesidad de configurarlo manualmente.
• Agregó, en el web.config, varias líneas, y quizás modificó otras, principalmente:
  • agregó la sección: microsoft.identityModel con toda la configuración referente WIF.
  • denegó el ingreso para personas no autenticadas: <authorization><deny users="?" /></authorization>
  • configuró el modo de autenticación en none: <authentication mode="None" />
  • Agregó 2 HttpModules: WSFederationAuthenticationModule y SessionAuthenticationModule. Nota: si ejecutás en IIS 7 y tenés un error 500, probá de quitar los httpModules definidos en system.web.

Deploy, problemas comunes y posibles soluciones

Ahora estamos en condiciones de hacer el deploy de nuestra aplicación a un IIS, esto es necesario para manejar los certificados, puede ser un IIS local o en un servidor, en mi caso va a ser en el servidor ya que no tengo un IIS local en la máquina de desarrollo.

Si accedemos al sitio en este momento y no teníamos la misma configurada con https (SSL)probablemente tengamos el siguiente error: “ID1059: Cannot authenticate the user because the URL scheme is not https and requireSsl is set to true in the configuration, therefore the authentication cookie will not be sent. Change the URL scheme to https or set requireSsl to false on the cookieHandler element in configuration.”. Para esto, lo mejor va a ser utilizar https y así también subir el nivel de seguridad de nuestra aplicación por lo que, en nuestro ambiente de desarrollo, creamos un certificado firmado por nosotros mismos y configuramos el Binding del IIS en https con el certificado que acabamos de crear.

Si ahora accedemos al sitio, probablemente nos pida autenticarnos y luego nos de un error, esto se debe a que aun no configuramos la aplicación en ADFS. Esto lo podemos confirmar abriendo el EventViewer del servidor donde está instalado ADFS y, en la rama de ADFS/Admin vamos a encontrar un error que dice algo de: “MSIS7007: The requested relying party trust 'https://aplicacionweb.neluz.int/' is unspecified or unsupported”. Para agregar la aplicación a ADFS abrimos la consola de administración de ADFS y en “Trust Relationships” / “Relying Party Trust” vamos a “Add Relying Party Trust…” y seleccionamos la FederationMetadata.xml que habíamos creado con “Federation Utility”

Luego de completar el wizard vamos a “Edit Claims Rules” donde creamos, al menos una regla como la siguiente:

Guardamos y volvemos a ingresar a nuestro sitio.

Ahora podemos obtener un mensaje como: “A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...").”. Si esto ocurre debemos agregar en nuestro web.config el siguiente tag “<httpRuntime requestValidationMode="2.0"/>” dentro de “<system.web>”.

Ahora si nuestra aplicación debería autenticar con ADFS.

En mi caso, la aplicación es muy simple y, en Default.aspx tiene una línea que dice:

<%= HttpContext.Current.Request.IsAuthenticated ? HttpContext.Current.User.Identity.Name : "El usuario no está autenticado" %>

por lo que al ingresar al sitio primero me pide que me autentique y luego se ve como la siguiente imagen:

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/

Retrospectiva de mi primer año (y unos meses) como desarrollar freelance)

Antes de comenzar a enumerar aspectos que me gustaría mantener y aspectos que quisiera mejorar, quiero destacar que este año fue muy positivo profesionalmente para mi. Aunque también debo admitir que varias veces sentí el vértigo de ir muy rápido, de estar aprendiendo en el momento de estar aplicando el conocimiento.

Para mantener

• Involucrarme en la comunidad alt.net hispano.
• Trabajar con @carlospeix (http://carlospeix.com).
• Incremento de temas aprendidos.
• Poder dedicarle el tiempo a eventos de formación profesional.
• Disponer de tiempo libre para otras actividades no relacionadas con lo laboral.
• Cumplir con los plazos propuestos.
• Aprender de casi todos los proyecto en los que participé.
• Haber logrado no disminuir los ingresos de cuando trabajaba en relación de dependencia (con una gran ganancia de tiempo).
• Pagar todos mis impuestos y tributos.
• Virtualizar entornos de trabajo (con Linux como SO host).
• Mantener los socios/clientes con los que he trabajado.

Para mejorar

• Continuidad en las publicaciones en el blog.
• Aumentar la interacción con los integrantes de los equipos de trabajo que participo.
• Disminuir mi tendencia a abarcar demasiados roles en el proceso de desarrollo, lo que pienso que baja la calidad del producto.
• No sentirme un nabo por pagar todos mis impuestos y tributos.
• Imagen sobredimencionada acerca de mi en algunos colegas.
• Manejo comercial de algunas situaciones que así lo requieren, no solo ver la parte técnica.
• Mejorar el manejo del tiempo que dedico a la investigación.

 

Vamos por otro año!