What is the best way to implement authorization/authentication

What is the best way to implement authorization/authentication

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


detritus posted on Thursday, September 11, 2008

Dear All,

I'm designing my first CSLA.NET based project. I've done a lot of reading on the framework (which is not easy when the framework itself moving forward fast while I trying to catch-up) and I'm not sure how to do couple of things. I'll appreciate if somebody help me on these:

In the application, while the "user" has it's usual meaning (authentication), it's must be linked to a "Card" business entity. The application defines all kinds of cards with their detail data (phones, addresses, etc), the users of the application should be linked to their cards.
For example, if I have an admin as an application user, I must have a corresponding Admin card.

We also don't want to implement a full authentication system having one already with .NET (ASP.NET Membership) but not sure how to integrate that with CSLA.NET and our Card business object. I've seen wrapper CslaMembershipProvider and CslaRoleProvider classes posted in this forum but I think these solves the remoting problem rather than making user a business object.

Nothing is written in stone yet, if anybody here thinks I'm doing something wrong or there is an easier / better way to do it please let me know.

Not trying to make things more complex but having a solution that integrates (or can integrate with a small change) with X single-sign-on solution will be a bonus. I don't have any experience with one yet, please let me know what I should expect/do.

Thanks in advance,

Sinan



JoeFallon1 replied on Thursday, September 11, 2008

I have a large web app (been using CSLA since 1.x and .Net 1.1).

So I do not use the ASP.NET Membership provider as it didn't exist when I got started.

I use custom Principal and Identity classes:

<Serializable()> _
Public Class MyUser
 
Inherits Csla.Security.BusinessPrincipalBase

<Serializable()> _
Public Class MyBusinessIdentity
  Inherits Csla.ReadOnlyBase(Of MyBusinessIdentity)
  Implements IIdentity

With these 2 classes you can make your user code as complex or simple as you need. You can also create other objects inside your login procedure and "carry them around with you" as you keep the Principal in Session. So your Card business object could be fetched when you fetch your Identity and then you can expose it to the world the same way other things like Roles are exposed. And it is now available on every hit.

Single sign on is just having a system or screen that captures the Windows ID and then calls your Principal to perform login based on the passed in ID. So you get to write whatever code you need to validate the WindowsID. e.g. hit a local DB with the Name as the userid, or hit a company DB that maintains these IDs, or hit the network itself to ask directly from the store of IDs.

Once you are convinced the user is who they say they are, then you load up roles and permissions and Cards the same way you did when they used a username and password.

Joe

detritus replied on Friday, September 12, 2008

Hi Joe,

I actually though about that before but doing all the things ASP.NET membership already does seemed wrong. I also though about modifying the source codes for ASP.NET providers to make my custom providers, but this may couple security system and my application more than I like.

Anyway, thanks for the thought.
Sinan

Copyright (c) Marimer LLC