asp.net - ¿Qué esquemas de autenticación y autorización está utilizando, y por qué?

authentication asp.net-membership

Question

Estamos empezando a diseñar un conjunto completo de nuevos servicios para crear (WCF, ADO.NET Data Services, posiblemente en la nube en algún momento) y una pregunta que surge es qué esquema de autenticación y autorización usar: hay bastantes ¡pocos!

Básicamente, necesitamos poder identificar a los usuarios (personas reales y usuarios de aplicaciones / servicios "virtuales") en una amplia variedad de protocolos: HTTP, HTTPS, TCP, y debemos asignarles al menos un montón de roles / permisos para ver ciertos datos y / o hacer ciertas operaciones.

Definitivamente no podemos usar la membresía grupal de Windows, tenemos muchos consumidores externos de nuestros servicios y no queremos tener que configurar una cuenta de dominio en nuestro dominio interno para cada uno de ellos.

Entonces, hay principalmente tres opciones, creo:

1. Usar el sistema de membresía ASP.NET - crear usuarios y asignar roles allí
2. Use AzMan (Administrador de autorización) que parece ser un sistema más detallado, más maduro y más elaborado (con usuarios, tareas, grupos: tres niveles, no solo roles de usuario +)
3. Rollo nuestro

Antes que nada, ¿cuál de estos tres recomendarías? ¿Nada porque?

En segundo lugar, ¿hay más opciones de las que me estoy perdiendo?

Gracias por cualquier pista, punteros, opiniones!

Bagazo

PD: viendo las respuestas hasta ahora, me sorprende la cantidad de personas que votan por la opción n. ° 3. Pensé que MS podría diseñar algo reutilizable que pudiera manejar todos estos requisitos ...

Answer 1

¿No es AZMan desde 2003?

Yo recomendaría 1 o 3. Personalmente, siempre he ido por 3. Hay muchas funcionalidades que tengo que no uso o no me gusta usar.

Answer 2

En realidad, la respuesta es probablemente una combinación de 1 y 3.

Puede aprovechar muchas de las herramientas y características que proporciona el marco escribiendo una membership , una membership o profile proveedor de profile si las opciones predeterminadas no llegan tan lejos como desea.

Hemos hecho exactamente eso en varios sitios de clientes: por ejemplo, uno de nuestros clientes tiene la mayoría de sus usuarios almacenados como usuarios de Commerce Server, y usa el sistema de perfil de Commerce Server, así que escribimos un proveedor de membresía y perfil para hablar con aquellos datastores - un ejercicio bastante simple.

La mayoría de las personas probablemente opten por 3 debido a la necesidad de autenticarse con TCP sin procesar; esto introduce una capa más allá de la de los proveedores de membresía estándar de ASP.NET .

La mayor parte de lo que produce MS es "aceptable" o "lo suficientemente bueno", pero siempre habrá casos límite en los que desee hacer algo "no del todo estándar", lo que significa que terminará haciendo los suyos propios. Creo que para tener algo más allá de "Autenticación básica" o "Autenticación de Windows" que era sencillo de entender para el desarrollador medio, tomaron la sensata opción de "vamos a construir esto para la web".

Si echas un vistazo a las numerosas formas en que puedes autenticarte contra un servicio WCF, verás lo que quiero decir: están diseñadas para manejar diferentes mecanismos de transporte y, por lo tanto, son mucho más complejas.

Dicho esto, los roles predeterminados y los proveedores de perfiles son bastante limitados (roles: sin jerarquía, por lo que debe verificar cada rol posible o asignar explícitamente cada rol al usuario; perfiles: todos almacenados en un campo como valores separados por comas - no fácil de encontrar todos los usuarios que tienen un conjunto de valores).

Answer 3

En un proyecto reciente, extendimos el proveedor de membresía ASP.NET (escribió un proveedor personalizado) con la intención de utilizar algunos de los controles basados ​​en roles para administrar permisos. Ahora que el proyecto ha madurado lo suficiente, descubrimos que los controles no son lo suficientemente flexibles para nuestros requisitos, y hasta cierto punto nos arrepentimos de ir por la ruta de membresía de MS. Transferir su propia autenticación si tiene el tiempo para diseñarla correctamente será la mejor opción.

Parece que su aplicación es un poco híbrida, ya que presta servicios a clientes internos y externos, pero quizás también considere OpenID integración de OpenID para sus clientes externos. Existen algunos excelentes controles OpenID de ASP.NET que realmente hacen que manejar nuevas cuentas para clientes externos sea una obviedad. Esto, por supuesto, depende de qué tan ''pública'' sea su aplicación.

Answer 4

Me mantendría alejado de AzMan. Recorrimos esa ruta una vez y no nos gustó la sección de la ciudad en la que nos colapsamos. Siempre hemos hecho inicios de sesión basados ​​en AD que usan el SID del usuario actual para vincular a un usuario en la base de datos, luego tomamos los permisos desde allí. Dada su configuración, esto puede no ser posible (o práctico), pero me mantendría alejado de AzMan en cualquier caso.

Answer 5

No soy desarrollador de ASP o .NET, pero mi intuición dice (3). Realmente no desea que una aplicación web de uso público tenga ningún tipo de acceso a su red corporativa, y mucho menos pueda poner sus credenciales de autenticación cerca de AD.

Answer 6

Parece que proporciona demasiado y es demasiado extensible para apegarse a una solución tecnológica

Solución 3.

Basaría toda la aplicación en una clase de usuario. Simplemente tendría que modelarla para que le brinde la flexibilidad y extensibilidad necesarias.

Algo como:

    [ClassAttribute ( "Yordan Georgiev", "1.0.2", "20090302", "20090415" , false )]
public class User
{
    #region DomainName
    private string _DomainName;
    public string DomainName
    {
        get { return _DomainName; }
        set { _DomainName = value; }
    } //eof property DomainName 


    #endregion DomainName

    #region Status
    private int _Status;
    public int Status
    {
        get { return _Status; }
        set { _Status = value; }
    } //eof property Status 


    #endregion Status

#region Password
    private string _Password = Resources.GV.Pass; 
    public string Password
    {
        get { return _Password; }
        set {
            _Password = GenApp.Utils.Security.Encryptor.Encrypt ( value,
                GenApp.Conf.GenAppSettings.Instance.EncryptionAlgorithm );
            //debug_Password = value; //unencrypted 
        }
    } //eof property Password 


    #endregion Password 

#region ListUserRoles
        private List<UserRole> _ListUserRoles;
        public List<UserRole> ListUserRoles { get { return _ListUserRoles; } set     { _ListUserRoles = value; } }
        #endregion ListUserRoles


    #region UserSettings
    private GenApp.Conf.UserSettings _UserSettings;
    public GenApp.Conf.UserSettings UserSettings
    {
        get {
            if (_UserSettings == null)
                _UserSettings = (GenApp.Conf.UserSettings)GenApp.Conf.GenAppSettings.Instance;

            return _UserSettings; 
        }
        set { _UserSettings = value; }
    } //eof property UserSettings 

}

Answer 7

Usamos (3). En realidad, eso nos ayudó en un escenario de integración para tener cuentas en sincronización con

1. Procesos de negocios
2. Otros sistemas (no todos en la misma pila de tecnología (ASP.NET))

Answer 8

Ldap alguien? Es gratuito, de planificación cruzada, fácil de usar y administrar de forma remota, tiene puentes con otros esquemas de autenticación y enlaces en más idiomas que usted sabía que existían ...