Archive

Archive for August, 2010

Application level Security – Part III (Screens)

August 25, 2010 6 comments

In the last two posts we have done a lot of talking and discussing the requirements and database model to support implementing a security system that will allow for enforcing permissions based on roles and explicit screens.

Role Maintenance
Now let’s start looking at the screens make all of this happen. We will start with the Role Maintenance screen. The Role Maintenance screen provides the ability to manage all roles in the application. Users can create, modify, or delete roles. The following is a screen shot of the Role Maintenance screen:

Adding a Role
When adding a role, the user clicks on the New button to left side of the toolbar as shown below:

This will bring the following popup:

In my scenario, the system has several modules that represent different lines of business. The user can pick what Application they wish the role to belong and then enter a name for new role. The user clicks on the Save button to commit the new role to the database.

Adding Screens to a Role
The user associates screens for a given role. With the new role that the user has created, the user clicks on the Add New button to the right of the Screens title of the grid as seen below:

This will bring up the following popup:

The user can multi-select screens to add to the current role. NOTE: Only the screens that are not already associated with this will will show up in the selector. Once the user closes the selector screen, the user can assign the appropriate permissions as shown below:

The user clicks on the Save button to commit the new screens and permissions to the database.

Deleting a Role
The user has the ability to remove existing roles. Based on business requirements, the user must first remove all associated screens to this role. To delete a role, the user clicks on the Delete button in the toolbar as shown below:

This will bring up the following a confirmation dialog:

After the user clicks the Yes button, the user clicks on the Save button to commit removing the role to the database.

Removing Screens from a Role
As stated previously, before a Role can be deleted, all screens must first be removed. The user clicks on the delete button to the right of the role in the grid as shown below:

This will bring up the following a confirmation dialog:

After the user clicks the Yes button, the user clicks on the Save button to commit removing the screen from the role.

User Access Security
The User Access Security screen provides the ability to control user access to all screens in the application. A user can assign existing roles to user accounts or define explicit screen permissions. The following is a screen shot of the user “matt” and his user access permissions:

Adding a User Role
When adding a user to a role, the user clicks on the New button to the right side of the User Roles title in the tree.

This will bring up the popup as seen below:

The user will first pick what Application he/she wants to filter the existing roles and then selects the appropriate role. NOTE: Only the roles that have not already been associated with this user account will be displayed. Finally, the user clicks the Save button to commit his/her changes and have the tree refresh to reflect the change as well.

Deleting a User Role
The user has the ability to remove roles from user accounts. The user clicks on the Delete button to the right of the role title in the tree.

This will bring up the following a confirmation dialog:

After the user clicks the Yes button, the user clicks on the Save button to commit removing the role from the user account. The tree will refresh to reflect the removal.

Editing a User Role Screen
The user has the ability to override any screen permission for a role. The user clicks on the Edit button to the right of the role title in the tree.

This will bring up a popup as seen below:

The user can then change the permissions for the specified screen. NOTE: This action does not change the role. The system will check to see if there is an existing explicit permission and open it up. If the system cannot find the corresponding screen permission, then it will create a new one for the user account. Finally, the user click the Save button to commit all changes to the database and the tree will refresh.

Adding a Screen User
When assigning screen permissions to a user account, the user must click on the New button to the right side of the Explicit Screen Permissions title.

This will bring up a popup as seen below:

The user will first pick what Application they wish to filter the screens and then they select the corresponding screen. NOTE: Only the screens that have not already been associated with the current user account will be displayed. Finally the user clicks the Save button to commit their changes and have the tree refresh to display the new change.

Deleting a Screen User
The user has the ability to remove screen permissions from a user account. The user clicks on the Delete button to the right of the screen in the tree.

This will bring up the following a confirmation dialog:

After the user clicks the Yes button, the user clicks the Save button to commit their changes and have the tree refresh to display the deleted change.

Editing a Screen User
The user can modify any existing screen permission on a user account. The user clicks on the Edit button to the right of the screen in the tree.

This will bring up a popup as seen below:

The user can then change the permissions for the specific screen. Finally, the user clicks the Save button to commit their changes and have the tree refresh to display the modified change.

A Note about Roles and Explicit Screen Permissions
If a user account has a role associated with it and the user account also has an explicit screen permission that is also part of a role. The explicit screen permission always has a higher priority over the role when enforcing the security model. This is a simple business rule and you could do more here to deal with concurrency issues between screens in roles and explicit permissions.

Wrap up
This should give you an idea as to how you can build a security infrastructure to provide roles and permissions. In the last post of this series we will see how this affects building the menu and enforcing the explicit permissions.

Advertisements
Categories: English Tags: ,

Application level Security – Part II (Database model)

August 25, 2010 1 comment

Now that we have covered business requirements and the usage scenario, let’s go further and look at the data model and what it takes to implement this.

The following is an entity-relationship diagram of the security portion of the system. These tables are all that are required to implemented the security requirements outlined in the previous series post.

Let’s review each table and see how each plays its part in the security model in the table below:

Table Name Purpose
sec_u_User Holds pertinent user information. Represents any user accessing the system.
sec_r_Role Defines the group of screens that can be rolled up into a role. A role can be associated with one or more screens.
sec_s_Screen Represents actual screens in the system.
sec_su_ScreenUser The explicit permissions for any given user at the screen level.
sec_sr_ScreenRole The permissions for a given role.
sec_ur_UserRole User can belong to multiple roles as well as roles can have multiple users.
sec_m_Menu Represents the menus in the system. Menus are associated with screens for navigation.
sec_uia_UserInstalledApplication In this system, there are multiple applications and user accounts can be granted access at the application level.
mr_xa_Application The system is comprised of multiple applications. An application can easily be associated as a Line Of Business (LOB) aspect of the system, e.g. Operations and Utility Billing would be two separate LOBs.

Hopefully, you can start to see how each piece plays its part. Not every table would be required in your scenario but I like to be able to control a lot of my security behavior via the database so that I don’t need to recompile and deploy with every little change.

In the next post we will examine screens and how they are implemented in the system.

Categories: English Tags: ,

Behaviors and Triggers in Silverlight

August 20, 2010 Leave a comment

Here are the slides and code samples from my talk at the Western North Carolina .NET Developers Guild.

Hope you enjoy.

Categories: English, Español Tags: ,

Seguridad en las applicaciones – Parte I (Historia)

August 19, 2010 Leave a comment

En las próximas entradas de blog, voy a hablar de cómo uno se puede implementar seguridad en una applicación de la cooperación. En esta entrada de blog, voy a definar los requisitos usarios de la applicación.

Esta va a ser una applicación compuesta. Va a usar Prism 2.0 utilizando Silverlight. La applicación tendrá muchos módulos que representan las líneas correspondientes de Business. Usando Prism y un marco de applicaciones se permite definir soluciones que se puede usar en todas las niveles de la arquitectura.

Cuando se inicia la applicación, el sistema va a exigir que el usario pones sus credenciales. Ya que estamos usando el Prism, solo dos módulos han bajado desde el internet: el módulo principal y el módulo de seguridad. Cuando el sistema ha aprobado el usarios, el sistema se obtiene las roles y permisos explícitos que pertenece el usario. El menu se cree dinamicamente. El menu pertenece al otro módulo que se llama, “Navigation”. El menu solo va a tener opciones a las pantallas que el usario tiene permiso.

El usario se puede pertenecer a un role que contiene varios pantallas pero si el usario también tienen un permiso explícito a la misma pantalla entonces el permiso explicito siempre manda y no la de el role. Asi podemos definar varios roles que tienen permisos globales pero si necesitamos tener un permiso explicito todavía se puede hacer.

Despué de autenticarse, el usario se puede hacer clic en el menu para abrir una pantalla.

El siguente mesa describe cómo se maneja cada permiso en el sistema cuando se construa el menu y cuando el usario se haga clic en las pantallas y toolbar:

Permiso Descripción
Se puede Crear? Si es verdadero, entonces la propiedad de “Visibility” del buton “Addicionar Nuevo” se establecerá en “Visible”; de lo contrario, la propiedad de “Visibility” se establecerá en “Collapsed”.
Se puede Borrar? Si es verdadero, entonces la propiedad de “Visibility” del buton “Borrar” se establecerá en “Visible”; de lo contrario, la propiedad de “Visibility” se establecerá en “Collapsed”.
Se puede leer? Si no es verdadero, ninguna opción del menu no se creará para esta pantalla. Si intentas de navegar desde una otra pantalla, entonces un cuadro de diálogo aparece con las siguientes letras: “No tienes acceso a esta pantalla ahora. Por favor consulte a su administrador de seguridad.”
Se puede Guardar? Si es verdadero, entonces la propiedad de “Visibility” del buton “Guardar” se establecerá en “Visible”; de lo contrario, la propiedad de “Visibility” se establecerá en “Collapsed”. Si no es verdadero, entonces ninguna comprobación sucia a ser aplicada cuando se trata de cerrar la pantalla.

En la próxima entrada de blog, vamos a repasar la base de data y lo que es necessario para implementarlo nuestra modelo de seguridad.

Categories: Español Tags: ,

Application level Security – Part I (Background)

August 19, 2010 2 comments

Over the next blog posts, I am going to be covering implementing security in an enterprise application. For this first post, I am going to define some user requirements of the application.

This will be a composite application. It will use Prism 2.0 in Silverlight. The application will have many modules that will represent corresponding lines of business. Using Prism and an application framework will allow defining solutions for some cross-cutting concerns. We can use these throughout all of the modules where necessary.

When the application starts, the first thing that will happen is the system will challenge the user to authenticate. Since we are using Prism, only two modules are downloaded at startup: the Shell module and the Security module. Once the user provides a valid username and password, the system will then obtain the roles and explicit permissions in which the user belongs. The menu is dynamically created. The menu is part of another module called, Navigation. The menu will only be created for screens that the user has been granted access.

The user may belong to a role that has several screens but if the user also has one of the screens as an explicit permission, then the explicit permission always wins over the role definition. This way we can have the ability to define general broad role definitions but then go back and override where necessary.

Once the menu has been created, the user can then click on any item in the menu since security has already been enforced at the authentication step.

The following table describes how the system will behave for each permission value when building the menu and interacting with the screen and toolbar:

Permission Description
Can Create? If true, then the Add New button’s Visibility property will be set to Visible; otherwise, the Visibility will be set to Collapsed.
Can Delete? If true, then the Delete button’s Visibility property will be set to Visible; otherwise, the Visibility will be set to Collapsed.
Can Read? If false, no menu is created for this screen. If you navigate from another screen, then a dialog is displayed with the following text, “Access to this option is not available to you at this time. Please see your Security Administrator.”
Can Write? If true, then the Save button’s Visibility property will be set to Visible; otherwise, the Visibility will be set to Collapsed. If false, no dirty checking will be enforced when trying to close the screen.

In the next post we will start taking a look at the database model necessary to implement this infrastructure.

Categories: English Tags: ,

¡Ya en español!

August 11, 2010 1 comment

Quería empezar escribiendo entradas de blog en español. Soy de Colombia pero fuí adoptado de bebe y crecí en los estados unidos. No aprendí hablar español hasta la universidad y que nadia en mi familia hablaba español. Espero que me pueden entender. Les prometo de tratar de escribir mis entradas de blog lo mejor que puedo. Voy a intentar poner todas mis entradas de blog en inglés y español.

Categories: Español

Behaviors and Triggers in Silverlight

August 6, 2010 2 comments

I will be doing a presentation this coming Tuesday, August 10 at the WNC .NET Developers Guild. Here is a summary of the presentation:

Since Silverlight 3 we have had the opportunity to work with Behaviors and Triggers. Most of our exposure has been limited to Blend since the bits come from the Blend application. In this presentation, we will analyze both Behaviors and Triggers and then look at what it takes to build a behavior and trigger from scratch. We will also discuss how we can use Behaviors and Triggers to support Model-View-ViewModel (MVVM) as well. Finally, we will look at where we can use Behaviors and Triggers in our applications in a practical approach. Instead of just showing simple animations, we will look at how we can use these powerful features to get component and logic re-use as much as possible.

Looking forward to it!