Control de acceso para aplicaciones Web

Transcripción

1 Control de acceso para aplicaciones Web Andes 1365 piso 7º Montevideo Uruguay Tel./Fax: (+598) *

2

3 Í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) * contacto@agesic.gub.uy

4 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

5 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

6 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: iv-creds: Version=1, BAKs3DCCB88MADCCB8kwggfFAgIGEDCB+DAtMB8CBBeohvwCAwD6xAICEd0CAgCJAgIAng QGAAwp0eExD. iv-groups: "SecurityGroup","ivmgrd-servers","iv-admin","secmgrdservers iv-remote-address: v-user: sec_master referer: user-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;.NET CLR )via: HTTP/1.1 vmwds101:81 iv-user-l: cn=securitymaster,secauthority=defaultiv_ iv- usuario@agesic.gub.uy iv-ci: server_name: default-webseald-vmwds101 ua-cpu: x86 cache-control: no-cache Cookie: PREF=ID=07c691fd051e5e39:U=924bb2eed27f19aa:TM= :LM= :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

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, ibm.com/support/docview.wss?uid=swg [2] IBM Tivoli Access Manager Apache Tomcat Adapter, ibm.com/support/docview.wss?uid=swg Control de acceso para aplicaciones Web Página 7 de 7