A bit about me: I've been working in the application and network management space for just over 14 years now focusing on security, primarily for the big players in the producer of technology space and also spent several years working in the consumer space. About 8 years ago, I worked for a start-up called Netegrity, that helped to spearhead the web-security service space. I now work for another start-up, Securent, that I believe is taking the granular authorization space to the next level.
First and foremost, Security is about asset protection. An asset could be anything ranging from your office, to datum that's stored on some storage system. There are four distinct parts to security from a business perspective: (a) defining what your assets are (b) identifying what assets need to be secured (c) identifying the users/consumers of a secured asset and (d) controlling the use of the secured asset.
Most of the focus of security has been on the last two of these business imperatives. At one time, each application that consumed some data asset that was classified as secure also encapsulated the enforcement aspect of security for those assets within the application. That is to say that application developers embedded security into each application in a silo, much like each door to a secure room included its own lock and key. As secure business-critical applications proliferated through the enterprise over time, it quickly became evident that this silo-based approach would not satisfy many requirements of corporate governance. For instance, one could not easily answer the question, "what rights does this user have?" or "given these rights, what can this user do across my applications?". In some extreme cases, it became hard to even answer the question, "what users currently have access to this application?". Silo data became stale as user-bases grew and user turn-around became frequent.
Thus the idea of turning reusable security-related functions into services was born. The theory was simple: take security-related functions such as logon, logoff, registration, password-management and coarse/fine-grained access control out of each application silo and put those functions into a security service. The solutions that sit within the service should plug and play. The service should provide abstract interfaces to applications that give up their embedded security-management features for those of the service, so that if a specific solution used within the service changes over time, applications are not impacted; the change should be transparent. To meet this challenge, many vendors embarked upon providing technologies to help build out this security service. To do this, we had to break up the various aspects of security and make a clear distinction between authentication and authorization. The former is synonymous to logging on to the security service by providing some set of credentials, which after verification would help the user obtain a session token -- a skeleton key -- that would allow the user access to various applications that uses the service. Authorization, on the other hand, is everything that happens after authentication that allows the service and the applications to determine what a user is allowed to do, if anything. Simply put, authorization is business-logic represented as rules or predicate statements (if...then...) that help determine the scope of what the user can see and do in an application.
Single Sign-On was nothing more than a side-effect of turning authentication into a service but sadly, it was touted as a "feature" of a lot of the authentication service products sold in the market. If security (authentication and authorization) was to become a true service, the service would have to provide a data-abstraction layer that would allow access to various enterprise and application data-stores that contained credentials used by a user to authenticate and appropriate entitlements that would help to authorize a user. Thus, it became apparent that in order for a user to be able to access an application sitting on the security service, it would be insufficient to simply establish user credentials in the data-stores that were consumed by the service alone. Parts of the user's identity -- say their user-ID -- would also have to exist in the application's own data-stores so that after logging on to the service, the application that the user was attempting to use could personalize content for the user using information derived from its own stores. In the days of the application silos, each application provided administration interfaces so that users of the application could be managed in the application's data-store. We would need an equivalent of this function in the security service. Thus Identity Management (IM) was born. The IM components of the security service would ensure that the requisite components of a user's identity used for authentication and authorization would be centrally managed, while the service automagically populated these identity elements in the appropriate service and application data-stores (through a process called provisioning that is synonymous to data-synchronization).
The next logical step in this service revolution is turning authorization into a service function. This is by far the most challenging aspect of a security service: how do we go about taking the 100s or perhaps 1000s of existing enterprise applications, some packaged and others home-grown, to a service architecture? Is it even possible to take the business logic embedded in these applications that today handle fine-grained authorization onto a service? Won't the application owners lose some control of their applications? How is the assumption of risk managed?
Like all complex problems, let's try to address these concerns by breaking the larger problem into smaller portions. I will state for the record that while it may not be feasible or even practical to abstract out every bit of business-logic from all applications onto a service platform, abstracting even a single line of authorization logic onto a configurable service platform means that there is one less line of logic that has to be maintained in the application. Forget ROI; this is common sense.
You've also probably heard this time and again before, but it does need restating: your application developers should focus on writing secure code; not on writing security-management code. Most firms that are developer-heavy find themselves attempting to solve security-related challenges for their applications by creating their own widgets, instead of focusing their development efforts on creating functional services for their customers. Let the software vendors in the security space do their job in creating reusable security service offerings that can be easily integrated, while you let your developers focus on the products and service offerings for your business.
Next, the actual challenge of abstracting fine-grained authorization is actually less related to stripping out n-lines code from an application and more related to how one can transport the authorization model from the application onto a service platform function. It would help if the vendor of the authorization service provided tools to be able to do this, that say, a business analyst could use. More importantly, it would help if those tools and the model itself could make use of standards that helped represent the authorization policies in a portable fashion. Luckily, a mature standard exists and its called XACML. XACML is an XML standard for representing authorization policies. Using a rules-engine that is optimized to process authorization models represented in XACML, we should be able to solve the challenge of transporting the authorization model of an application and onto a service.
However, this alone will not address all the challenges. In today's economy, governance initiatives such as regulatory compliance demand that we must be able to report on and control all elements of data that find its way to a firm's P&L and Balance Sheet. So it is important that we are able to answer questions about who has access to what asset or what someone can do given a specific entitlement. This is where the entitlement management and granular authorization worlds collide. An analyst may have defined business rules that govern a specific business function. Another analyst may have done the same thing as it relates to another business function. Some of these rules will be subject to segregation of duty constraints that one or both of the analysts may not directly be aware of given the scope of their individual function. For example, a trading system analyst may state that a trader ("role") cannot approve his or her own trades. Similarly, a money-laundering system analyst may state that an approved trade ("asset") cannot be settled when the recipient is a resident of a country that is part of the trade-embargo list maintained by the US Government ("role"). The trading system analyst does not necessarily need to know about finite details of the money-laundering system analysts domain or vice versa. But when a trade is executed, the transaction flows between both the trading and the money-laundering system. If both these systems sit on a common security service, then the service must ensure that the intersection of the business rules does not violate policy and that entitlements adhere to segregation of duty constraints. So in the world of authorization, we should be able to manage entitlements and their constraints, while enforcing security policy intersections that may be business-unit opaque.
In helping to report on security, the onus falls on the authorization platform to report not only on the entitlements that are defined within the service, but also on the entitlements maintained wholly by the application (not all business logic may be abstracted to the service). Ask the vendor of the product you choose if their technology can do that. It is a misnomer that an Identity Management system in and of itself will be able to do that for you.
As for loss of control, if you authorization platform supports delegated administration of policies with fine-grained control of who can do what within the platform itself, then application owners can maintain administrative control. Moreover, if the security enforcement points used by the authorization platform support both programmatic (a.k.a code-able ) as well as declarative (a.k.a configurable) security models, then the application developers can still retain control.
When security is moved from an application silo and onto a service, the assumption of risk is typically spread between the application owners and the service platform owners. From a security-related risk management perspective, if the application owners can retain control of security enforcement while utilizing the service platform, then risk is still primarily assumed by the application owner. If however, control of security management is taken over by some centralized corporate-wide entity to whom the application owners have to defer for changes to the security enforcement policies for their application (i.e. a purely declarative security enforcement model), then risk is predominantly assumed by the corporate-wide entity. The type and capabilities of solution you choose, to a great degree, dictates how risk is spread.
As always, pick the solution that best fits your business needs, keeping in mind that technology is simply a tool and not the magic bullet...
