Hace un tiempo escribi un post sobre este tema: http://staff.southworks.net/blogs/matiaswoloski/archive/2007/03/10/The-holly -grail-of-Enterprise-SOA-security.aspx
En resumen habla de una arquitectura centralizada para manejar identity (authentication y authorization en particular) basada en standards como WS-Trust, SAML, STS, etc. Esta implementado sobre WCF. Esto es adicional a lo que comenta Daniel. Apunta a la exposición de estos servicios utilizando standards y en segundo plano al store de autenticación/autorización que se utilice (ADAM, AzMan, DB, xml). From: puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Pablo E. Navarro (Listas MUG) Sent: Tuesday, April 08, 2008 9:39 PM To: puntonet@mug.org.ar Subject: [puntonet] Seguridad Centralizada Gracias Daniel por todos tus comentarios. Saludos Pablo E. Navarro Vía Informática - (54-11) 4541-2768 <http://www.via-informatica.com.ar> www.via-informatica.com.ar From: puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Laco Sent: Lunes, 07 de Abril de 2008 10:04 To: puntonet@mug.org.ar Subject: [puntonet] Seguridad Centralizada Hola Pablo Vamos por parte. AzMan provee servicios de Autorización, NO de Autenticación. Ahi uno puede definir Tareas, Operaciones y eso asignarlos a Usuarios y/o Grupos de Usuarios. Ahora, al momento de asignar los usuarios a los Roles del AzMan, ahí si se usan Usuarios de ActiveDirectory (AD). La única forma de agregar usuarios que no sean de AD, es mediante la API, por programación. Pero es ese caso lo que tenes que generar es un SID para cada usuario, no importa que el usuario tuyo este en una base de datos. Internamente AzMan usa SIDs (http://en.wikipedia.org/wiki/Security_Identifier) para asignar los usuarios a los Roles. O sea, si bien AzMan es el motor de AD, sin AD, y te permite usarlo sin tener instalado un AD, inclusive se pueden almacenar los datos en un archivo XML, se complica en el caso de que se quieran utilizar autorización con usuarios que no son de AD, ya que hay que hacer las cosas por programación (el API esta preparado). Una solución mas flexible, es NetSqlAzMan, que tiene mas funcionalidad que el AzMan de MS, almacena todo en una base SQL Server y te permite almacenar permisos de usuarios que no son de AD. Saludos! Daniel Laco | Business Development Manager | Microsoft MVP | VEMN S.A. | |Pje. Villalonga 821 2° piso - Ituzaingó - Buenos Aires | TE: 54 11. 4623.2582 | Cel: 15.5737.9201 | From: puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Pablo E. Navarro (Listas MUG) Sent: Viernes, 04 de Abril de 2008 08:45 p.m. To: puntonet@mug.org.ar Subject: [puntonet] Seguridad Centralizada Hola Daniel Creo que para no depender de Active Directory se podría usar AzMan con ADAM. Entiendo que ADAM provee servicios de directorio que se pueden acceder con LDAP sin necesidad de tener Active Directory. Hay info de ADAM en: http://www.microsoft.com/windowsserver2003/techinfo/overview/adam.mspx http://www.microsoft.com/downloads/details.aspx?FamilyID=b7e505c0-d4b9-46fb- ae71-e3b48e7938c0 <http://www.microsoft.com/downloads/details.aspx?FamilyID=b7e505c0-d4b9-46fb -ae71-e3b48e7938c0&displaylang=en> &displaylang=en Cómo se utiliza AzMan y ADAM para administrar roles con ASP.NET: http://msdn2.microsoft.com/en-us/library/ms998331.aspx Developing Applications Using Windows Authorization Manager: http://msdn2.microsoft.com/en-us/library/aa480244.aspx Alguien ya trabajó con AzMan? Desde ya muchas gracias por cualquier referencia o experiencia personal sobre el tema. Saludos Pablo E. Navarro Vía Informática - (54-11) 4541-2768 <http://www.via-informatica.com.ar> www.via-informatica.com.ar From: puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Laco Sent: Jueves, 03 de Abril de 2008 18:32 To: puntonet@mug.org.ar Subject: [puntonet] Seguridad Centralizada Hola Pablo. Voy a tratar de responderte la pregunta (justo estamos haciendo algo similar para un cliente): El tema de manejar centralizado la seguridad tiene varios aspectos, entre los principales esta el tema de Autenticación y la Autorización a aplicaciones y/o a funciones de una aplicación en particular. Sin entrar mucho en detalle porque sería un mail largo, creo que la alternativa para el caso que necesitas es que proveas servicio/s que brinden la funcionalidad que necesitas. Por ej. Podrías tener un servicio que haga la autenticación y otro servicio que haga la autorización. Con el tema de autenticación no hay muchos secretos, o es usuario y clave contra una base de datos (esto si tenes Java como comentás) o usuario de Windows y AD (Active Directory). El tema de autorización es otra cosa, en ese caso poder usar AzMan como comentás (con lo cual estas limitado a usuarios de Active Directory, aunque se pueden agregar usuarios "custom"), otra alternativa es usar NetSqlAzMan - http://sourceforge.net/projects/netsqlazman/ (similar al anterior, pero mucho mas flexible, almacena en SQL Server y permite usuarios "custom"), otra alternativa es que desarrolles un modelo personalizado de almacenamiento. Estos paquetes cumplen lo relativo al tema de autorización. El tema de la implementación lo podrías hacer perfectamente con WCF, publicando URLs por HTTP/SOAP, con lo cual, si bien es menos performante que TCP/Binario nativo, es mas interoperable porque sumas a Java. Ahora, si el manejo es centralizado, no creo que sea buena idea lo que comentás de que cada servicio tenga que exponer "servicios" similares para operar con el esquema. Mas bien, los sistemas tendrían que "consumir" el esquema centralizado. Con respecto al tema de restringir el acceso a esos servicios, en realidad no le veo mucho inconveniente, porque no creo que necesiten mucha restricción, ya que solamente van a autenticar y para un usuario dado, obtendrás la lista de funciones/acciones permitidas para cada aplicación. No hay mucha lógica de negocios para proteger. Además si tenes una consola central de administración los usuarios o bien son del Dominio, o tendrá algún administrador que se ocupe del mantenimiento de los usuarios. Lo mismo vale para las aplicaciones y las funciones de cada una de ellas. Bueno Pablo, espero no haber sumado más confusión al tema. Si bien es para explicarlo más en detalle, espero que sirva como un comentario sobre el tema. Un abrazo. Daniel Laco <http://www.vemn.com.ar/> www.vemn.com.ar Pje. Villalonga 821 - Piso 2 | (1714) | Ituzaingó | Argentina ( +54 (11) 4623-2582 / 4624-6012 From: puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Pablo E. Navarro (Listas MUG) Sent: Jueves, 03 de Abril de 2008 05:47 p.m. To: puntonet@mug.org.ar Subject: [puntonet] Seguridad Centralizada Hola gente Tengo el caso de una empresa con un sistema central desarrollado en .NET, más sistemas satélites, algunos en .NET, otros en Java. La idea es centralizar la administración de la seguridad (Autenticación de usuarios y autorizaciones de acceso a funcionalidades de cada sistema), de modo que un administrador de seguridad local tenga una sola pantalla donde se muestre por un lado cada usuario (de dominio) y por otro los sistemas / funcionalidades a habilitar. Esto es para evitar que el administrador de seguridad tenga que conocer y acceder a cada una de las aplicaciones para dar de alta usuarios, inicializar passwords, etc., que tenga una única pantalla donde para cada usuario pueda ver los sistemas y funcionalidades habilitadas. Estoy encaminando algunas soluciones alternativas que quería compartir con Uds. y ver qué les parece. Estas son las soluciones que tengo hasta el momento: - Armar una aplicación independiente a las demás que se encargue de "recolectar" información de cada sistema y manejar la interfaz de usuario unificada. o Luego cada sistema tendría que exponer "servicios" similares que permitan operar sobre el esquema de seguridad local (altas de usuarios, cambio de passwords, devolver una lista de roles/funcionalidades permitidas, agregar/quitar un rol a un usuario, etc.) - Armar algo con ADAM (Active Directory Application Mode) en cada aplicación, para que la info de usuarios y accesos quede centralizada en un lugar único. o Con esto estaría dejando afuera a las aplicaciones Java. L a 1ra opción mantiene el esquema de seguridad de cada aplicación intacto mientras que ofrece servicios para que otros aplicativos puedan operar en forma externa. El problema es cómo restringir el acceso a esos servicios, supongo que con WCF, un tema aún pendiente de explorar. Saludos Pablo E. Navarro Vía Informática - (54-11) 4541-2768 <http://www.via-informatica.com.ar> www.via-informatica.com.ar
<<attachment: winmail.dat>>
