What is the best way to implement dynamic authorization management? Is externalizing authorization decisions a truly safe and efficient method compared to other access management technologies or methods?
Ask a question
Randall Gamby, SearchSecurity.com's resident expert on identity management and access control, is standing by to answer your toughest enterprise IAM questions. Send in your questions today! (All questions are anonymous.)
First of all, externalizing authorization decisions is a good thing to do. Unfortunately, in the vast majority of cases, it isn’t feasible. Let’s explore why this is the case by revisiting how application authorization works in today’s environments.
As workers jump from one enterprise application to the next, an organization needs to define what employees can do and what information individuals may access. From the early days of automating applications, it has been the function of the application administrator to translate business processes and functional roles into configurations that the application can understand. In other words, certain systems are used for a variety of operations, such as reading, writing, executing tasks, and deleting information. Furthermore, these programs are commonly operated by a number of people, such as a system user, administrator, business user or a teller.
Over time, as business systems have become important components of a successfully operated enterprise, executives have noticed that the application administrators' interpretations of business functions were being mistranslated. A business person might go to one system and have a certain set of authorized permissions, but in a similar system managed by a different administrator, that same person may have either more restricted or expanded capabilities. It turns out that the level of authorization a particular user received was directly proportional to how risk averse the application administrator was. Because of this, when company managers take a look at authorized activities at the macro level of an organization, they see a disparity of access to information across their computing environment.
IT managers have searched for a way to take the authorization decisions out of the individual application administrators' hands and create a more balanced and consistent level of authorized access. They pictured an authorization engine that contains all the functions and data access choices compiled into one enterprise service, fed by the corporate identity management provisioning system. Once such a system was in place, the business applications could be connected to this system and would assume authorization information control instead of enterprises having to create their own local tables.
While this method of dynamic authorization seems like a great way to solve the access management problem, it hasn’t been successful; mainly because most application vendors still maintain proprietary authorization tables and have not modified their software with the choice to consume external authorization data.
Assuming an application can consume authorization information, what’s the best way to implement dynamic authorization management? Start with the applications that are expected to get external authorizations; business partner applications. Security Assertion Markup Language (SAML) is a standard to communicate external authorization data to and from Internet-facing applications. SAML has been around for quite a while and is well understood by IT administrators. However, most administrators pigeon-hole SAML as a standard for talking to “external applications” when, in fact, SAML can be used to loosely couple enterprise applications as well.
One way to start normalizing authorization between enterprise applications is to make the effort to define user authorizations based on an organization’s provisioning system. This can be accomplished by using an application’s SAML interface to push assertions to “loosely couple” an application to the provisioning system rather than “tightly couple” them. In this way, as users navigate to the enterprise application, the application will prompt the provisioning system to retrieve a user’s authorizations rather than maintaining the access itself.
While SAML will allow an enterprise to experiment with dynamic authorization management, it is a short-term fix and I recommend it only as a starting point. Long term, OASIS’ eXtensible Access Control Markup Language (XACML) will be the standard protocol for allowing managers to achieve their goal of a central authorization repository. XACML was created out of the management necessity outlined above. Its purpose is to create a standard method for representing authorization controls and to allow enterprise applications to consume them. Although this technology is still in its infancy, there are commercial products on the market, like Axiomatic’s Policy Server (APS), that allows XACML authorizations to be consumed by some enterprise applications through an authorization gateway. In this case, the policy server emulates an application cluster and pushes the authorizations to the native application authorization tables, similar to how provisioning systems push user accounts. While this is a proprietary technology, being XACML based means that someday, as the vendors incorporate XACML into their native products, organizations will be able to migrate out the gateway and point to an enterprise dynamic authorization service.
Therefore, while dynamic authorization management is still not feasible for a vast majority of organizations, the potential for it to become so is growing. Regardless, the main factor that will determine its success is the willingness of commercial off-the-shelf vendors to eventually move away from locally storing the access controls they need to manage their data and create standardized interfaces and configurations in their applications that are able to consume external authorizations.
Dig Deeper on Privileged access management
Related Q&A from Randall Gamby
Learn how to create account lockout policies that detail how many unsuccessful login attempts are allowed before a password lockout in order to ... Continue Reading
When it comes to minimum password length, 14-character passwords are generally considered secure, but they may not be enough to keep your enterprise ... Continue Reading
Enterprise SSO products have matured over the years, so what's the state of eSSO today? Expert Randall Gamby discusses. Continue Reading