RestrictedUI: A .NET Library for restricting a user interface based on a security policy

===============
 RestrictedUI: 
===============
Librer�a para limitar la interface de usuario en base a una pol�tica de seguridad

C�mo controlar la interface de usuario mediante una pol�tica establecida de manera declarativa, en base al rol o roles del usuario y al estado de la aplicaci�n.

Introducci�n
**************
Una parte delicada de la implementaci�n de la seguridad en aplicaciones, especialmente corporativas, consiste en determinar qu� funcionalidad debe estar o no accesible al usuario en funci�n de su rol, o qu� elementos deben o no mostrarse.

Lo habitual es incluir en el c�digo la l�gica necesaria para ocultar o deshabilitar determinadas opciones, botones, etc, dependiendo del tipo de usuario que accede a la aplicaci�n. Esto puede complicarse cuando aparte del tipo de usuario tambi�n debe tenerse en cuenta el estado en que se encuentra la aplicaci�n, por ejemplo el estado de tramitaci�n de una entidad.
Es bastante usual que esta pol�tica deba cambiar con cierta frecuencia, de la misma forma que deben evolucionar los requerimientos de las aplicaciones. Modificaciones en la estructura organizativa de la empresa, cambios en los protocolos de gesti�n de las unidades implicadas o simplemente la identificaci�n de carencias tras el uso de la aplicaci�n, entre otras causas, llevan a tener que hacer adaptaciones a esta l�gica ligada a la interface.

En respuesta a esta problem�tica cabe tambi�n la opci�n de centralizar la definici�n de esta pol�tica, en un repositorio com�n a m�ltiples aplicaciones. En base a esta definici�n, soportada por un modelo de datos determinado, es posible definir una librer�a que utilicen las aplicaciones, y que haga posible modificar la pol�tica de seguridad sin necesidad de recompilar y redistribuir las aplicaciones. La idea principal es la siguiente: el programador desarrolla como si s�lo hubiera un tipo de usuario, el administrador, con permisos para hacer cualquier cosa. Es la librer�a la que controla si debe impedirse un intento de hacer visible o de habilitar determinados controles.

Este enfoque es el que se usa actualmente en la empresa en la que trabajo. Aun ofreciendo gran flexibilidad en su concepci�n, la implementaci�n concreta de la misma presenta desde mi punto de vista una serie de limitaciones y dificultades concretas que he intentado corregir con esta otra librer�a/arquitectura:

Caracter�sticas principales
******************************
Por un lado la librer�a / arquitectura que aqu� se explica no obliga a centralizar la definici�n de esta seguridad, pero s� la contempla como un caso m�s; por otro lado para asegurar el cumplimiento de estas restricciones no es necesario obligar al programador a utilizar m�todos ni propiedades espec�ficas de la librer�a, que verifiquen si el cambio se permite o no, ni tiene que ser controlado por c�digo a a�adir; simplemente cualquier intento de hacer visible o habilitar cualquier elemento de interface supervisado que no sea admitido por la pol�tica de seguridad es interceptado e impedido. 
Se permite definir la pol�tica de restricciones no s�lo en base a roles sino a estados de la aplicaci�n, tanto en aplicaciones WinForms como Web; y para simplificar la definici�n de esta pol�tica se ofrece un formulario de mantenimiento, disponible tanto en tiempo de dise�o como de ejecuci�n.

Notas:
- No es objetivo de esta librer�a controlar la autenticaci�n del usuario. Se asume que �sta es realizada correctamente y que se conoce, con garant�as, el rol o roles que ostenta el usuario.
- El nombre de la librer�a, RestrictedUI, hace referencia al hecho de que ciertos elementos de la interface estar�n restringidos seg�n la seguridad establecida ('�rea restringida')

M�s informaci�n:
http://code.google.com/p/restricted-ui/