Custom Authorization

Custom Authorization

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


bhavener posted on Thursday, June 25, 2009

Rocky,

I have implemented Windows-based Authentication with Active Directory checking per your new book 'Expert C# 2008', but I am running into an issue with the authentication and wanted to ask you for a 'best practice'.

I have created both CustomPrincipal and CustomIdentity classes which descend from BusinessPrincipalBase and CslaIdentity (respectively). My custom authorization flow needs to go through the following:

1) Look at the custom User business object which lives in a property within my CustomIdentity class
2) Inspect one or more properties within the User business object against properties found in the business object being Created/Updated/Read/Deleted
3) Return the type-level authorization based on the results of comparing attributes of the current user to the BO in question

I know that the type-based authorization within CSLA is role-based and works in a fashion where each business object only needs to load roles once per application lifecycle and all CRUD operations are then authorized based on teh role of the User. What would you recommend for implementing the authorization I laid out above?

Any/all insights are much appreciated!

RockfordLhotka replied on Thursday, June 25, 2009

I think your only option is to override CanReadProperty() and CanWriteProperty() in a custom base class so you can call some more advanced method on your principal object that accepts the business object and role as parameters.

bhavener replied on Thursday, June 25, 2009

I actually don't have any property specific authorization needs - I am looking to handle all of this for CRUD operations. It would seem my best approach to create a custom base class with overrides the AllowCreate(), AllowGet(), AllowEdit(), AllowDelete(), but it looks like those methods are all 'static'??

RockfordLhotka replied on Thursday, June 25, 2009

You may need to create a parallel authorization object for that purpose.

 

Those methods have to be static, otherwise you’d be forced to create an instance of the object to find out if you are allowed to create an instance of the object :)

 

In 3.6 they aren’t on each business class, they are centralized in Csla.Security.AuthorizationRules. And what I’m suggesting then, is that you choose to not use the Csla.Security.AuthorizationRules per-type functionality, and instead create your own equivalent that operates on broader context information.

 

Though now that I say that, it occurs to me that what you are asking is for a per-instance AllowCreate() method – which is nonsensical, as you’ve obviously already created the instance and it is too late to find out you aren’t allowed to create the instance…

 

I suppose a per-instance AllowEdit() or AllowDelete() could make sense – and that is something you could add to your custom base class.

 

Rocky

 

Copyright (c) Marimer LLC