Archive

Posts Tagged ‘Security’

Getting the user credentials both in and out of the browser in Silverlight

January 15, 2011 6 comments

Silverlight is quite powerful and gives you a lot of flexibility. You can have your application run in the browser our you can opt for a more Windows like experience and run your application Out of the Browser. One of the frustrations that I have encountered in the past, is trying to write my code so that it supports both.

A common scenario is trying to get the current user signed into the computer. With Silverlight running in the browser, this is quite easy by passing information into the InitParams. But this becomes quite a bit more difficult when you are trying to do the same Out of the Browser.

The following is a screen shot of retrieving the currently signed in user from a web page:

Current User - Browser

In discussing this issue with some colleagues of mine, it came to me that solving the problem for out of the browser could be quite simple if we allow for elevated priviledges. My solutions was to use COM Automation.

The following is the same application now running out of the browser displaying the currently signed in user:

Current User - Out Of Browser

In this post we will go through getting the currently signed in user from the hosting web page and then via COM.

We will start with the web page first. First of all, you need to have a web page that has code-behind associated with it. The default behavior of Visual Studio is to create an ASPX page without any code-behind. The following is a code snippet of the hosting web page:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="TestComInterop.Web.Default" %>




    TestComInterop
    <!--
    html, body {
	    height: 100%;
	    overflow: auto;
    }
    body {
	    padding: 0;
	    margin: 0;
    }
    #silverlightControlHost {
	    height: 100%;
	    text-align:center;
    }
    
-->
    <script src="Silverlight.js" type="text/javascript"><!--mce:0--></script>
    <script type="text/javascript"><!--mce:1--></script>


<form id="form1" style="height: 100%;">
<div id="silverlightControlHost"></div>
</form>


I posted the whole in its entirety but there is only one element that you need to pay attention to with the ID=”InitParameters”. We will use this Literal tag to inject our current user from the code-behind.

Now let’s look at the code-behind:

public partial class Default : System.Web.UI.Page
{
	protected void Page_Load(object sender, EventArgs e)
	{
		Response.Cache.SetCacheability(HttpCacheability.NoCache);
		ConfigureSilverlightDeploymentSettings(InitParameters);
	}

	private static void ConfigureSilverlightSettings(Literal settings)
	{
		StringBuilder sb = new StringBuilder();
		sb.Append("<param name=\"InitParams\" value=\"");
		sb.Append("UserName");
		sb.Append("=");
		sb.Append(System.Security.Principal.WindowsIdentity.GetCurrent().Name);
		sb.Append("\" />");
		settings.Text = sb.ToString();
	}
};

Basically, I am turning off caching in the Page_Load method as well as calling the ConfigureSilverlightSettings method. It is in this method that we dynamically construct a Param with the name of “InitParams”. This is the mechanism that Silverlight gains access to parameters we wish to pass to it externally. We then just create a key/value pair setting the UserName value to GetCurrent().Name property from System.Security.Principal.WindowsIdentity.

The last piece of this puzzle is to see how this is accessed from Silverlight. This leads us to the App.xaml.cs file. For brevity, I am only going to show you the Application_Startup method as it is the only thing that concerns us:

private void Application_Startup(object sender, StartupEventArgs e)
{
	this.RootVisual = new MainPage();

	if (Application.Current.IsRunningOutOfBrowser)
	{
		if (AutomationFactory.IsAvailable)
		{
			using (dynamic wScript = AutomationFactory.CreateObject("WScript.Network"))
			{
				this.UserName = string.Format(@"{0}\{1}", wScript.UserDomain, wScript.UserName);
			}
		}
	}
	else
	{
		// We are running in the browser and can use the HTML-Bridge to get our user.
		this.UserName = e.InitParams.ContainsKey("UserName") ? e.InitParams["UserName"] : "UNKNOWN";
	}

	Application.Current.Resources.Add("UserName", this.UserName);
}

I am showing you the solution for both but I want you to first focus on the else condition. Basically, we are just pulling the key/value pair from the InitParams object off of the StartupEventArgs object. I also ensure that we get a dummy value if no “UserName” exists as a key.

The final step is to add this to the Application.Current.Resources dictionary so that we can access it globally. You may have your own mechanism or may want to use your favorite DI/IOC container to handle this as well.

This really completes the web page workflow. Since we have the code for the App.xaml.cs file, let’s examine how this is accomplished out of the browser. If you look above, we are first checking to be sure that the application IsRunningOutOfBrowser. We also check to be sure that we have elevated priviledges to use COM Automation. Once this is established the we simply create a “WScript.Network” object. This allows us to use the Windows Script API and access the networking stack. Finally we format a string so that it looks just like what we would get from the web page.

The last piece of the puzzle is displaying the message box. The code-behind from the MaingPage.xaml file has the follwoing content:

public partial class MainPage : UserControl
{
	public MainPage()
	{
		InitializeComponent();
	}

	private void Button_Click(object sender, RoutedEventArgs e)
	{
		if (Application.Current.IsRunningOutOfBrowser)
		{
			MessageBox.Show(string.Format("OOB Current User: {0}", Application.Current.Resources["UserName"]));
		}
		else
		{
			MessageBox.Show(string.Format("Browser Current User: {0}", Application.Current.Resources["UserName"]));
		}
	}
};

I only added a condition test so that the screen shots would be different. The rest is just accessing the Resources property off of the Application.Current object. Again, you could do this quite differently using DI/IOC in your code.

I have zipped up a sample application to download here.

Hope this helps….

Seguridad en las applicaciones – Parte III (Pantallas)

September 1, 2010 Leave a comment

En las dos entradas de blog pasados hemos visto los requisitos y la base de data. Hemos mirado los papeles y permisos explicitos y cómo juntar las pantallas con los permisos. Vamos a ver las pantalla en el sistema que nos permite configurar la seguridad para nuestra usarios.

Mantenimiento de un Papel
Vamos a ver la pantalla de Mantenimiento de un Papel. Esta pantalla maneja todos los papeles en el sistema. Usarios se pueden crear, cambiar, o borrar papeles. El siguente es un imagen de la pantalla Mantenimiento de un Papel:

Adición de un Papel
Para adicionar a un papel, el usario haga clic sobre el botón “New” que queda en la parte a la izquierda del toolbar:

Esto traerá la siguente pantalla:

En mi escenario, el sistema tiene varios módulos que representen diversas líneas de negocio. El usuario puede escoger cuál applicación él quiere que el papel va a pertenecer. También él escribe un nombre para el nuevo papel. El usario haga clic sobre el botón “Save” para guardar sus cambios.

Colocando Pantallas a un Papel
El usuario asocia las pantallas para un papel. Con el nuevo papel que el usuario ha creado, el usario haga clic sobre el botón “Add New” que queda en la parte a la derecha del titulo “Screen” en la matrix:

Esto traerá la siguente pantalla:

El usuario puede multi-selecciona las pantallas para agregar al papel actual. NOTA: Solamente las pantallas que no se asocian ya a esto querrán aparecer en el selector. Una vez que el usuario cierra la pantalla del selector, el usuario puede asignar los permisos apropiados como se muestra abajo:

El usario haga clic sobre el botón “Save” para guardar sus cambios.

Borrar un Papel
El usuario tiene la capacidad de quitar papeles existentes. De acuerdo con requisitos del negocio, el usuario debe primero quitar todas las pantallas asociadas a este papel. Para borrar un papel, el usario haga clic sobre el botón “Delete” en la barra de herramientas como se muestra abajo:

Esto traerá la siguente pantalla de confirmación:

El usario haga clic sobre el botón “Save” para guardar sus cambios.

Borrando Pantallas de un Papel
Según lo indicado previamente, antes de que un papel pueda ser borrado, todas las pantallas deben primero ser quitadas. El usario haga clic sobre el botón “Delete” a la derecha del papel en la matrix como se muestra abajo:

Esto traerá la siguente pantalla de confirmación:

El usario haga clic sobre el botón “Save” para guardar sus cambios.

Seguridad del Acceso de Usuario
La pantalla de seguridad del acceso de usuario proporciona la capacidad de controlar el acceso de usuario a todas las pantallas en el sistema. Un usuario puede asignar papeles existentes a las cuentas de usuario o definir permisos explícitos de la pantalla. Lo que sigue es un imagen de pantalla del usuario “matt” y sus permisos:

Adición de un Papel de Usario
Al agregar a un usuario a un papel, el usuario haga clic sobre el botón “New” al derecho del título de los papeles de usuario en el árbol.

Esto traerá la siguente pantalla:

El usuario primero escogerá qué Applicación él quiere para filtrar los papeles existentes y después selecciona el papel apropiado. NOTA: Solamente los papeles que no se han asociado ya a esta cuenta de usuario serán exhibidos. Finalmente, el usuario haga clic sobre el botón “Save” para guardar sus cambios y para que el árbol refleja el cambio también.

Borrar un Papel de Usario
El usuario tiene la capacidad de quitar papeles de cuentas de usuario. El usuario haga clic sobre el botón “Delete” a la derecha del título del papel en el árbol.

Esto traerá la siguente pantalla de confirmación:

El usuario haga clic sobre el botón “Save” para guardar sus cambios y para que el árbol refleja el cambio también.

Cambiando los Permisos de una Pantalla en un Papel de Usario
El usuario tiene la capacidad de eliminar cualquier permiso de la pantalla para un papel. El usuario haga clic sobre el botón “Edit” a la derecha del título del papel en el árbol.

Esto traerá la siguente pantalla:

El usuario puede cambiar los permisos para la pantalla especificada. NOTA: Esta acción no cambia el papel. El sistema comprobará para saber si hay un permiso explícito existente y para abrirlo. Si el sistema no puede encontrar el permiso correspondiente de la pantalla, creará un nuevo para la cuenta de usuario. Finalmente, el usuario haga clic sobre el botón “Save” para guardar sus cambios y para que el árbol refleja el cambio también.

Adición a una Pantalla al Usario
Al asignar permisos de la pantalla a una cuenta de usuario, el usuario haga clic sobre botón “New” al derecho del título explícito de los permisos de la pantalla.

Esto traerá la siguente pantalla:

El usuario primero escogerá qué Applicación él quiere para filtrar las pantallas y después selecciona la pantalla apropiada. NOTA: Solamente las pantallas que no se han asociado ya a esta cuenta de usuario serán exhibidos. Finalmente, el usuario haga clic sobre el botón “Save” para guardar sus cambios y para que el árbol refleja el cambio también.

Quitando una Pantalla de un Usario
El usuario tiene la capacidad de quitar permisos de la pantalla de una cuenta de usuario. El usuario haga clic sobre el botón “Delete” a la derecha de la pantalla en el árbol.

Esto traerá la siguente pantalla de confirmación:

El usuario haga clic sobre el botón “Save” para guardar sus cambios y para que el árbol refleja el cambio también.

Cambiando un a Pantalla de un Usario
El usuario puede cambiar cualquier permiso existente de la pantalla en una cuenta de usuario. El usuario haga clic sobre el botón “Edit” a la derecha de la pantalla en el árbol.

Esto traerá la siguente pantalla:

El usuario puede cambiar los permisos para la pantalla específica. Finalmente, el usuario haga clic sobre el botón “Save” para guardar sus cambios y para que el árbol refleja el cambio también.

Una Nota sobre los Papeles y los Permisos Explícitos de una Pantalla
Si una cuenta de usuario tiene un papel asociado a ella y la cuenta de usuario también tiene un permiso explícito de la pantalla que sea también parte de un papel. El permiso explícito de la pantalla tiene siempre una prioridad más elevada sobre el papel al hacer cumplir el modelo de seguridad. Esto es una regla de negocio simple y usted podría hacer más aquí para ocuparse de las ediciones de la concurrencia entre las pantallas en papeles y los permisos explícitos.

Fin
Esto debe darle una idea en cuanto a cómo usted puede construir una infraestructura de la seguridad para proporcionar papeles y permisos. En la última entrada de blog de esta serie veremos cómo ésta afecta a construir el menú y a hacer cumplir los permisos explícitos.

Categories: Español Tags: ,

Seguridad en las applicaciones – Parte II (Base de Data)

September 1, 2010 Leave a comment

Ya que hemos cubierto los requisitos del negocio y los escenarios de los usarios, vamos a mirar a los componentes de la data y lo necessario para implementar.

El siguente es un diagrama de la base de data de seguridad del systema. Estas mesas son todo lo necessario para implementar un sistema de seguridad que hemos hablado en las entradas de blog anteriores.

Vamos a ver que significa cada mesa y el papel que lleva para implementar seguridad en el sistema:

Nombre de la Tabla Propósito
sec_u_User Lleva a cabo la información de usuario pertinente. Representa a cualquier usuario que tiene acceso al sistema.
sec_r_Role Define el grupo de pantallas que se puedan juntar en un papel. Un papel se puede asociar a una o más pantallas.
sec_s_Screen Representa las pantallas reales en el sistema.
sec_su_ScreenUser Los permisos explícitos para cualquier usuario al nivel de la pantalla.
sec_sr_ScreenRole Los permisos para un papel.
sec_ur_UserRole El usuario puede pertenecer a los papeles múltiples tan bien como los papeles pueden tener usuarios múltiples.
sec_m_Menu Representa los menús en el sistema. Los menús se asocian a las pantallas para la navegación.
sec_uia_UserInstalledApplication En este sistema, hay muchos applicaciones y las cuentas de usuario se pueden tener el acceso en el nivel de la applicación.
mr_xa_Application El sistema contiene muchos muchos applicaciones. Cada applicación es como un departamento en un negocio. Por ejemplo, operaciones y ventas serian dos applicaciones separadas en el sistema.

Espero que ya puede comenzar a ver cómo cada pedazo toma su papel. No cada tabla sería requerida en su escenario pero me gusta tener el control de la seguridad del sistema desde la base de data. Asi no tengo que recompilar ni mandar codigo por un cambio de seguridad en el sistema.

En la entrada de blog siguiente veremos las pantallas y cómo se ejecutan en el sistema.

Categories: Español Tags: ,

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.

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: ,

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: ,