In a previous post, I laid some of the conceptual groundwork for authorization in the tricky world of SOA. Now, a year older and a year wiser (I hope!), I'd like to swing back around to the topic of authorization, but broaden the scope a bit - talking not just about authorization and SOA, but about authorization and the whole enterprise "ecosystem" (services, applications, user interfaces, etc.).
In this post I'd like to describe the decentralized, "every man for themselves" model of authorization that is most common in organizations, and the problems inherent. In later posts I hope to touch on some possible paths out of this chaos - the XACML standard, entitlement management, and attribute services. Here goes...
The Authorization Status Quo
In any decent-sized organization, there exists a number of different systems that a given user may interact with - think HR, CRM, financial apps, knowledge management portals, ERPs, etc.. While these systems may differ along any number number of dimensions (size, technology, hosting model, etc.), each will inevitably share the common feature of authorization - in other words, each must define some rules for determining what a user can and cannot do within.
The problem is that while each system must "do" authorization, the way in which they actually do it can differ greatly. One system may take a simple role-based approach leveraging LDAP groups, a second may use an access control list tying permissions directly to user IDs, and a third may just use some internal database connecting users to roles to permissions. Essentially, authorization in the enterprise is often a wild west - there are no laws; systems do as they do, with no connection between them in terms of either approach (RBAC, ABAC, etc.), tools (e.g. JAAS, Acegi, etc.), data store (LDAP, database, flat-file, etc.), or process (e.g. provisioning/de-provisioning requests, auditing, reporting, etc.).
And while this inconsistency can be beneficial to the extent that it allows each system to implement authorization in the way that is easiest or most effective within that context, across the organization as a whole, managing authorization separately in each system is a serious bane, incurring significant costs in terms of time, resources, and quality. These costs are most evident to the organization in the areas of administration, development, reporting, and auditing.
Administration
Any system which manages authorization must provide some mechanism for allowing administrators to change access privileges for users, whether by using a nice GUI, editing a configuration file, or directly manipulating rows/columns in an underlying database. As a user's status changes (e.g. they get promoted, quit, take on new accounts, etc.), these tools must be used to re-provision permissions accordingly. Depending on the number of systems, however, this can be an extremely difficult, time intensive, and error-prone process. A simple resignation of a single employee, for example, could necessitate the re-provisioning of this user's access across dozens of different systems, executed by a handful of different administrators.
Development
For systems developed and maintained internally, authorization, like other cross-cutting concerns (e.g. authentication, logging, etc.) should ideally be implemented using a similar set of tools and patterns in order to eliminate duplication of work, maintain quality, and enable developers to translate knowledge or skills from one system to another. Unfortunately, in larger organizations, this is often not the case: authorization is implemented differently for every application, using the approach, patterns, and tools selected by the development team, usually with no concern for commonality or re-use across the organization. Whether a new project uses Spring Security, AzMan, or some other custom solution typically depends on the whims and proclivities of the developers, and the result of reinventing the wheel like this is higher development cost, lower quality, and discrepancies in feature set and usability (e.g. fine-grained authorization may be possible in one system while another has a one-size-fits-all/none model).
Reporting
A generally accepted principle of authorization is that of least privilege, giving users as little access as possible to perform their job. In complex enterprise environments, where users are in the thousands, upholding this principle is crucial both from a security perspective as well as a regulatory one. And although this seems simple in theory, in practice, when systems all have their own model for authorization, it's easier said than done. The reason is that before we can even ensure what user X should be able to do, we need to first understand what he can do now. To this end, generating a simple report detailing what permissions a user has is crucial. Unfortunately, this simple view is not trivial to produce, entailing the manual (and collaborative task) of going to each system, discovering what the user can do, and then aggregating the individual sets of permissions into one global report. In other words, there is no one report that can tell "what can Joe Smith do across the organization".
Auditing
Finally, auditing is another key component of authorization, both from an administration perspective (e.g. "Joe granted permission X to Sandy on 7/20/10") and an enforcement perspective ("e.g. Joe was authorized to approve order 1234 on 8/1/10"). Unfortunately, auditing of this kind is implemented inconsistently at best or not at all at worst. Piecing together how a user's permissions changed or what a user did on any given day, across the organization, with a model of decentralized authorization, is virtually impossible, necessitating scouring through different log files, database tables, etc.
Conclusion
These are just a few problems of implementing authorization independently across different systems in an organization. In later posts I'd like to explain how steps can be taken to centralize some elements of authorization, to the benefit of administration, development, reporting, and auditing. As we all know, there is no silver bullet - every decision comes with a set of trade-offs, however given the status quo of decentralized authorization, it's clear we can do better!
