tutorial - roles asp.net c#
Autenticación, autorización, gestión de usuarios y roles y seguridad general en.NET (7)
Busque en los proveedores de membresía de ASP.NET . No creo que el proveedor de SQLMembershipProvider listo para usar funcione en su caso, pero es muy fácil rodar a su propio proveedor.
Necesito saber cómo implementar la seguridad general para una aplicación C #. ¿Qué opciones tengo a este respecto? Preferiría usar un marco existente si satisface mis necesidades, no quiero reinventar la rueda.
Mis requerimientos son los siguientes:
- la autenticación de usuario / contraseña habitual
- gestión de usuarios - asignar permisos a los usuarios
- gestión de roles: asigne usuarios a roles, asigne permisos a roles
- Autorización de usuarios basada en su nombre de usuario y rol.
Estoy buscando un framework / biblioteca de código abierto / gratuito que haya sido evaluado y utilizado por la comunidad .Net.
Mi aplicación tiene un enfoque de cliente / servidor, con el servidor ejecutándose como un servicio de Windows, conectándose a una base de datos de SQL Server. La comunicación entre el cliente y el servidor será a través de WCF.
Otra cosa importante es que necesito poder asignar permisos de usuarios o roles específicos para Ver / Actualizar / Eliminar una entidad específica, ya sea un Cliente, un Producto, etc. Por ejemplo, Jack puede ver un cierto 3 de 10 clientes, pero solo actualizan los detalles de los clientes Microsoft, Yahoo y Google, y solo pueden eliminar Yahoo.
Creo que está viendo algunos problemas por separado aquí. No es casualidad que la mayoría de los sistemas de seguridad tengan autenticación y autorización por separado.
Para la autenticación, la pregunta más grande es logística. O bien, ¿existe un lugar lógico para que estos usuarios vivan, ya sea localmente a la aplicación, en Active Directory, en algún otro almacén LDAP o incluso en alguna otra aplicación? Exactamente donde es bastante irrelevante: solo tenemos que ser capaces de identificar sólidamente a los usuarios y, preferiblemente, hacer que la tarea sea un problema de otra persona. Al final del día, solo necesita un identificador único y la comodidad que Bob de Accounting es en realidad Bob de Accounting.
La autorización es la parte más interesante del problema aquí. Creo que, si es realmente detallado, realmente desea gestionar todo esto dentro de su aplicación, sin importar de dónde provengan los usuarios. Marc Gravell realmente logró una buena manera de modelar al menos parte de esto: usar alguna implementación personalizada de IPrincipal y PrincipalPermission para administrar las cosas es una forma muy limpia de comenzar. Más allá de eso, puede utilizar técnicas como esta para tomar decisiones de autorización más complejas de una manera bastante limpia.
Me gustaría echar un vistazo a algo como CSLA.net: Expert C # 2008 Business Objects
Debe proporcionar todo lo que necesita.
Mi respuesta probablemente depende de la respuesta a esta pregunta: ¿es esta una aplicación Enterprise que vive dentro de una red con Active Directory?
Si la respuesta es afirmativa, estos son los pasos que proporcionaría:
1) Crear grupos globales para su aplicación, en mi caso, tenía un grupo APPUSER y un grupo APPADMIN.
2) Haga que se pueda acceder a su SQL Server en el modo de AUTENTICACIÓN MIXTA, y luego asigne su (s) grupo (s) de APPUSER como el SQL SERVER LOGIN a su base de datos con los derechos de CRUD correspondientes a sus DB (s), y asegúrese de acceder el SERVIDOR SQL con Trusted Connection = True en su cadena de conexión.
En este punto, su tienda de AD será responsable de la autenticación. Como está accediendo a la aplicación a través de una CONEXIÓN DE CONFIANZA, pasará la identidad de cualquier cuenta que ejecute la aplicación al servidor SQL.
Ahora, para la AUTORIZACIÓN (es decir, informar a su aplicación qué está permitido hacer el usuario que inició sesión) es simplemente una cuestión de AD para obtener una lista de los grupos a los que pertenece el usuario que ha iniciado sesión. Luego, verifique los nombres de grupo apropiados y cree su UI basada en la membresía de esta manera.
La forma en que funcionan mis aplicaciones son:
- Al iniciar la aplicación, las credenciales se basan en el usuario que ha iniciado sesión, este es el aspecto principal de la autenticación (es decir, pueden iniciar sesión, por lo tanto, existen)
- Obtengo todos los grupos para la identidad de Windows en cuestión
- Verifico el Grupo de USUARIOS Estándar: si este grupo no existe para la Identidad de Windows en cuestión, eso es una FALLA de autenticación
- Verifico el grupo de usuarios ADMIN. Con esto existente en los grupos de usuarios, modifico la IU para permitir el acceso a los componentes de administración.
- Mostrar la interfaz de usuario
Luego tengo un objeto PRINCIPIO con los derechos / etc determinados en él, o utilizo variables GLOBALES a las que puedo acceder para determinar la IU apropiada al crear mis formularios (es decir, si mi usuario no es miembro del grupo ADMIN, entonces ocultaría todos los botones DELETE).
¿Por qué sugiero esto?
Es una cuestión de despliegue.
Según mi experiencia, la mayoría de las aplicaciones empresariales son implementadas por ingenieros de redes en lugar de programadores; por lo tanto, tener autenticación / autorización para que sea responsabilidad de AD tiene sentido, ya que ahí es donde van los tipos de red cuando se habla de autenticación / autorización.
Además, durante la creación de nuevos usuarios para la red, un ingeniero de redes (o quien sea responsable de crear nuevos usuarios de la red) es más propenso a recordar que debe realizar asignaciones de grupo mientras están EN AD que el hecho de que tienen que ingresar a una red. Docena de solicitudes para analizar asignaciones de autorización.
Hacer esto ayuda con el laberinto de permisos y derechos que deben otorgarse las nuevas contrataciones o que se debe denegar a quienes dejan la empresa, y mantiene la autenticación y la autorización en el repositorio central al que pertenece (es decir, en el nivel AD @ the Domain Controller).
Para la seguridad general, puede encontrar útil el código principal incorporado; el objeto de usuario (y sus roles) están controlados en .NET por el "principal", pero de manera útil el propio tiempo de ejecución puede imponer esto.
La implementación de un principal puede ser definida por la implementación y, por lo general, puede inyectar la suya propia; por ejemplo en WCF .
Para ver el tiempo de ejecución que impone el acceso aproximado (es decir, a qué funcionalidad se puede acceder, pero sin limitarse a qué datos específicos):
static class Roles {
public const string Administrator = "ADMIN";
}
static class Program {
static void Main() {
Thread.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("Fred"), new string[] { Roles.Administrator });
DeleteDatabase(); // fine
Thread.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("Barney"), new string[] { });
DeleteDatabase(); // boom
}
[PrincipalPermission(SecurityAction.Demand, Role = Roles.Administrator)]
public static void DeleteDatabase()
{
Console.WriteLine(
Thread.CurrentPrincipal.Identity.Name + " has deleted the database...");
}
}
Sin embargo, esto no ayuda con el acceso detallado (es decir, "Fred puede acceder al cliente A pero no al cliente B").
Adicional; Por supuesto, para información detallada, simplemente puede verificar los roles requeridos en el tiempo de ejecución, marcando IsInRole en el principal:
static void EnforceRole(string role)
{
if (string.IsNullOrEmpty(role)) { return; } // assume anon OK
IPrincipal principal = Thread.CurrentPrincipal;
if (principal == null || !principal.IsInRole(role))
{
throw new SecurityException("Access denied to role: " + role);
}
}
public static User GetUser(string id)
{
User user = Repository.GetUser(id);
EnforceRole(user.AccessRole);
return user;
}
También puede escribir sus propios objetos principales / de identidad que realizan pruebas perezosas / almacenamiento en caché de los roles, en lugar de tener que conocerlos todos de antemano:
class CustomPrincipal : IPrincipal, IIdentity
{
private string cn;
public CustomPrincipal(string cn)
{
if (string.IsNullOrEmpty(cn)) throw new ArgumentNullException("cn");
this.cn = cn;
}
// perhaps not ideal, but serves as an example
readonly Dictionary<string, bool> roleCache =
new Dictionary<string, bool>();
public override string ToString() { return cn; }
bool IIdentity.IsAuthenticated { get { return true; } }
string IIdentity.AuthenticationType { get { return "iris scan"; } }
string IIdentity.Name { get { return cn; } }
IIdentity IPrincipal.Identity { get { return this; } }
bool IPrincipal.IsInRole(string role)
{
if (string.IsNullOrEmpty(role)) return true; // assume anon OK
lock (roleCache)
{
bool value;
if (!roleCache.TryGetValue(role, out value)) {
value = RoleHasAccess(cn, role);
roleCache.Add(role, value);
}
return value;
}
}
private static bool RoleHasAccess(string cn, string role)
{
//TODO: talk to your own security store
}
}
WCF tiene una rica funcionalidad relacionada con la seguridad que proporciona tanto autorización como autenticación. En detalles aquí: http://msdn.microsoft.com/en-us/library/ms735093.aspx
Yo usaría el término "RBAC" (Sistema de control de acceso basado en roles) como la Solución para todos sus requisitos.
No daría muchos detalles para explicar ''RBAC'' aquí, sino que lo resumiría a continuación.
Básicamente contiene 3 características.
1) Autenticación - Confirma la identidad del usuario. Por lo general, se realiza a través de cuentas de usuario y contraseñas o credenciales.
2) Autorización: define lo que el usuario puede hacer y no puede hacer en una aplicación. Ex. "Modificar orden" está permitido, pero "crear nueva orden" no está permitido.
3) Auditoria de acciones de usuario sobre aplicaciones. - Realiza un seguimiento de las acciones del usuario en las aplicaciones, así como quién ha concedido qué acceso a qué usuarios.
Puedes consultar RBAC en wiki aquí.
https://en.wikipedia.org/wiki/Role-based_access_control
Ahora, con respecto a la respuesta a sus requisitos, una de las posibles soluciones es ampliar la membresía de Asp.Net según sus necesidades.
Y en cuanto a algunos marcos listos para usar, recomendaría visual-guard.com/EN/-source_soforum.html para el que trabajo, debería verificar esto, hace todo lo que necesita muy fácilmente y lo más importante es que administra todos sus usuarios, roles y permisos. y las aplicaciones a través de la Consola de administración central, y para definir permisos, los administradores no requieren el conocimiento del desarrollador, es decir, él / ella puede crear restricciones en las actividades a través de la interfaz de usuario.
También puede consultar este artículo para comprender mejor los permisos y el sistema basado en roles.