Windows Authentication and Roles Authorization

andrewrajcoomar posted on Sunday, August 23, 2009

Hi,

I'd like a little help on how to make CSLA work for Windows Authentication with the NT Security groups being used for Roles to authorize the users.

There are some limitations regarding using Session. The web admin group and peer-reviews strongly discourages the use of Session on server (farm/load balancing/scalability), and to some extent ViewState (controls viewstate allowed, but persisting objects such as ViewState("objEmployee") = oEmployee, is a no-no.). They allow some caching on the web server RAM or file system, or better yet caching using SQL.

My basis requirements for an intranet web application are:

1. Use Csla.ApplicationContext.User
2. Authenticate user using Integrated Windows Authentication.
3. Disable Anonymous acces on IIS.
4. Authorize user using pre-defined NT Security groups; if User.IsInRole(role).
5. Persist User's name and group during post-back (perhaps caching, controls/properties in MasterPage, or cookie as last resort).
6. Define other properties; roles collection; String(Of roles); Rollup Group Code, that need to be persisted also.
7. Add additional authorization to classes based on user Rollup Group Code.

Thanks,

Andrew

RockfordLhotka replied on Sunday, August 23, 2009

It is important to realize that Csla.ApplicationContext.User is just a way to get to HttpContext.Current.User in an ASP.NET environment.

In other words, if you are using Windows authn and authz, CSLA .NET does nothing for you - it just uses whatever principal you've set up - which would be the Windows principal/identity. So whatever techniques you use for any non-CSLA web app will work with Csla.ApplicationContext.User as well when using Windows mode.