Control de acceso para aplicaciones Web

Control de acceso para
aplicaciones Web
Andes 1365 piso 7º
Montevideo – Uruguay
Tel./Fax: (+598) 2901.2929*
Email: contacto@agesic.gub.uy
www.agesic.gub.uy
Índice de contenido
Control de Acceso............................................................................................................................................4
Autenticación...................................................................................................................................................6
Autorización.....................................................................................................................................................7
Logging y Auditoría.........................................................................................................................................7
Single Sign-On.................................................................................................................................................7
Referencias.......................................................................................................................................................7
Andes 1365 piso 7º
Montevideo – Uruguay
Tel./Fax: (+598) 2901.2929*
Email: contacto@agesic.gub.uy
www.agesic.gub.uy
Control de Acceso
La Figura 1 presenta la arquitectura de control de acceso que las aplicaciones
transversales a la plataforma como son Expediente Electrónico (EE), Portal,
Herramienta Colaborativa (HHCC), etc.
Figura 1: Esquema de Control de Acceso de aplicaciones
En este esquema, webSEAL es el Policy Enforcement Point (PEP) actuando como
reverse proxy. Sobre webSEAL llegarán todos los posibles pedidos y ataques que
pueda realizarse sobre la plataforma, siendo el único punto de acceso a las
aplicaciones.
Para autenticar los pedidos que le llegan a la plataforma, webSEAL consultará a TAM
basado en las credenciales enviadas por parte del usuario (ej. usuario y password,
certificdos, etc). En caso que el usuario sea autenticado correctamente, webSEAL
redirige el pedido hacia la aplicación correspondiente, incluyendo en el mismo un token
de seguridad de tipo SSO que confirma que el usuario está autenticado. Las
aplicaciones finales deberán leer este token de seguridad, interpretarlo y validarlo para
autenticar los pedidos de los usuarios. Por más detalles acerca de cómo integrar
aplicaciones .NET y JEE con Webseal, ver [1] y [2].
Control de acceso para aplicaciones Web
Página 4 de 7
Un detalle importante a destacar es que la aplicaciones transversales no realizan la
gestión de usuarios (lo que refiere a alta, baja o modificación de los mismos). Los
mismos podrán ser obtenidos del respositorio central de usuarios (LDAP) que estará
poblado con todos los usuarios necesarios por las aplicaciones. Asimismo, este
repositorio podrá ser utilizado por las aplicaciones en caso de necesitar un directorio
LDAP para su correcto funcionamiento.
La gestión de identidades en este esquema, se realizará en forma centralizada. Cada
aplicación detrás de WebSEAL podrá tener su propio respositorio de perfiles de usuario,
pero la autenticación será realizada por TAM y la gestión de identidades mediante una
aplicación externa.
Otro detalle importante a destacar, es que el sistema de control de acceso no lleva a
cabo la autorización de los usuarios por lo que las aplicaciones deberán realizar esta
tarea en caso de ser necesario.
Bajo el esquema de control de acceso planteado, los pasos que debe seguir un pedido
a una aplicación transversal, son los siguientes:
1. El usuario accede a una URL que es publicada por WebSeal. En este punto,
WebSeal cumple tres funciones:
a) Reverse Proxy: WebSeal es el único punto de acceso publicado a la web, y
todas las solicitudes web realizadas fuera de la plataforma deben pasar por
dicho producto. WebSeal se ocupará de redirigir las solicitudes al servidor de
aplicaciones correcto dentro de la plataforma.
b) Autenticación: WebSeal autentica los usuarios contra TAM.
c) Autorización: En base a las ACLs definidas en TAM para las distintas URLs
manejadas por WebSeal, se toma una decisión de autorización.
2. Se envían las credenciales del usuario a TAM.
3. TAM autentica el usuario contra el TDS.
4. Si el usuario es autenticado exitosamente, se consulta al TDS por los valores de
los atributos necesarios para incluir en el token de seguridad.
5. TAM envía los atributos a WebSeal.
6. WebSeal incluye en el HTTP request que será enviado al servidor de
aplicaciones los headers con los valores que recibió de TAM.
7. La aplicación ejecuta sus reglas de autorización, en base al contexto de
seguridad establecido para la misma, y envía una respuesta. Es importante
destacar que esta autorización es de suma importancia, ya que la autorización
realizada en WebSeal cumple únicamente un objetivo de optimización, evitando
que se envíen solicitudes no autorizadas a los servidores web. Sin embargo,
dicha autorización es de alto nivel, y nunca deberá sustituir a la de la aplicación.
Se recomienda, como buena práctica, asumir que la autorización de WebSeal
no existe al momento de asegurar las aplicaciones publicadas en la plataforma.
8. Finalmente, como último paso se envía la respuesta al usuario con la página
solicitada.
Control de acceso para aplicaciones Web
Página 5 de 7
En la Tabla 1 se presenta un ejemplo del cabezal HTTP envíado por WebSEAL con la
información del usuario autenticado. Puede observarse información como el id de
usuario, los grupos del usuario, ip desde donde accede, etc. Además, el cabezal envía
una firma de la información que envía, para que pueda verificarse la integridad de la
misma.
GET / HTTP/1.1
accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
accept-language: en-usconnection: close
host: www.google.com
iv-creds: Version=1,
BAKs3DCCB88MADCCB8kwggfFAgIGEDCB+DAtMB8CBBeohvwCAwD6xAICEd0CAgCJAgIAng
QGAAwp0eExD….
iv-groups: "SecurityGroup","ivmgrd-servers","iv-admin","secmgrdservers”
iv-remote-address: 127.0.0.1
v-user: sec_master
referer: http://localhost:81/google
user-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;
.NET CLR 1.1.4322)via: HTTP/1.1 vmwds101:81
iv-user-l: cn=SecurityMaster,secAuthority=Defaultiv_
iv-email: usuario@agesic.gub.uy
iv-ci: 12345678
server_name: default-webseald-vmwds101
ua-cpu: x86
cache-control: no-cache
Cookie:
PREF=ID=07c691fd051e5e39:U=924bb2eed27f19aa:TM=1263325927:LM=126332600
8:S=zyECm9FxprZe9Xt9;
NID=30=vYouHqU4LEGcp8CxGxZ_G_jWiWM7J_xmTVvxhkiieY_lJB5j4P1hPCzZ4dglPXE
V5FsN-aQeZYDW_46hHATBpS0WffPaSN_K-XjR96ahUNeKpNIZrPdPBksE0x3Xt222
Tabla 1: Ejemplo de cabezal HTTP WebSEAL
Entre las carácteristicas básicas que la solución ofrece, se encuentran:
• Autenticación de usuarios
• Autorización de usuarios
• Auditoria y logging
• Single Sign-On
Autenticación
En forma nativa, WebSEAL puede autenticar usuarios con su username y password
utilizando una conexión SSL o utilizando un certificado de clave pública X.509 V3,
Tokens, etc. TAM puede integrarse con varios tipos de soluciones de PKI, incluyendo
Tivoli PKI, VeriSign, Entrust, etc.
Control de acceso para aplicaciones Web
Pág. 6 de 7
TAM soporta firma de certificados y chequeo de revocación. También soporta el mapeo
de credenciales de clave pública con permiso de acceso para el usuario “dueño” de ese
certificado digital. Una vez que el usuario es autenticado, TAM acepta las credenciales
de autorización del usuario que incluye información de identidad como ser a que grupos
pertenece el usuario y que roles tiene asociado.
Autorización
Cada vez que un usuario intenta acceder a un recurso, se chequean las credenciales
del usuario contra las políticas de autorización para ese recurso. Este modelo permite
que la información de las políticas de autorización pueda administrarse de manera
centralizada y que no pase al escritorio del usuario.
Los servicios de autorización de TAM permiten heredar políticas, autorización por
grupos de membresía y control de accesos basados en roles.
Logging y Auditoría
La habilidad de logear y auditar todos los intentos de accesos es esencial para asegurar
la Web corporativa. Monitorear los intentos de accesos que intenten y realicen todos los
usuarios, le permiten al administrador detectar riesgos de seguridad.
TAM loguea en forma centralizada todos los intentos de acceso en forma estándar y
genera reportes fáciles de leer. Este log puede ser transferido en forma segura a un
sistema de base de datos de terceros para un análisis de patrones de uso.
Single Sign-On
WebSEAL provee single sign-on a la Web corporativa. El mismo puede integrarse con
aplicaciones Web, tales como el portal, pasando la información del usuario a la
aplicación en forma transparente. Con TAM, los usuarios deben autenticarse una sola
vez y pueden acceder a todos los recursos y aplicaciones Web para los cuales estén
autorizados.
Referencias
[1] IBM Tivoli Access Manager Microsoft IIS Integration, https://www304.ibm.com/support/docview.wss?uid=swg24016387
[2] IBM Tivoli Access Manager Apache Tomcat Adapter, https://www304.ibm.com/support/docview.wss?uid=swg24021393
Control de acceso para aplicaciones Web
Página 7 de 7