Skip to main content

Cloud

Visual studio 2005, Authentication and authorization using different combinations of roles and membership providers.

Introduction

Here I want to share my experience in evaluating some of the new security features of .Net 2.0.

The main two parts of security is authentication and authorization and in .Net we have brand new tools to automate this.

There are a lot of very good tutorials and other material on http://asp.net but all of the samples are using SQL server providers it means that all users and roles are stored on SQL server.

I was trying to investigate a possibility of using users and roles from AD. Keeping all your users in AD makes sense and not only for Intranet application (in this case users are already there).

Let’s consider an application that have Internal and External users, you want to keep the authentication consistent and at the same time you want to use the credentials of internal users from AD, because your internal users want to use their credential they use every day to log on to Windows, but at the same time the users from outside should be able to register and log on the same way the Internal users do.

What is new in .Net 2.0

The new version of .Net 2.0 includes very rich authentication and authorization framework for most common business security tasks.

The framework includes:

  • On the middle layer: membership and role providers
  • On the UI Layer: Login, password, create user wizard and other controls, grouped under Login in the toolbox.
  • On the data layer: Visual studio 2005 is shipped with SQL server 2005 express edition and aspdb.sql that allows to create SQL database with the structure that works for SQL providers. Additionally all business templates (Personal website, TimeTracker, Clubwebsite) are coming with .mdf files that have the same membership schema (tables, functions, stored procedures).

The whole idea of providers is not new, you could do some of the functionality if you use EA (enterprise library) with VS 2003 but now it’s included in the .Net framework and save much more time for developers.

The first of all, the main advantage of using the providers approach is that you can always write your own provider if you are not happy with out the box providers and you will be a able to use the same user controls. Another huge advantage is that are all configurable, so if you need to change some of the parameters you just change it in web.config.

Membership and Roles Providers

Membership and role providers are working together and also used by other providers, for example map providers (site navigation) and personalization providers.

Here is an example how all of this works together: You create some users using ASP.Net configuration tool. Using the same tool you create roles and manage roles/users relationship. Then you grant some of the created roles/users access to same folders/pages. Now if you use sitemap provider with navigation controls (sitemap path, menu, treeview) all security will be implemented without writing a line of code. On the navigation control the logged user will see only pages he is allowed to see according to his role membership.

All this is a really good feature but here is the main disadvantages I fond:

  • It works as expected only with SQL providers. When I tried to use some other role and membership providers some of the features don’t work and don’t give you any clue. The configuration console doesn’t work at all with AD RoleProvider, it turns out that AD role provider (WindowsTokenRoleProvider) is read only it means that it assumes the user role membership based on Windows roles. But even if I can’t create new roles (windows groups) with this provider I still should be able to change the access security for different windows groups. Instead of that the tool tells me something like “WindowsTokenRoleProvider is the read only provider, use SQLroleProvider instead”.
  • If something is wrong with the provider or in web.config file it’s not easy to figure out the problem. The configuration tool usually tells something “Error occurred try again later”. So when I tried AD membership provider the only way to make it work was to try different parameters (the parameters from MS doc don’t work).
  • The ASP.Net configuration tool is very unstable and sometimes is very slow. But if you are using SqlRoleProvider this tool is the only way to create and manage the roles unless you are ready to make the changes directly inn the database.

Membership providers: (System.Web.Security namespace) all of the membership providers inherit fromSystem.Web.Security.MembershipProvider.

The providers are used to work with “members” (users) authenticate users, create a new users, change user info and passwords.

  • SqlMembershipProvider: works with aspnetdb database (the aspnetdb can be created using Aspnet_regsql.exe tool), or any other db that has necessary tables and stored procedures). This provider is used in all MS examples and demo and works pretty good with ASP.Net configuration tool.
  • ActiveDirectoryMembershipProvider: Uses AD users to authenticate users. ASP.Net configuration tool can create a new user in AD and manage roles stored in SQL database but managing access rules doesn’t work. The way both of this providers work together is not a straightforward because users are created and stored in two places AD and SQL server. Roles and users/roles relationship are stored in the SQL server. But in general to use this provider a developer has to be prepared to write additional code for authorization.
  • AuthorizationStoreRoleProvider: Uses Authorization Manager (AzMan) to store roles and users/roles membership. You can use AzMan console (Win 2003 Administrative tools) or ASP.Net configuration console to manage roles.

With all the variety of providers it’s not obvious what combination of providers will work together. Some of them don’t make sense at all. Some combinations won’t work together. Here I tried to summarize all possible combinations of providers.

Membership

Role

SqlMembershipProvider

ActiveDirectoryMembershipProvider

SqlRoleProvider

This combination is used in all MS samples and pretty straightforward.

Works only for Forms authentication.

The only combination that works with ASP.Net configuration tool.

Forms authentication: User authenticated against AD but the roles are stored in SQL server, it means that all user names are stored in two places AD and SQL.

Windows authentication: The user name is windows user in format DomainUsername the only way to make this work if you make the changes in the SQL database directly.

WindowsTokenRoleProvider

This combination doesn’t make sense, there is no way for Windows to know about users from SQL.

Makes sense only with Windows authentication, in this case the “Roles” are Windows groups user belongs to. But I couldn’t make it work with sitemap provider looks like it doesn’t recognize the windows groups.

AuthorizationStoreRoleProvider

This combination doesn’t make sense, authorization manager works only with windows users.

Can work with Windows and Forms authentication.

The main advantage of using this combination is that you don’t need SQL database to store the roles and membership information you can use XML or AD storage.

You don’t need to use ASP.Net configuration tool to manage the roles.

Here is the example of config information for membership providers from web.config

<membership defaultProvider="AspNetActiveDirectoryMembershipProvider">

<providers>

<add connectionStringName="aspnetdb"

applicationName="WebSite1"

enablePasswordRetrieval="false"

enablePasswordReset="true"

requiresQuestionAndAnswer="true"

requiresUniqueEmail="false"

passwordFormat="Hashed"

maxInvalidPasswordAttempts="5"

passwordAttemptWindow="10"

minRequiredPasswordLength="1"

minRequiredNonalphanumericCharacters="0"

name="aspnetdb" type="System.Web.Security.SqlMembershipProvider" />

<add connectionStringName="ADService"

connectionUsername="Test"

connectionPassword="Password1"

enableSearchMethods="true"

minRequiredPasswordLength="1"

minRequiredNonalphanumericCharacters="0"

name="AspNetActiveDirectoryMembershipProvider"

type="System.Web.Security.ActiveDirectoryMembershipProvider"

applicationName="WebSite1"/>

</providers>

</membership>

Role Providers: all of them inherit from System.Web.Security.RoleProvider

  • SqlRoleProvider
  • WindowsTokenRoleProvider
  • AuthorizationStoreRoleProvider

Here is the example of the providers in web.config

<roleManager defaultProvider="AuthorizationStoreRoleProvider"

enabled="true"

cacheRolesInCookie="true"

cookieName=".ASPROLES"

cookieTimeout="30"

cookiePath="/"

cookieRequireSSL="false"

cookieSlidingExpiration="true"

cookieProtection="All" >

<providers>

<add

name="WindowsProvider"

type="System.Web.Security.WindowsTokenRoleProvider"

applicationName="WebSite1"/>

<add

name="aspnetdb"

type="System.Web.Security.SqlRoleProvider"

connectionStringName="aspnetdb"

applicationName="WebSite1"/>

<add name="AuthorizationStoreRoleProvider"

type="System.Web.Security.AuthorizationStoreRoleProvider"

connectionStringName="LocalPolicyStore"

applicationName="WebSite1" />

</providers>

</roleManager>

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Dave Scheele

More from this Author

Follow Us