In computer software, authorization is an area that is continuing to morph. As I demonstrated yesterday, by defining horizontal and vertical partitioning in a database, most engines have some form of authorization for basic activities.
This methodology was especially useful when there were fewer layers in an application, and the layers were closely bound. A 1990s application written using a client/server could easily take advantage of authorization methods built into the database. The application would only have to handle errors raised by the database, when unauthorized activities were being executed.
As we started moving to browser based applications, the potential volume of unique users grew from dozens, or hundreds, to thousands or millions. In the old days, licensing was based on the number of user accounts. With web based applications, the cost was frightening. Database vendors moved towards licensing by CPU or later, Core. Now you could have thousands of users.
The thought of managing permissions for thousands of users in a database was overwhelming. So, we moved our authorization into higher layers, and used a limited number of accounts to access the database on behalf of a large group of users. Sometimes only one account was used for all users when addressing the database.
Due to the open nature of the internet, applications have begun authenticating long before utilizing database resources. The client of an application may be authenticated before even executing a method. This closes the door to hackers at an earlier stage, hiding much of the capabilities of your application until authentication is fulfilled. As we move more and more toward mobile applications, early authentication will be come the norm.
No longer will we take advantage of built in authentication and authorization in a database. New techniques and skills will be required in order to perform the same sorts of filtering and morphing, most likely implemented by the developer. It is more likely that these kinds of requirements will be built out in a middle layer instead of being an asset of the persistence engine itself.
Do you build an authorization API into your applications? How do you implement the power formerly found only in relational database engines? Please share your insights, questions, or observations by leaving a comment here.
Cheers,
Ben