MARMITA. Arquitectura. Autenticación

De EduWiki
Saltar a: navegación, buscar

Justificación

Volver a MARMITA


Gran parte de las aplicaciones que se desarrollan necesitan que el usuario se identifique, es decir, que demuestre de algún modo que es quien dice ser; bien porque es necesario para acceder a determinados procesos restringidos o bien para personalizar la aplicación y ofrecerle los servicios adecuados.
Al tratarse de aplicaciones independientes entre sí, en principio cada una de ellas utilizaría su propio sistema de autenticación, lo cual implica inconvenientes al usuario cada vez más graves a medida que el número de sistemas que utiliza crece:

  • Debe recordar diferentes identificadores de usuario y contraseñas para diferentes sistemas,
  • Debe autenticarse en cada uno de ellos cada vez que desea usarlos.

Esta situación no solo es incómoda para los usuarios, sino que lleva a que estos realicen prácticas que comprometen la seguridad de nuestros sistemas, como son:

  • Uso de contraseñas poco seguras;
  • Anotación de las contraseñas en papel, en documentos de texto, etc.;
  • Reutilización de contraseñas en diferentes sistemas, lo cual en muchos casos no es posible y genera muchos más problemas.

Conceptos

  • Autenticación: consiste en un sistema para certificar que el usuario es quien dice ser; lo más común es utilizar una combinación de identificador de usuario único y contraseña, aunque existen otros. Un sistema de single-sign-on consiste, por tanto, en un protocolo de autenticación que funcione en más de un sistema.
  • Autorización: consiste en dar acceso a una serie de recursos a un usuario o sistema (para ello, el usuario o el sistema previamente tendrá que haberse autenticado). La autorización podemos dividirla en:
  1. La que se da a un usuario después de autenticarse en una determinada aplicación y que será gestionada por esa aplicación.
  2. La que un usuario proporciona sobre sus recursos en un determinado sistema para que un tercer sistema tenga acceso a ellos.


Soluciones tecnológicas

Para solucionar el problema de la autenticación hay muchas opciones. Se consideran tres.

Directorio común. LDAP

Una primera aproximación a la solución del problema es la utilización de un directorio común donde almacenar el login y la contraseña, como repositorio de información de usuarios. Con esto conseguimos que el usuario tenga el mismo login y la misma contraseña para todas las aplicaciones que lo utilicen. Sin embargo, no evita que cuando trabaje con aplicaciones de diferente tecnología deba volver a escribir el login y la contraseña.

Provisión del directorio LDAP

Las fuentes de origen de los datos son las siguientes:

  1. TIZA: Personal docente.
  2. PLUMIER: Personal docente de centros privados y concertados y personal de administración y alumnos.
  3. FUNCION PUBLICA: PAS y otro personal que presta servicios en Educación.
  4. TERCEROS: Personal diverso.

Problemas que presenta el LDAP

  1. No se dispone de un login y contraseña único, ya que cada origen tiene uno: CAT, correo electrónico, NIF, ...
  2. Cada acceso a cada aplicación implica introducir un login y contraseña. En si no es un problema, salvo en programas que utilizan distinta tecnología que es un inconveniente para usuarios con un login largo.


Single Sign On. CAS

Una segunda aproximación es utilizar un sistema que permita que las aplicaciones se identifique en un sitio común, al que todas pregunten y si el usuario ya está autenticado no sea necesario volver a pedir el login y la contraseña. Es lo que se llama un SSO, o Single Sign On.

El CAS es un servicio que permite la autenticación a usuarios de la Consejería.  

Es un procedimiento de autenticación que habilita a un usuario para acceder a distintas aplicaciones web (en distintos dominios y en distintos servidores) con hacer login una única vez.
En general, cuando un usuario se conecta a una de las aplicaciones integradas en el CAS, el sistema comprueba si está autenticado. Si no lo está, lo redirige a la pantalla del servidor de autenticación. Si la autenticación es correcta el sistema de autenticación, en este caso CAS, vuelve a redirigir al usuario a la página a la que quería acceder en un primer momento.
Para el desarrollo de aplicaciones supone que despreocuparse del mantenimiento de la seguridad y de disponer de un formulario de login en cada una de las aplicaciones web que se desarrollen, simplemente será necesario hacer la comprobación de si el usuario ya está registrado.


Ventajas.

  • Permite crear un sistema único de acceso, de forma que:
  • Evita a las aplicaciones tener que implementar un sistema de autenticación.
  • Permite modificar la autenticación de forma transparente, al enviarlo a un servidor externo.
  • Permite Single Sign On, es decir, que muchas aplicaciones diferentes incluso desarrolladas en lenguajes diferentes no tengan que volver a pedir login y contraseña para acceder.


Como funciona

Primera autenticación:

  • El cliente se presenta ante el servidor de CAS.
  • El servidor requiere usuario y contraseña.
  • Si todo va bien el servidor envía un ticket al cliente, al navegador, que lo almacena.
  • El ticket es opaco y no contiene información del usuario.

Acceso a un servicio autenticado:

  • La aplicación redirige al navegador al servidor CAS.
  • El navegador presenta su ticket.
  • El servidor CAS envía al navegador un ticket de servicio.
  • Se redirige el navegador a la aplicación.
  • La aplicación valida el ticket de servicio con CAS.
  • La aplicación permite acceso al navegador.





Autorización delegada. OAUTH

Una tercera aproximación es delegar la autenticación en alguien especializado en ello, y que te devuelva el usuario ya autenticado. Por ejemplo, algo similar a lo que se hace cuando un usuario se autentica con el certificado digital, o cuando una aplicación delega la autenticación en Google o en Facebook.

OAuth (Open Authorization) es un estándar abierto que permite delegar el acceso de autorización para sitios web o aplicaciones informáticas.

Este estándar está diseñado para trabajar específicamente sobre el protocolo HTTP, y esencialmente lo que hace es generar tokens de acceso a un cliente con la aprobación de dueño de los recursos.

Esta federación de autorización nos facilita, como usuarios, a no tener que crear y recordar cientos de nombres de usuario y contraseñas; y como desarrolladores, a poder acceder a los datos de un usuario y a establecer un esquema de autenticación en pocas líneas. También ofrece mayor seguridad y transparencia, al establecer los alcances específicos de la aplicación que estamos integrando.

Permite autorización segura de una API de modo estándar y simple para:

  • Aplicaciones de escritorio,
  • Aplicaciones móviles
  • Aplicaciones web.

En OAuth no hay contraseñas, estas se encuentran en el directorio LDAP


Como funciona

El protocolo es básicamente este:

  • El usuario dispone de una serie de recursos propios en un servidor (el “proveedor”).
  • Un servidor externo (el “consumidor”) desea acceder a un subconjunto de esos recursos.
  • El consumidor redirige al usuario hacia el proveedor.
  • El usuario se autentica en el proveedor (si no lo estaba previamente).
  • El proveedor pregunta al usuario si autoriza al consumidor a que utilice esos determinados recursos.
  • El usuario autoriza al consumidor a utilizar esos recursos.
  • El servidor externo (consumidor) consigue acceso a esos recursos.


Aclaraciones

  • OAuth no es exactamente un protocolo de autenticación de usuario, ya que no define ningún mecanismo explicito destinado a autenticar la identidad del usuario. Sin embargo, uno de los pasos de este protocolo de autorización es la autenticación del usuario final en el servidor proveedor de OAuth para poder dar autorización a otros a acceder a tus recursos, antes tienes que autenticar quien eres tú realmente.
  • OAuth se puede utilizar sin CAS, si bien el tener CAS facilita la gestión de usuarios y contraseñas.


Otras Organizaciones

  1. Servicio de Identidad de Rediris  Pulsar aqui. Se ha visto, analizado, pero no es objetivo nuestro por ahora crear una federación.
  1. Servicio de identidad de la Junta de Castilla La Mancha  JA-SIG Pulsar aqui. Integracion con Oauth, OpenId, SAML, Rest, SingleSignOut, ... Coincide en arquitectura con lo que se tiene en Educación. No coincide en configuración.
  1. Servicio de autenticación de ICM (Madrid). Pulsar aqui.  Utiliza spring-security. Posiblemente más complejo de configurar.

Situación actual


Los sistemas de autenticación permiten garantizar la identidad de una persona.

Se puede hacer a través de diversos mecanismos, como login y contraseña, certificado digital, sistema de claves, etc.

Algunas aplicaciones tienen uno o más de un sistema de autenticación para poder acceder.

Indicamos a continuación los que se tienen en la Consejería, y el tipo de usuarios que lo utiliza.


CAS. Servicio de Autenticación Centralizada

Se basa en JA-SIG No están todas las aplicaciones en el CAS.

Se dispone de dos CAS,

OAuth (Open Authentication), Autenticación abierta.

Se utiliza para las aplicaciones móviles

  • De profesores
  • De alumnos.

Se encuentra en proceso de pruebas.

LDAP

El directorio LDAP se basa en OpenLDAP. Tiene múltiples fuentes de orígenes de datos que confluyen en el directorio.

Se utiliza LDAP como repositorio de usuarios, aprovisionándose de las siguientes fuentes de datos:

  • TIZA: Personal docente.
  • PLUMIER: Personal docente de centros privados y concertados y personal de administración y alumnos.
  • FUNCION PUBLICA: PAS y otro personal que presta servicios en Educación.
  • TERCEROS: Personal diverso. (Directamente en LDAP).
  • Otros.


Problemas que presenta el LDAP:

  1. La gestión de los usuarios se realiza en el origen de los datos, lo que implica disponer de un sistema de sincronización con el inconveniente de que los cambios no son reflejados de forma inmediata en el LDAP.
  2. La enorme cantidad de información que se maneja hace que el sistema sea lento.
  3. Por el origen de los datos y las restricciones que imponen algunas aplicaciones, no se dispone de un identificador único para los usuarios, permitiendo que el mismo usuario aparezca más de una vez en el sistema con distintos login. Esto no tiene por qué ser un inconveniente, pues permite por ejemplo que el mismo usuario pueda ser tratado como docente y como personal de la Consejería, lo que ha de ser valorado positivamente en nuestro entorno.


Aplicaciones que integran su autenticación

Hay aplicaciones que pueden parametrizarse para que se autentiquen contra el directorio LDAP. Algunas de ellas son las siguientes:

  • Redmine
  • CLIP
  • Moodle


Base de datos

Autenticación contra usuarios de base de datos. Tienen las siguientes aplicaciones

  • Zona privada de EDUCARM. Se utiliza cuando el directorio LDAP falla.


Lotus Notes

Directorio de Lotus, no está sincronizado.

Los usuarios están en la propia plataforma de Lotus

Se utiliza para las aplicaciones desarrolladas en Lotus Notes


Lotus Less

Migración de aplicaciones de Lotus a Java

Utiliza el CAS para la autenticación.



Directorio Novell

Se utiliza para las aplicaciones existentes en Novell, fundamentalmente las aplicaciones desarrolladas en Delphi.

se validan con el UserName del equipo.

La autenticación se realiza en Novell, las contraseñas se sincronizan con el directorio LDAP. Son los siguientes:

  • Aplicaciones Delphi


Directorio activo de Microsoft

Se utiliza para aplicaciones que se encuentran bajo el entorno de aplicaciones de Microsoft. 

La autenticación se realiza en AD, las contraseñas se sincronizan con el directorio LDAP. Son los siguientes:

  • Aplicaciones Citrix


Sistemas y aplicaciones propietarios

Hay aplicaciones que utilizan sistemas propietarios y que no es posible integrar con otros sistemas.

  • Prevengos, aplicación para la gestión de la prevención de riesgos laborales.
  • Nomina Unix. Aplicación para la gestión de la nómina.
  • BOB, Business On Board, desarrollado por SQA.
  • SINEE, tiene su poropio sistema


Google Apps Murciaeduca

Google Apps. Aplicación en la nube de Google. Se sincronizan las contraseñas.

Existen dos diferentes, uno para profesores y otro para alumnos

  • Profesores: murciaeduca.es
  • Alumnos: alu.murciaeduca.es

Directorio Activo de Microsoft en la Nube

Office 365, aplicación en la nube de Microsoft. Se sincronizan las contraseñas.

Existen dos diferentes, uno para profesores y otro para alumnos.

  • Profesores: aulaxxi.murciaeduca.es
  • Alumnos:    aula365.murciaeduca.es


Certificado digital

Permite la autenticación con cualquier certificado digital reconocido por la eA.

Se llama al servicio de autenticación de la plataforma corporativa de Administración Electrónica



Claves conocidas

En algunos casos tenemos identificación que permite realizar algunas acciones sin necesidad de tener a las personas en un directorio.

Por ejemplo, para ciudadanos que realizan convocatorias, para padres/madres/tutores que quieren acceder a la información de sus hijos.

Estos se utilizan en aplicaciones concretas:


  • MIRADOR: NIF del padre y NRE del alumno, que permite entrar a MIRADOR a comprobar las notas de un alumno. 



Visión

En ese punto se marca dónde queremos estar dentro de cinco años, en el 2020.

  1. Tener el menor número posible de sistemas de autenticación.
  2. El alta de los usuarios en los sistemas debe ser automático.
  3. La gestión de la contraseña debe ser independiente y autónoma para los usuarios.
  4. Nunca mantener sistemas en los que la contraseña esté en claro o sea posible su decodificación.
  5. Tener un solo CAS, balanceado y en alta disponibilidad.
  6. El CAS debe ser mantenido por Sistemas, al igual que el LDAP
  7. El CAS/LDAP/... se preocupe solo de autenticación.
  8. OAUTH utilizarlo para delegar la autenticación, no la autorización de procesos.
  9. Que permita OAUTH 2.0 y SAML
  10. Que cada aplicación identifique la mejor forma para autenticarse: LDAP, CAS, OAUTH 


Recomendaciones


Estrategias

  1. Eliminar el directorio de Novell para acceder a aplicaciones, utilizar el mismo que para las aplicaciones Citrix.
  2. Eliminar la gestión de identidades en Base de datos.

Bibliografía y referencias

  • Documento de Juan Francisco
  • Internet
  • Documento de Paco