Using Parameters for Enhanced Usability, Not Questionable Security

By August 5, 2011For Developers, Tips

Traditional Environments: DBAs Rule and Users Drool

If you want data or an update, the only option is to put in a request to your DBA.  Worse yet, it may be a committee of DBAs. The DBA would run the report and send it to you. If your company is a bit more enlightened, you may have online reports you can access (but not modify.)  While this is progress, knowledge workers really need access to data immediately and through a self-service interface that makes it easy to run routine reports with minimal steps and customize them when necessary.

The All-Seeing Database Administrator (DBA)

In a traditional environment, the DBA has access to all data and is responsible for dishing it out to people in a secure way. The DBA manually adds parameters to a report to ensure that users never get more than they were supposed to. There are several inherent flaws with this. The primary one is the overhead it creates. The DBA has to spend enormous amounts of time (for which they like to bill by the hour) auditing requests and cross-checking business rules about who can see what. Another flaw is that it assumes the DBA is perfect and has perfect information as policies change, organizations transform and new people get hired. It also assumes that the DBA won’t work for your competitors one day.

Separating Security from Parameters via Hidden Filters

Parameters serve a purpose. They guide the user in the right direction, save steps and increase performance by requiring the user to fill out things like data ranges before the report executes. This forced reminder actually makes it easier or the user and prevents the database from having to execute on all records for all time unless they really really meant it. They should not be used a replacement for a true security layer.