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!
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.
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'??
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