I don't know what N2 is, sorry.
CSLA uses standard .NET concepts for most of its security. It relies on the standard .NET principal object, just like .NET itself. And if you use custom CSLA authentication then your code sets that standard .NET principal, which is the only way it works in .NET.
If you have some external (outside of CSLA) mechanism for managing your principal object then just tell CSLA to use Windows authentication. I followed the same model as ASP.NET - which is to say that if you tell ASP.NET or CSLA that you are using Windows authentication, then the assumption is that no extra work is required. Another way to put it is that "Windows" authentication really means "external" authentication - CSLA does nothing - it just assumes that you've taken care of getting the principal set at all times (on client and server).
Where CSLA goes beyond the standard security support is around per-property and per-type authorization. This doesn't interfere with the per-page authorization provided by ASP.NET - it is complimentary. And there is no support in Windows Forms or WPF at all, so it is entirely complimentary in those UI styles.
CSLA defines the IAuthorizeReadWrite interface for per-property authorization, and provides (in version 3.5) a set of static methods on Csla.AuthorizationRules for per-type authorization.
The problem is that Microsoft hasn't defined standard interfaces for authorization like they have for validation. So every framework out there either ignores the issue, or defines their own approach.
Assuming N2 is a UI framework of some sort, it is quite likely that they've defined some custom authorization scheme at the form/page and perhaps property levels. That wouldn't surprise me - certainly if I was creating a UI framework I'd do that sort of thing.
I found it: http://n2cms.com/
N2 Open Source ASP.NET CMS
N2 is a lightweight CMS framework that helps you build great web sites that anyone can update. Web content editors will enjoy a simple and enpowering web interface while developers can benefit from a discoverable and programmer friendly API.
I wonder how other portals behave with CSLA such as DotNetNuke and the Rainbow portal.
RockfordLhotka:
I don't know what N2 is, sorry.
CSLA uses standard .NET concepts for most of its security. It relies on the standard .NET principal object, just like .NET itself. And if you use custom CSLA authentication then your code sets that standard .NET principal, which is the only way it works in .NET.
If you have some external (outside of CSLA) mechanism for managing your principal object then just tell CSLA to use Windows authentication. I followed the same model as ASP.NET - which is to say that if you tell ASP.NET or CSLA that you are using Windows authentication, then the assumption is that no extra work is required. Another way to put it is that "Windows" authentication really means "external" authentication - CSLA does nothing - it just assumes that you've taken care of getting the principal set at all times (on client and server).
Where CSLA goes beyond the standard security support is around per-property and per-type authorization. This doesn't interfere with the per-page authorization provided by ASP.NET - it is complimentary. And there is no support in Windows Forms or WPF at all, so it is entirely complimentary in those UI styles.
CSLA defines the IAuthorizeReadWrite interface for per-property authorization, and provides (in version 3.5) a set of static methods on Csla.AuthorizationRules for per-type authorization.
The problem is that Microsoft hasn't defined standard interfaces for authorization like they have for validation. So every framework out there either ignores the issue, or defines their own approach.
Assuming N2 is a UI framework of some sort, it is quite likely that they've defined some custom authorization scheme at the form/page and perhaps property levels. That wouldn't surprise me - certainly if I was creating a UI framework I'd do that sort of thing.
Thanks a lot Rocky !
By the way, I just completed chapter 2 of Business Objects for .NET 2.0 and I am enjoying reading it very much.
From within CSLA .NET, I can control and customize Authentication very easily, but I have yet to dive into the area of Authoriation/Validation (which is still confusing me, because it talks about delegation and the like). I suppose more details will clarify this concept in the other chapters. I am such a slow reader !
I do not want to spend time and effort learning huge UI Framework like DNN, and seems like N2 is a good choice, if it works well with CSLA.
There has been many reports that several people used DNN with CSLA and also other tools like NHybernate (DAL) successfully.
It might be worth it to setup some kind of forum or directory to tell which UI and other Frameworks can be used easily/safely with CSLA .NET, and it will be based on users' experience.
Tarek.
Copyright (c) Marimer LLC