Take control of your Authentication (and Authorization/Entitlements)

It feels good to hear that people are realizing the difference between authentication and authorization. Even though it is self evident from the basic definition of Identity, Authentication, Authorization (Wikipedia) that these are three different things, I have a feeling people do not completely realize whether the current products in market allow them to solve authentication and authorization problems at application level.

When I talk to most of the clients who are trying to get control over their authentication and authorization, it is pretty clear that User provisioning, User-centric IDs (well they need to start thinking about Infocard), EAM/Web SSO products and Enterprise Reduced SignOn are solving only the authentication part of equation. Even though most of these product claim to solve the authorization, I do not think they understand it or are just doing at very basic level.

For example, EAM/Web SSO products are built to extract the authentication out of application and they do it pretty well. Most of these product would claim that they provide Authorization solution also. But if you look deep into them, these products support very simple Authorization policies and can only protect resources that people access through standard containers (like Web Servers, Application servers). You still have to rely on the authorization model of the application for actually controlling who has access to what. Incase of user-centric ID systems and federated SSO, it seems the only problem they are trying to solve is access control over user's data (besides core issue of federated SSO) and this makes them completely unusable for enterprise entitlement systems. The last but not the least the Provisioning products are limited by their capability to just make the target systems (i.e. application's identity repository) aware of User's Identity (and to some extend control its capability by assigning groups, etc) and can not provide a deeper understanding about what a user can actually do within the application.

But I think most of the enterprises will agree that what they are looking for is the capability of being able to answer something similar to the following questions when the auditors visit them next time

"What are the various financial resources that a user can perform specific action on?" "What are actions can the user perform on given resources?" "Who are the various users that can perform the given actions on given resources?"

Now eventhough some of the auditors may get satisfied with the answers like "these people belong to this role in application x" or "these people have access to application y" but I have a feeling most probably that may not be good enough in near future.

Besides that all the other reasons like taking security out of developers hands, making life of developers easy by reducing coding they need to do for security features, allowing security people to have a better idea about state of software security esp in terms of access control models, and so on are not completely solved by authentication systems.

At this point I would like to make it clear that all the work that enterprises have done so far for getting access control in order using various products is not waste. I am not suggesting that all these the previous stuff need to be thrown out and a new product must bought. My suggestion is to take a look at the need to complete the last mile of the Authentication, Authorization roadmap by looking at the application authorization model.

The application authorization model is the fine grained access control model that most of Identity aware applications typically have implemented in their code. This implementation can be in form of an accounts table in database with user id and account mapping, or a simple isUserInRole call in application. Such implementations have the basic flaw that the security model is not completely clear to any body (including developer in case of very large applications) and thus reduces the ability of people responsible for the security to generate accurate and complete access control models for various purposes (including audit and compliance) based on design documentation, collation of various replies from developers and so on. So, the ultimate goal is to develop a single enterprise dashboard that can provide (and possibly manage) authorization (and/or authentication) information.

There are various reasons why people may see this as an issue that needs to be rectified. Most of the typical reasons would probably be same as that responsible for earlier wave of Identity Access Management products. I would like to discuss the various approaches that can be taken to solve this issue. Just like other similar problems there are atleast three ways to approach this problem -

1. Centralized and Standardized Monitoring - In this approach, there is a central monitoring/reporting system that receives the various application policy and associated events (that may affect the evaluation results) like user data change, role assignments, etc in a standardized format and uses it to develop a standardized Authorization model across all the relevant products within the enterprise. This approach is similar to the process of periodic synchronization that provisioning product perform to ensure that they have correct data and hence correct user's profile across all the applications.
   At this point I do not know of any commericial or opensource product that can help people achieve this.
2. Centralized and standardized Runtime (and administration) - In this approach, there is a central/standard runtime policy evaluation engine that can be used by application to perform the authorization. This is an approach that one my client calls "cop-out approach". When comparing with authentication world, it is similar to Web SSO approach where you expect application to change (or it may not change if application container is well integrated) so that at runtime the application will leaverage a standarized approach to make authorization decision. But just like SSO, if your application is in support mode (which most of the money making stable applications are), you probably will not be able to use this. The reason for calling it cop-out is that this approach is basically built on pricipal of "my-way or highway" and that would ensure that most of the application would probably not be able to leaverage this. My pessimism on this comes from the first hand understanding of how few applications have moved to Web SSO platform over long time at most of the clients that I talk to. Most of these are very large clients (with 2000 and more apps) that are running these infrastructure for atleast 4 years and are making slow progress.
   There are 3 commerical vendors that I know of (i.e. BEA, CA, Securent) in this space (2 older companies merged with bigger company) and one standards i.e. XACML that defines the standard protocol for request/response to the centralized service.
3. Centralized and standardized Administration - In this approach, there is a central administration system which is used for policy design and then it is distributed to external runtime entitlement/authorization system in a format that can be understood by these third party for enforcement at runtime. This is similar to the approach of Identity provisioning, but it is much more difficult to achieve due to a myriad of reason (may be next blog) compare to IDentity provisioning.
   I do not see any of the vendors moving in this direction but would love to hear otherwise.

I think there are a few hybrid models that are possible based on above approaches (and possibly other approaches like audit/log management) but would love to hear your thoughts. At this point, I think things are still unclear as to how the entitlement landspace will grow , what its drivers are going to be or would it even have any drivers to continue (which has been the reason for lack of vendors in this space for so long). This is an interesting and complicated space where it would be fun to watch how the things grow.