Ideas for authentication?

ianinspain posted on Tuesday, November 07, 2006

Hi there,

I wonder if anyone can help ... i have having some issues with implementing Authentication/Security... from what i understand ... each BO will implement authentication i..e. Who can access me? What can they do to me etc

I hope i am right on that.... I was planning on bring this sort of information from a table(db).... so i think i am ok there...

But then i was thinking my application needs a way of getting more information into the DB about new rights, permissions, new users and what they can do etc etc.... so would i be going down the same road here and use a Business Editable Base object where I can do CRUD which would effectively add new information into a security table which other BO's would use to decide weather a user has permissions to an object etc..

Any ideas and thoughts on this would be really appreciated

Thanks in advance

Ian

ianinspain replied on Tuesday, November 07, 2006

ermmm i just had another thought :-) .... within the authentication methods of each business object... what would be the best way of authenticating this user, using another Business Object to find out if this user has the rights needs for the specific task/behavoir that he/she is trying to perform??

Authentication has me thrown a little :-)

Any comments or advice..

Thanks

Ian

ajj3085 replied on Tuesday, November 07, 2006

Usually you use the IPrincipal.IsInRole method to determine if a user has access.  Role based access is the most common way to handle this.

To actually load the roles which are allowed to perform functions, you may want an internal class that handles this for you. 

Then your authentication is usually WindowsPrincipal or some custom principal which you create.

SonOfPirate replied on Tuesday, November 07, 2006

The typical way this is done is via the good ol' Access Control Lists (ACLs).  In a CSLA app, this would be a BO that retrieves your security information from the DB and performs the authentication by looking up the required permissions in the list of rights (or roles) that have been granted to the user.

So, your custom IPrincipal object would have a child collection of rights or roles.  When instantiating the collection, pass the parent object (IPrincipal) to the constructor and use whatever primary key field you have to perform the query on the DB and get the records for that user.  Then, is the IsInRole() method, you can simply call myACL.Contains(role) - or something like that.

If you want to get more specific and set permissions based not only on role but per method or something, just add that as another column in your DB and a property in your list item object then make you collection handle using that as part of the lookup too.

You could get more involved by having both grant/deny permissions so that you would change your code to query the collection with the role, property or method name and either return an enum indicating granted/denied or pass which you are interested in as another parameter.

Anyway, you can get as complex as you want or keep it a simple lookup list of roles.

The reverse side of this, if you want it to support built in principals like WindowsPrincipal for an "integrated" type of thing, would be to have a master ACL that accepts the IPrincipal and the role you are attempting to authorize.  The collection would look use the IPrincipal.Identity.Name to identify the user and lookup the role based on that.  Then you are not limited to just using a custom principal object.

Hope that helps.

guyroch replied on Tuesday, November 07, 2006

I think you're confusing Authentication (user/password) and AuthorizationRules (what are my roles).

You should take a look the the PTracker code sample Rocky provides.

 

ianinspain replied on Tuesday, November 14, 2006

Ok thanks all... i am going to take another look at it...

Thanks again

Ian