Sanity Check -Mixed Authentication and Authorization

Sanity Check -Mixed Authentication and Authorization

Old forum URL: forums.lhotka.net/forums/t/4185.aspx


Diz posted on Thursday, January 17, 2008

Background:
I'm working on porting a large legacy application into .net, using CSLA for the business layer.  

This is an intranet app - all users will be using the app from PCs which are on the domain; all users have domain accounts.    There are about 2,200 users of the legacy application so we'll have at least that.

We are building a web UI first, but eventually there will be a Windows Forms or WPF UI that cover certain areas of functionality for different groups of users. 

We're using CSLA 3.01, and .net 3.5. 

The web server communicates with an app server (hosting the business objects) using WCF.  

Database is Oracle.

As all users have domain accounts, our plan is to use Windows Authentication.   

Questions:
I have and have read the majority of the 2005 CSLA book, and both of the subsequent e-books.  I'm still confused however about the effect of different settings for CslaAuthentication tag.   All of the examples use Forms authentication so I don't know how this plays into Windows Authentication other than the notes in the book about Windows auth means removing the custom principal and identity classes.   

The legacy application has an existing set of tables which contain user names, roles, and a mapping table.   I'd like to use those tables if possible to control authorization in the business layer.  I've got some code that reads from there now and applies the rules in the business objects, and all is fine. 

Can I mix the two - Win Authentication and custom, db driven authorization?   Any gotchas that come to mind?

The desire is for us to create functionality allowing admins to tweak a role's  permissions for areas of the app, so I can't hard code the role checks on the business object methods like in the examples.    Mapping BOs to roles in the database just doesn't seem like the thing to do.  Has anyone been in the situation where these permissions had to be data driven?

Or am I thinking too granular - should I do the granular and dynamic authorization at the site map level and do some basic, coarse grained re-authorization in the business objects?

Lots of questions I know.   Thanks!



RockfordLhotka replied on Thursday, January 17, 2008

CslaAuthentication works much like the ASP.NET Authentication switch in web.config.

That is to say that setting the value to Windows tells CSLA to totally ignore the principal (other than returning it from Csla.ApplicationContext.User). In this mode CSLA assumes Windows (or something) is automatically authenticating the user and creating the principal and performing impersonation across any data portal calls. CSLA is hands-off.

Setting the value to Csla tells CSLA to do its own impersonation for data portal calls, so CSLA will move the principal from client to server on every call. A side-effect is that the principal must inherit from the CSLA base class.

If you want a hybrid, you'd want to use Windows authentication so CSLA is hands-off the principal. But then you'd still need to take steps to ensure that the default WindowsPrincipal is replaced by your custom principal (after Windows authentication/impersonation) so you get the hybrid principal.

JoeFallon1 replied on Thursday, January 17, 2008

I use Windows for single sign on - but I am not reading any app level roles or permissions from it.

In my Web app I allow both Windows log-in and standard UID/PWD log-in.

I have a derived class for Principal and Identity and 2 (or more) factory methods to fetch the Identity.

In my other code I check to see if they are using Windows to log in and I trap the networkID and domain values and pass them to my factory method. Then when I log-in the user I validate those values against my app's security database and read out the roles and permissions.

This way they do not have to enter a UID/PWD combination.

If they are not using Windows then they do have to enter these values. And then I do a standard log-in.

The end result of the 2 log-ins is the same - a CSLA principal filled with roles and permissions and user information.

This means that my security DB must have the same networkId and domain values that the user has in Windows. And they must be unique. The same row maps to the UID/PWD combination.

Joe

 

 

rvlc05 replied on Friday, February 29, 2008

Joe,

Could you provide some specifics on your handling this.  I'm facing a similar problem and would appreciate some input.

Paul

JoeFallon1 replied on Monday, March 03, 2008

Paul,

You can drop me a line with more specific questions if you like.

Joe

 

Copyright (c) Marimer LLC