Integrated security questions

jgk1701 posted on Tuesday, August 29, 2006

Environment:

Windows 2003 app server; IIS hosted remoting application

SQL Server on another machine

CSLA framework version 1.52

Requirements:

Virtual directory hosting remoting application must not allow anonymous access. Only allowed authenticated domain users can access business objects. The worker process impersonates domain account DOMAIN\AppServerAcct for sql server access (this allows for connection pooling).

What's working:

The application pool assigned to the remoting app has the application pool identity account set to DOMAIN\AppServerAcct. The sql server is set to allow this account to login. The worker process can log into sql server and retreive/update data.

What's not working:

I have disabled anonymous access on the virtual directory, and checked Integrated Windows authentication. In both app config and web config files, entries are present for for setting Authentication to Windows. However, the remoting app is allowing everyone and their dog to access business objects. Any ideas as to what I am missing?

ajj3085 replied on Wednesday, August 30, 2006

Are you checking permissions in your factory methods? You should be calling your CanCreate() method in the NewObject factory method, for example.

Additionally, you may want to contact Active Directory to verify the user exists on the domain. Use the DirectoryServices namespace to do this. I'm not sure however if that's how you're supposed to implement your own Integrated Security or not though..

ajj3085 replied on Wednesday, August 30, 2006

Well the AD check would be teh first thing your app does... before it uses any business objects at all.

The method I described occurs before the user gets to the data portal.. your factory method would look like this:

public static MyBO GetMyBO( int boId ) {
   if ( !CanFetch() ) {
      throw new SecurityException( "User cannot load BO." );
   }

   return DataPortal.Fetch<MyBO>( new IdCriteria( boId ) );
}

What is wrong with that approach?

jgk1701 replied on Wednesday, August 30, 2006

Now I see what you and Rocky are saying. I was trying to disallow users from accessing the data portal based on NTFS permissions, and from what I read from Rocky below that's not how it works.

Thanks for your input.

Jeff

RockfordLhotka replied on Wednesday, August 30, 2006

jgk1701:
What's not working:

I have disabled anonymous access on the virtual directory, and checked Integrated Windows authentication. In both app config and web config files, entries are present for for setting Authentication to Windows. However, the remoting app is allowing everyone and their dog to access business objects. Any ideas as to what I am missing?

All CSLA .NET and the data portal do is ensure that you have the same user Principal/Identity object on client and server. The framework doesn't do authorization at all - or authentication either for that matter. It merely makes the user's identity available to you so you can do your own authorization.

The reason all your users can get through, is because they all have valid Windows accounts. It is up to you to authorize users by role or whatever you choose. Typically this is done by calling

System.Threading.Thread.CurrentPrincipal.IsInRole(role)

Though such calls are often wrapped into Shared/static helper methods like CanGetObject() or something like that, so you can more easily call them where needed from within your class.

jgk1701 replied on Wednesday, August 30, 2006

OK, thanks for clearing that up. I was under the impression that when using Windows authentication, IIS was going to allow or deny access to the app based on the permissions set on the virtual directory. This is not correct as I gather from your response. As long as you have a valid Windows account, then the permissions set on the virtual directory do not come into play.

Thanks,

Jeff

cultofluna replied on Monday, October 02, 2006

Sorry, this is not a real CSLA question, but why does System.Threading.Thread.CurrentPrincipal not work? When I use the IsInRole, there are no roles and also the Identity seems to be unavailable.
Do I need to set my identity first at some point in my app?

Thanks for any answers,

Regards,

SonOfPirate replied on Monday, October 02, 2006

check the instance type returned by System.Threading.Thread.CurrentPrincipal. My guess is that it is a GenericPrincipal which will explain the behavior you are seeing. This will be the case if you allow anonymous access. You have to "force" Windows to perform authentication or it won't.

cultofluna replied on Monday, October 02, 2006

That's exactly what I'm seeing. So how do I force Windows authentication? Setting app.config CslaAuthentication to Windows isn't enough :)
I believe the WindowsIdentity class may do the trick, but should I use this instead of Thread.CurrentPrincipal? Or should I set CurrentPrincipal, but then, what is the best position to set it?

Thanks so far!

SonOfPirate replied on Monday, October 02, 2006

If it's a web app, you can force authentication thru IIS (or the web.config) file. If you are using custom authentication (such as CslaAuthentication in a Windows app), then you will need to set the CurrentPrincipal to your custom principal object once you've authenticated the user and then you can make use of it in other places in your code.