My website application requires 3 different ways to authenticate a user. The first is through the standard username, password with forms authentication. The second logs someone in if a unique id, passed in the query string, is validated, so basically using forms authentication again. The third is via WCF.
My question refers to the first two techniques. I want my business objects to be able to know and treat users differently depending on how they were authenticated. The business objects are secured using the CSLA roles based approach (v3.8.3). I’m thinking I could add some new methods to the AuthorizationRules class, e.g.
private static void AddObjectAuthorizationRules()
AuthorizationRules.AllowAuthTypeGet(typeof(MyObject), “PasswordLogin”, “UrlToken”);
Then the methods could check the Authentication Type property. However I see that Csla uses this property so perhaps I might break CSLA if I do this.
I assume that my requirements are not unusual and therefore there may be a solution to work with CSLA. I’d appreciate a bit of guidance about this and any lateral suggestions that might meet my needs.
You have to seperate authentication from authorization - they are very different things.
Authorization is simply making use of the user's identity (and roles, etc) to decide whether the user is allowed to do certain things. This pre-supposes that you know the user's identity (authentication), but otherwise has nothing to do with authentication.
Authentication is the process of identifying and verifying the user so you know the user's identity (and roles, etc).
CSLA doesn't really care how you authenticate the user. It uses the .NET principal object for authorization, and relies entirely on that value. There are many, many ways to set the .NET principal. CSLA doesn't care which one you use, or even if you use several within the same app.
CSLA has an authorization system, which is reflected by the code snippet in your post. That has nothing to do with authentication, and should be consistent regardless of how a user was authenticated. This works completely off the user's roles list.
In CSLA 4 however, authorization is much more flexible, and can take into account more than just the user's roles. It is very easy in CSLA 4 to leverage other properties of the principal or identity objects, or other ambient objects within the execution context. This was relatively difficult prior to version 4, and my recommendation prior to CSLA 4 is to try and get any required values into the user's roles list so you can use standard role-based authorization.
Copyright (c) Marimer LLC