Authorisation and the GetProperty<> property

Authorisation and the GetProperty<> property

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


rfcdejong posted on Friday, January 16, 2009

Just before the weekend hits there was a discussion at my work. Another collegua is going to implement our custom authorisation into our new application-framework. The current application has restrictions on the database foreach userrole, based upon a table/field customized by the applicationmanager.

The discussion went about where to implement the authorisation.

He says: The dataaccess service should not do a LoadProperty when the current user isn't allowed to see the field on screen.

I asked him: Why don't u want to use the AllowRead(propertyname) method in the businessobject currently available in the CSLA core? Then in our own businessbase class we can dynamicly load the custom rules from an authorisation businessobject.

He says: The dataaccess service is the safest place to implement that so noone can make an mistake and the performance will always be better since the businessobjects will contain less.

I say: What about business behind the screen? Maybe an Execute within the businessobject need to access the property?

... and so on

1 hour later we just decided to go home with no real results :(

Anyway, who is voting for me and who is voting for him? :)

The real question is:
Why use LoadProperty and when CanReadProperty will always return false?

ajj3085 replied on Friday, January 16, 2009

Well... there are a few things I can think of.

One, if you're like me, you're using stored procedures.  So you need to have the original value around when you call the procedure, otherwise you'll blank out the value... either that or you have A LOT more work to do to prevent that from happening.  So updating is easier, which means your code is simpler.

The performance gains your co-worker is talking about will likely be minimal.  My first response to his "pro" would be: do we CURRENTLY have performance issues?  If the answer is no, then performance is irrelevant, and to do something for the sake of performance when you don't have a performance problem would be following the Premature optimization Anti-pattern

He's is right though that if you didn't load the value, the un-authorized user can't see it.  My response to that is that you need to determine if that's a risk worth the cost of addressing.  As I said, your code will be much more complex without the value.  So what is the cost of implementing the more secure way vs. the risk that this will actually happen.  If you're doing an application for internal employees, your risk would likely be less than a Silverlight application deployed over the internet.  But it's a matter of risk vs. cost analysis. 

Those are my thoughts on this question..

HTH!

rfcdejong replied on Saturday, January 17, 2009

Ok, but what about when an user is not allowed to read a property value on screen, but he is allowed to execute business code which will require the property in the businessobject? I would say that the value always needs to go into the business layer, let the data layer only be smart for dataaccess and nothing else.

Then he'll just say that in that case a businessobject will use some sort of impersionation to outsmart the datalayer.

Are there any other statements i can use to defend my thinking? Maybe something about the command objects, since i have less knowledge about the command objects :)

rfcdejong replied on Sunday, January 18, 2009

Nothing else, anyone?

ajj3085 replied on Monday, January 19, 2009

Well, that was the point I made.  You at least need to value to not wipe it out on update, and as you said you may need to use the value (say in a calculation) on the business object, and not having it prevents you from doing so.

I'm not sure what you think his counterpoint will be though.  I don't see how impersonation will help outsmart anything.  And if you have one layer trying to use another layer in a way you didn't intend... well I'm not sure what the point of that would be.  Either you goofed on the data layer design or your breaking your established architecture, which will make your application  harder to maintain.

Copyright (c) Marimer LLC