I want to use property level auhorization security in a fashion similar to the following:

  Public Property Name() As String
    Get
      CanReadProperty()
      Return m_name
    End Get

    Set(ByVal Value As String)
      CanWriteProperty()
       m_name = Value
      End If
    End Set

  End Property

I found that EntityBase2 exposes a virtual (overridable) method

PreProcessValueToSet()

I can override this method in an entity's (partial) class to inject my

CanWriteProperty()

calls for the properties I want to implement the authorization security for.

My problem is that EntityBase2 does not use an equivelent

PreProcessValueToGet()

method to be called BEFORE returning the value of a field.

Is it possible to add such a method in LLBL's EntityBase2. The method

PreProcessValueToGet()

would be a no-op unless it is overridden in the entity's (partial) class

You can add this in the entityBase template.

Although generally I think permission checking is a business logic task, that should be implemented in a another level than the business object classes.

Walaa wrote:

You can add this in the entityBase template.

Should I use an include template for this or create my own custom copy of the template

Walaa wrote:

Although generally I think permission checking is a business logic task, that should be implemented in a another level than the business object classes.

Agreed and this is exactly where I am checking my Entity level authorization security. The problem arizes when I want to implement "property level authorization security" because my entities are generated at the DAL layer and I am putting my logic at the business layer. How can I inject my authorization checking (at the property level) for an entity. The only way I can do that is if I inject my CanRead()/CanWrite() method calls into each property GET/SET. If you have a better architecture to implement "property auhtorization security", I am all ears

Couldnt you in your BL, loop through each field in the entitity and check if its dirty or not? then throw an error if the field is dirty and the user doesnt have permission to change that field?

Omar, as it seems that the CanRead and CanWrite methods are orthogonal to the logic within the methods (properties), I think AOP is well applied here, if you're willing to deal with the complexity.

In this case, calls to the properties (at runtime) would be intercepted by the AOP framework and allowed to pass only by its permission. This way your permissions structure could be maintained centrally, and your entities would not have to know anything about a permissions structure, outside of a simple attribute decorating each property.

So:

<Secured()> _
Public Property SecretInformation as string
   Get
      Return m_secretInformation
   End Get

   Set (value as string)
      m_secretInformation = value
   End Set
End Property

Jeff

jeffreygg wrote:

Omar, as it seems that the CanRead and CanWrite methods are orthogonal to the logic within the methods (properties), I think AOP is well applied here, if you're willing to deal with the complexity.

I agree with u that the CanRead/CanWrite method calls seem immaterial to the properties' logic. But I tried to shoe-horn the reasoning by looking at authorization security as just another kind of business rules.

My pick on using attributes is that I have to build an AOP based framework and force all property access through this layer of reflection. Although the performance penalty might be acceptable (as all reflection code is done at the UI) but the code becomes un-natural because everything has to be routed through this accessability layer.

Another architecture I have been banging in my head for the last two days is one modeled after LLBL's validation. LLBL's documentation categories validation into 3 types; Field, Entity and multiEntity. It seemed that Authorization can also be categoriezed into the same 3 categories. Where applying the latter two seems natural at the BL layer, the problem arizes in implementing the field security.

Steeling a page from LLBL's design, I thought of doing the following:

1- Define IAuthorizer/AuthorizerBase classes that exposes OnBeforePropertySet/OnBeforePropertyGet/OnBeforeSave/OnBeforeDelete

2- Add an (Authorizer) property to each entity (by using the CommonBaseClass template)

3- Extend the adapter class in my BL to override the Save/Delete entities actions and inspect if the entity in question has an IAuthorizer property and accordingly call its appropiate Onxx method.

This architecure can also be applied for Auditing where an entity can have an Auditor property. The real problem with this architecture is the place to house the IAuthorizer/AuthorizerBase classes which I only found 2 possibilities:

1- the LLBL's DLL which is something I always make a point to avoid

2- If I Extend each DAL entity class in the BL class, I can add the Authorizer property in each entity and then define the IAuthorizer/AuthorizerBase classes in the BL itself. I find extending 100 entities in the BL is an over-kill and hoping to find a better approach.

I see this architecture (modeled after LLBL's validation) as felxible and natural. I just wish I can resolve the issue of where to find a home for the IAuthorizer/AuthorizerBase classes in a pracical way.