Authentication/authorization of users with the rules in a custom database.

Topics: Web Client Software Factory
Sep 23, 2008 at 7:53 AM

The June 2007 WCFS ASP.NET 2.0 web app I've inherrited uses a custom role provider and a custom membership provider to get the user's role from a (custom) sql database.
The rule identifiers are defined in web.config:

 <securityConfiguration defaultAuthorizationInstance="RuleProvider" defaultSecurityCacheInstance="">
  <authorizationProviders>
   <add type="Microsoft.Practices.EnterpriseLibrary.Security.AuthorizationRuleProvider, Microsoft.Practices.EnterpriseLibrary.Security, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" name="RuleProvider">
    <rules>
     <add expression="R:Admin" name="AllowMenuItem1"/>
     <add expression="R:Admin" name="AllowMenuItem2"/>
    </rules>
   </add>
  </authorizationProviders>
 </securityConfiguration>

This allows all the 'Admin' users access to a specific page and the specific menu options are displayable which works fine.
However, now there is a requirement for the database to contain the 'rules' stating the displayability of all the menu items specific for a user (or user role).

So, arn't these web.config rules 'hard-coded' at design time and remain static with the app lifetime? How can i make these rules (string values) dynamic and and remain static after logon of the user? I know theres the business modules 'Configure'method, but isn't this executed on the application start (i.e. before the user login page even displays)?

Where can i get some further info on this? Any pointers would be great....

Sep 23, 2008 at 1:27 PM
What you're looking at is the out-of-the-box authorization mechanism. WCSF does not force you to use that mechanism.
The reason authorization rules are defined in the configuration file (at least one of the reasons) is that every module (this is the world of Composite applications) can define such rules independent from the rest of the application. 
Another benefit of doing it that way is that you rely on Enterprise Library authorization provider's ability to define and interpret complex rules, using AND or OR, etc. - you don't have to write all that yourself. 
I am curious what's behind your requirement for "dynamic" rules? In general, authorization rules don't change that often - usually you have some functionality that only users in certain roles can access.
What is usually dynamic is user's role assignments. Once the rules are in place, you can add/remove users to/from roles which may give you the "dynamic" effect that you're looking for. That's something you can easily code using ASP.NET Membership providers.

If you absolutely need it, you could change the authorization provider to use a database as the repository for your authorization rules (you may have to write your own provider - I can't say off the top of my head if MS ships one).

As far as reference/documentation on WCSF, I think the Hands-On-Labs and the reference implementation that come with WCSF are good sources. I can also point you to the notes I was taking when I was going through implementing authorization. My notes are somewhat work in progress as the project was drifted in another direction and I am yet to come back and put authorization logic in place. I have posted them here, but under the disclaimer that may not be 100% complete or accurate.
Giorgi
Sep 24, 2008 at 2:20 AM

Thanks for the detailed reply. Well, it looks like i'll have to write my own authorization provider (lots of research by me needed for this as i have no idea!?!).... thanks for your link by the way.

The idea I had was to have a well-defined menu structure for the app defined in the application code. The database will contain users, and each user will be assigned one-or-more roles. A role will have the information for every menu option: either its displayable, or not displayable.
The assignment of users/roles will be configuable by an 'administrator' user via the app.

When the user logs on, the rules for this particular person will 'load' thus populating the 'allowed' menu option. This will be saved (somehow?) thus be retained through the lifetime of the user's session.

This, in theroy, will allow me some flexibility when we choose to develop another application as this system can be re-used with a different menu structure: just redefine the menu structure and the rules allowing an option displayable or not.

This 'idea' is based in my readings (so far) of ASP.NET 2.0 and the WCSF. I'd like to use the WCSF as much as possible...

Am I heading in the right direction?

 Jack.