In a perfect world... web pages, page fragments and UI components should not be designed as monolithic full featured resources but as reusable and extensible portions of user interface. In other words reusability and composibility should be considered mandatory and primary requirements of any modular front-end tier architecture. The same concern is obviously essential for the application modules built on these UI components, call them workflows or business process interfaces or how you prefer: the ideal front-end tier architecture is the one that transparently helps and facilitates both, process and UI designers to maximize decomposition, reusability and of course maintainability of their artifacts.

Modularity/composability of applications and business processes together with role based authorization and access control and last but not least rule based customizability of the presentation layer are the three most frequent architectural requirements in nowadays user interfaces but almost always they are even the most underesteemed" features so it almost always happens that these three foundamental features of any truly scalable application platform are missed, causing the complete or partial failure of entire information systems.

Using a mix of embedded and declarative role based view guards to secure web pages and selectively hide/show portions of views is a very common technique that only partially solves the last two requirements but is also a choice that dramatically reduces front-end modules reusability and maintainability.

This article summarizes a set of personal reflections about the different shades of Role Based Authorization and Access Control techniques and their impact on web application architectures.

RBAC is a very professional sounding acronym :) but unfortunately it says Access and means Authorization, that is just ambiguous, it's not rare to find papers speaking about RBAC like just a set of resource access policies, considering RBAC as just an evoluted ACL where user groups are replaced by user roles and control lists are replaced by some more abstract data structure like a composite or a hierarchy or something in the middle of both.

With this latter meaning of the acronym (RBAC as role based ACL), role based resource guards are the most simple and common RBAC technique: a guard checks for user's roles anytime a user tries to access a guarded resource. The guard is just defined by a static declaration of the roles that can access the guarded resources. Guard declaration can be embedded in the resource itself, for example using some kind of tagging or programmatical check surrounding the resource or can be externalized as a deployment time configurations, like for example happens for protected pages or areas of a website.

This model fits the web application domain quite well if we consider web pages as view resources to be guarded, letting people access only the views they are granted for, a technique that can be summarized with two words: "view guards". View guards can be embedded into the views and than controlled by the views themselves or declared into some external web application deployment descriptor to be handled by the web application container. The latter solution is usually the favoured one, but sometimes the application deployment document has a limited access access, so programmers are forced to adopt embedded view guards in the form of scriptlets or tags that they directly code into web pages. An extension to this model can be to create realms like repositories externalized on an LDAP or a DBMS and design some kind of policy administration tools but the whole scenario doesn't change that much, we are just creating a tool to define and change policies and roles at runtime, we still need to embed the view guards into the views, with all the limitations that implies.

An additional concern with this model is that web application developers and analysts too often abuse of role based view guards, using them to implement some kind of role based customizability of the user interface that nothing has to do with security requirements. Coupling views with embedded security policies to achieve UI transformation is a very counterproductive design hack. Can you smell the side effects of role based view guards applied to presentation layout customization? :-) Well maybe you will, later.

What's sad is that tricks like UI transformation via view guards are even published in specialized "patterns" papers or books and sponsorized by first line companies when it is obvious that they break some of the most fundamental principles of design: separation of concerns, coherence (architectural continuity) and cohesion of the single parts (integrity and sostitutability).

Role based view guards pro's:

-externalized role based resource guards are supported by many platforms, for example they are supported by J2EE servlet containers that let you define security policies in their deployment descriptors;

-embedded view guards technologies can be implemented with little effort, invoking container services api from within views (even decorated by tag libraries in languages like java or php).

-the model can be simplified to extreme extents, you just need roles and fully qualified resource names. If your platform doesn't support resource guards or you don't like how it supports it, you can build your own implementation, otherwise you can find many rich third party open source implementations (java: pow2acl, jguard, acegi, etc.)

Role based view guards con's:

-as stated before, basic authentication methods and flat role based resource guard services are supported by most enterprise application container but on the other hand there is no standard specification for richer models, so if we use feature richer implementations supplied by enterprise application servers we must be aware that we are going to tie our entire infrastructure to proprietary technologies, closed source, non portability, etc.;

-the simplest solution can be perfect for small span requirements but more than often it will be not adequate when problem frames involving real authoritative control and modularity have to be faced! Solutions that may look unexpensive when a problem requirements are not yet clear can become inadequate even before they reach a production release, generating just costs and slippages in project schedules. Well this point should be obvious, specially to customers and managers, but it is probably the most common error they do, 'missing the real user perspective' :);

-too often role based access control policies end up being interwoven with presentation logic, like in the case of partial view guards applied to customize the layout presentation; maintenance costs and chance of errors grow both as the number of views, the number of roles and the view complexity grow;

-views guarded by role aren't truly reusable (!) because they are accessible only by users with given subset of roles, they can't be reused to compose other views and paths accessible by other users! This issue reaches a maximum extent with views that contain multiple partial view guards. Forms, wizards, application modules that contain role based guarded resources are implicitely coupled to security and roles... so forget their reusability.

Almost all the commercial and open source security platforms, toolkits and API (for example in Java: JAAS, JACC, Acegi/Spring, etc.) just define this very low level of authorization security. Another common (anti)pattern is that security technologies always carry with them too much platform and infrastructure stuff, completely unacceptable for the little features they offer, for example Acegi started as an interesting standalone project but later became part of Spring, now is going to become Spring Security, it will evolve around Spring, Spring WebFlow, etc., open source is great but open source projects with a closed perspective are evil :).

"RBAAC", role based authorization access control - guarding users operations.

The first step to improve our application security model and to strenghten our overall architecture is to stop guarding resources and start controlling user operations. This step will not be enough to remove the coupling with the RBAC modules from the front-end tier, but at least is a first improvement toward the right direction.

So let's add the A of Authorization to the RBAC acronym and start thinking in terms of user operations.

-the access to application modules (we are not going to control views access anymore);

-the execution of operations/processes.

The authorization to access an application module must not be mistaken with the user authentication/idenfication process. We are not speaking of the authorization access to a simple "one entry point" application but to multiple front-end tier modules (or even multiple front-end tiers in case of federated applications) anywhich one could undergo different authorization policies and anywhich one could be accessible by multiple paths, access points, navigational flows.

In such a context, authentication must be a pre-requisite to authorization, must be independent from authorization and some technique must be used by the front-end modules (or front-end tiers in case we are architecting some kind of federation) to share some kind of authenticated user context. The backing authentication/sign on technology is not relevant to the topic I am are discussing in this article, just we should care that the authorization and authentication modules are independent and coordinated by some kind of security controller/provider.

The "RBAAC" model that authorizes only application modules access and operations execution is simple but effective. Application modules will be the only resources whose access and whose operativity will be subject to authorization control. Application views (UI) will not embed anymore raw access control guards and static list of granted roles but just more abstract operation execution guards.

...to be continued...
...(I should explain better what are the differences between this model and the previous in concrete... now we think in terms of user authorization to execute operations, not anymore in terms of roles...)...

....(I should write something about techniques to implement views that adapt themselves to user roles - how they can hide undesired sections without coupling with security...maybe it would be a too wide topic, etc., ...)...
....(I should write something about presentation layer adaptability to user profiles and user preferences, techniques, etc...but it's a completely separate topic... ...)...

....(I should explain why RBAAC still generate reusability issues in the application model...front-end modules are still coupled with security rules, even if now rules about roles are abstracted and externalized they still grip pages and modules) ...

....

It's not rare to find a degenerate version of this model that sounds simpler but introduces several limitations in terms of model adequacy and scalability (I would discourage it). The degenerate model arises from a wrong reduction:

access to an application is a type of operation execution, so we can reduce the entire authorizative model to a single type of event to be controlled:

-the execution of operations/processes.

to be continued...(I should explain the issues of the "everything is an operation" idea...giving examples of how the other model is more coherent and scalable while this latter tends to collapse into RBAC-ACL-View Guards...)

Context Based Authorization & Access Control - (Flow)Contexual Security, Separating Security Contexts from Application Contexts.

I should write about the ambiguity/weakness of the Role metaphore and of the common misconceptions running around it....(probably I'll do it in a separate post).
Rule Based Security (using rule engines) can help in the direction of abstracting authorization policies and realizing security agnostic front-end modules (see the case of JBoss Rules - ex Drools).
...

to be continued ...