2011-05-16 19 views
6

Me gusta la forma en que los permisos y los grupos funcionan en Active Directory, pero no quiero atar realmente mi aplicación con AD.¿Hay una biblioteca C# que se comporte como los permisos y grupos de Active Directory?

¿Existe una biblioteca existente que contenga el mismo tipo de funcionalidad que AD? En particular, ¿la capacidad de crear grupos, asignar usuarios a grupos, agregar permisos a grupos y ver los permisos aplicados de un usuario o grupo?

+1

¿Qué pasa con el modelo de proveedor que ya existe? http://msdn.microsoft.com/en-us/library/kt5ssstk.aspx –

+0

@ Charlie Gracias, pero estoy tratando de administrar las reglas comerciales, no solo manejar la autorización. – Rachel

+0

Veo, he utilizado el RoleProvider en el pasado para hacer esto, luego marco métodos en la capa de servicio con atributos para requerir roles específicos para ejecutar. También puede marcar accesorios visibles en el modelo de vista para mostrar u ocultar. –

Respuesta

0

Puede configurar un servidor LDAP gratuito, p. OpenLDAP, y use DirectoryServices para acceder a él, y cualquier cantidad de tools para administrar el directorio LDAP. ¡Alguna configuración requerida!

La ventaja de utilizar un servicio de directorio estándar se encuentra en la gran cantidad de herramientas de administración y la capacidad de admitir cualquier cantidad de aplicaciones. Las desventajas son aprender a administrar y consultar el directorio. ¿Hay alguna razón en particular por la que no quieras usar AD? Si está trabajando en Windows, lo recomiendo ampliamente en la mayoría de las objeciones.

0

Puede ser que pueda usar Microsoft-s AzMan-Authorization Manager como un contenedor para Active directory.

Contiene una API para programar en contra de pedir permisos

y una interfaz gráfica de usuario (azman.msc) donde se pueden definir las funciones y los derechos de mapas y almacenarlas en un archivo XML.

Se puede configurar contra Active Directory.

0

Dos cosas.

Primero:

Si desea interactuar con un directorio que tiene que programar en la parte superior de la API de LDAP. Por lo que yo entiendo, ADSI está trabajando en la parte superior de LDAP, pero no parece ser tan independiente de Active Directory. Sé que Novell que inicia el mono project edita un más independant C# library on the top of LDAP.

Segundo:

Permisos, me refiero a la lista de control de acceso (ACL) son una característica no estándar. La forma en que se implementan los permisos en Active Directory es diferente de la forma en que se implementan en Sun e-Directory (atributos especiales). Por ejemplo, en OpenLDAP los permisos se implementan en un tipo de filtro de acceso.

Puede (espero) estar equivocado, pero nunca escuché acerca de una biblioteca que federa permisos en Directorios.

0

Una biblioteca que he leído es Rhino Security. Parece manejar la autenticación y la autorización para operaciones comerciales, y probablemente valga la pena echarle un vistazo. No lo he implementado, así que no sé qué tan bien funciona.

0

Puede usar Authorization Manager (AzMan) para esto, es parte de Windows Server. Para integrarlo desde .NET, Enterprize Library 5 tiene tipos de biblioteca de clases que puede usar.

1

La clase ActiveDirectoryMembershipProvider hereda MembershipProvider.

Eso significa que no tiene que vincular su aplicación a AD per se, sino al modelo MembershipProvider. Este modelo se usa en .net y funciona bien con controles y clases incorporados.

Aquí es una muestra

//Any of these will work 
ActiveDirectoryMembershipProvider provider = new ActiveDirectoryMembershipProvider(); 
//SqlMembershipProvider provider = new SqlMembershipProvider(); 
//MyCustomMemebershipProvider provider = new MyCustomMemebershipProvider(); 

MembershipProvider membershipProvider = provider; 

if (membershipProvider.ValidateUser("username", "password")) 
{ 
    MembershipUser user = membershipProvider.GetUser("username", true); 
} 
else 
{ 
    //Do something 
} 

no soy un experto en este modelo, pero he tenido alguna experiencia sub clasificar a MembershipProvider e implementar IPrincipal, IIdentity etc. Hacer esto es muy flexible y mantiene una arquitectura consistente

Cuestiones relacionadas