Declarative security and validation constraints

Declarative security

Belts uses two types of security constraints when executing a specific
operation.

The first is a role check, is the user an administrator, are they a
student etc. The second type is to ensure that the user has a specific
data relationship (belongs to a school, class etc).

At the moment our security constraints are determined inside of the code
by checking to see if the user has a specific role or relationship and
throwing a security exception if there is a problem.

The inclusion of the checks in the code cause a number of problems:

Signal to noise. There are many actions where the majority of the code
is checking security constraints so the function of the action is
obscured.

Copy paste waste. Too many actions simply copy and paste the security
checks from a similar function rather than using inheritance or
delegation. This more than once lead to the replication of a bug in a
number of places. A tester would catch it in one block of code, it would
be fixed, but the remaining blocks with the same issue were left to
lurk.

Sloppy Separation: Because the code checks to see which role a user was
in often a command will take a different action based on the users role.
Nested if statements and unchecked roles caused a number of bugs in the
lead up to 1.0.

So how so we fix this. Simple. We have an execution chain in place.
Presently this is used only to extract parameters from the the
environment (request and sitemap) and to provide the command with the
container to execute within. Into the chain we now add an interceptor
for the user role and a number of interceptors to determine if the user
has the correct data relationships. The data interceptor presents us
with a small problem in that currently the interceptors are not run
within the containers environment. This will need to be addressed, but I
don't think it's a big problem, we just need to add an additional
interface, separate the container hosting and execution components and
have the interceptors with the new interface execute within the
contained environment. Configuration files would determine what roles
are allowed to execute what commands and which data correlation
constraints to activate.

Declarative validation constraints

Another place where we have a large amount of copy/paste code is in
checking parameters for commands. Much of the copy and paste here is to
do with java's lack of multiple inheritance and our lack of usage of
delegation. This leads to the same problems outlined above (though to a
lesser degree as the validation code is captured into a discreet
function). The solution is similar. The definition of the validation
constraints (remember that these constraints are executed in a
non-contained environment and check the the command parameters are in
the correct form, but not that they necessarily contain correct data).
It will be a relatively trivial task to externalise these functions.

Though none of the above add new "features" to BELTS from a user
perspective they are still vitally important improvements to the core
software as they reduce the the complexity of individual components thus
decreasing their likely hood of containing undiscovered bugs. These sort
of bugs where a significant contributor to the late delivery of the
previous release. If we do not learn from history we are doomed to
repeat it.

-k.  

-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://www.rocketred.com.au/blogs/kevin/



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/