asp.net - formularios - paginas web asp net ejemplos

seguridad del sitio web asp.net configurable por el cliente para un control detallado del acceso a la página y al botón

Question

Tengo un sitio web ASP.NET 2.0 [no ajax ... todavía] que se implementará en forma compilada en varios sitios de clientes. Normalmente, el sitio será intranet solamente. Algunos clientes confían en toda su gente y no les importa limitar el acceso al sitio y / o las funciones de la página, otros no confían en nadie y solo quieren que ciertas personas y / o grupos puedan ver ciertas páginas, hacer clic en ciertos botones, etc. Alabama.

Podría hacer alguna solución local, posiblemente obtener los permisos de acceso de una tabla de base de datos, pero antes de seguir por ese camino, pensé que podría preguntar en SO: ¿cuál es una buena solución para esta situación? preferiblemente uno que se puede controlar por completo en el archivo y / o base de datos web.config, ya que la reconstrucción del sitio web no es posible (para el cliente, y no quiero tener que hacerlo una y otra vez). La integración de Active Directory sería una ventaja, pero no un requisito (a menos que sea simplemente más fácil).

como punto de partida, estoy pensando que a cada página / punto de función en el sitio se le dé una identidad y se asocie con un grupo de permisos ...

EDITAR: la sección de autorización web.config permite / niega el acceso por rol y el usuario es bueno, pero eso es solo la mitad del problema; la otra mitad controla el acceso a los métodos individuales (botones, lo que sea) en cada página. Por ejemplo, algunos usuarios pueden ver whatchamacallits mientras que otros pueden editar, crear, eliminar o deshabilitar / habilitarlos. Todos estos botones / enlaces / acciones están en la página de visualización ...

[lo ideal sería que los botones desactivados fueran invisibles, pero eso no es importante aquí]

EDITAR: algunas buenas sugerencias hasta el momento, pero todavía no hay una solución completa, sigue inclinándose hacia una solución basada en bases de datos ...

• los atributos de demanda de permisos de seguridad generarán excepciones cuando se haga clic en los botones, lo cual no es una tarea amigable; Preferiría esconder botones que el usuario no puede usar
• el control LoginView también es interesante, pero requeriría replicar la mayor parte del contenido de la página varias veces (una para cada función) y no manejar el caso en el que un usuario tiene más de un rol: no puedo asumir que los roles sean jerárquicos ya que será definido por el cliente

EDITAR: la plataforma es Win2K / XP, Sql Server 2005, ASP.NET 2.0, sin utilizar AJAX

Answer 1

Aunque nunca he usado esto antes en la práctica y no puedo argumentar sus ventajas, sé que .NET tiene una función de seguridad de código basada en roles que le permite bloquear declarativamente los métodos por función o por usuario. Por ejemplo:

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "MyUser", Role = "User")]
public static void PrivateInfo()
{   
    //Print secret data.
    Console.WriteLine("/n/nYou have access to the private data!");
}

La seguridad basada en roles se trata con más detalle aquí . No sé si te ayudará mucho, aunque considerará que requerirá una recompilación para cambiarlo; Sin embargo, pegar etiquetas en los métodos es más rápido que crear lógica para mostrar / ocultar botones o validar la seguridad en el código.

Además, querrá leer sobre la autenticación integrada de Windows para obtener la posibilidad de Active Directory.

Answer 2

Creo que lo que debes hacer aquí es implementar un conjunto de métodos de consulta de permisos en tus objetos comerciales o tu controlador. Ejemplos: CanRead (), CanEdit (), CanDelete ()

Cuando la página rinde, necesita consultar el objeto comercial y determinar las capacidades autorizadas de los usuarios y habilitar o deshabilitar la funcionalidad en función de esta información. El objeto comercial puede, a su vez, usar Roles o consultas de bases de datos adicionales para determinar los permisos del usuario activo.

No puedo pensar en una forma de definir declarativamente estos permisos centralmente. Deben distribuirse en la implementación de las funciones. Sin embargo, si desea mejorar el diseño, puede usar la inyección de dependencia para insertar autorizadores en sus objetos comerciales y así mantener las implementaciones separadas.

Hay un código que usa este modelo en el libro de Rocky Lhotka. La nueva versión aún no está en Google .

Answer 3

Creo que voy a tener que combinar la autorización de AD con las tablas de "características y permisos" en la base de datos para obtener el control preciso que necesitamos.

• utilice el archivo web.config para permitir que solo los usuarios autorizados (a través de grupos de AD) visiten el sitio web
• crea una tabla de "características" que enumere cada página y función que puede verse afectada, por ejemplo, botón de edición de página 1, botón de eliminación de página 2, cuadrícula de detalle de página 3, etc.
• crear una tabla de ''permisos'' que especifique una característica y un grupo de AD que pueda usar la función
• alterar las páginas del sitio para verificar los permisos de las características en la carga de la página (o prerender, según corresponda) para deshabilitar / ocultar las funciones prohibidas según corresponda

ejemplos:

• Los administradores pueden usar todas las características del sitio
• Los desarrolladores pueden usar todas las características del sitio
• Los administradores pueden ver todas las páginas, pero solo pueden agregar y editar información, sin eliminaciones
• Los supervisores pueden ver resúmenes para todos los departamentos, pero pueden ver y editar detalles solo para su propio departamento (hay un grupo de AD para cada departamento y departamento-supervisor)
• El personal puede ver detalles solo para su departamento
• etc.

La solución final redujo la noción de ''característica'' a una decisión binaria que puede usarse o no puede usar, y agregó una bandera ''permisiva / no permisiva'' a cada característica. Esto permite que las características que todos pueden usar se definan como ''permisivas'', y luego la tabla de permisos solo tiene que registrar los grupos a los que se les deniega el permiso para usar esa función. Para una característica definida como no permisiva, por defecto nadie puede usar la característica y usted tiene que crear entradas de la tabla de permisos para los grupos que pueden usar la función. Esto parece brindar una solución de mejor de los dos mundos ya que reduce el número de registros de permisos requeridos para cada característica.

Answer 4

Parece que podría usar el control LoginView , que puede mostrar paneles de controles solo a ciertos usuarios o roles. Los roles son más flexibles: si no se requiere seguridad, coloque a todos los usuarios en todos los roles.

Úselo en combinación con la seguridad web.config estándar (ventanas integradas con directorio activo o autenticación de formularios (el esquema del servidor asp 2 Sql o el suyo propio).

<asp:LoginView id="LoginView1" runat="server">
                    <RoleGroups>
                        <asp:RoleGroup Roles="Admin">
                            <ContentTemplate>
                                <asp:LoginName id="LoginName2" runat="Server"></asp:LoginName>, you
                                are logged in as an administrator.
                            </ContentTemplate>
                        </asp:RoleGroup>
                        <asp:RoleGroup Roles="User">
                            <ContentTemplate>
                                <asp:Button id="Button1" runat="Server" OnClick="AllUserClick">
                            </ContentTemplate>
                        </asp:RoleGroup>
                    </RoleGroups>
                </asp:LoginView>

Answer 5

Prefiero otorgar derechos de acceso a los grupos de AD en lugar de a usuarios específicos. Encuentro que es mucho más flexible.

No sé mucho sobre su aplicación, pero es posible que desee consultar la etiqueta de autorización en el archivo web.config:

<authorization>
    <!--  
        <deny users="?" />
        <allow     users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
        <deny      users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
    -->
</authorization>

Puede separar los archivos web.config de cada directorio dentro de su aplicación web, y puede anidar directorios. Cada archivo web.config puede tener su propia sección de autorización. Si coloca diferentes páginas en cada directorio, puede administrar estrechamente la seguridad al permitir un rol específico en cada web.config y denegar todo lo demás. Luego puede administrar los miembros de cada rol en el directorio activo. He encontrado que se trata de una solución afectiva porque hace un buen uso del marco de seguridad de Microsoft Active Directory y ASP.NET sin escribir sus propias cosas personalizadas, y si usa roles, es posible descargar la gestión de la membresía de roles a alguien que no tiene que tocar el archivo web.config, solo necesitan saber cómo usar la consola de administración de AD.