Authorization management is becoming increasingly popular. But there are, in fact, two very different approaches:

• Static authorization management, where changes are provisioned to the target systems.
• Dynamic authorization management, where authorization decisions are externalized to authorization engines at runtime.

The latter require changes to the applications, but they lead to the externalization of authentication and authorization (and hopefully as well auditing) from applications. Everything can be easily managed from outside of the applications.

Whilst static authorization management is provided by provisioning systems (at the more technical level) and by several GRC vendors (from a business control perspective), vendors of solutions for dynamic authorization management are still relatively rare and, besides this, in most cases relatively small. Besides Oracle with their Entitlements Server and, to some degree, CA with their Embedded Entitlements Manager, vendors include companies like Bitkoo or Engiweb, to name some of the two which are particularly interesting. And, for sure, Microsoft’s approach for claims leads in that direction – but at least in the current approach, authorization decisions aren’t externalized yet.

From my perspective, externalizing these decisions from applications definitely makes sense. Policies can be managed centrally, changes are effective immediately, and application developers don’t have to think much about security. They just rely on external decisions. In fact, things are moved from coding not only to deployment, but to runtime.

There are three challenges:

• The authorization engines have to be fast
• They have to be integratable with other IAM/GRC tools for a consistent management
• The applications have to be adopted to a specific solution

The first part is just an architecture and engineering task which has been solved by several vendors. The second requires, from my perspective, standards for the description and exchange of policies which are still widely missing. The third part could also be addressed by standards. That would give customers the choice between different authorization engines. As long as these standards are missing, customers should, with respect to the last bullet point, focus on implementations which require few changes in applications to minimize the risks of vendor lock-in. On the other hand, the advantages of such approaches are significant – and vendors like Bitkoo and Engiweb are succesful because of that fact.

From my perspective, companies should start looking at these approaches today and really start externalizing security out of the code.

By the way: We’ve given our European Identity Award in the category best innovation in 2008 to some of the vendors mentioned above. Attend European Identity Conference 2009 and learn, amongst many other things, who will be awarded as innovator this year.

The need for standards

There is no doubt that the attestation capabilities which can be found in many of today’s IAM-GRC platforms (e.g. GRC platforms with focus on Identity and especially Access Management aspects) are important and helpful. Attestation provides a capability to go through existing entitlements and, in some cases, changes and confirm or revoke them. But: Attestation is mainly sort of a detective approach. There are two other aspects which have to be addressed as well:

• Preemptive controls which avoid that there is any access right granted which later on has to be revoked
• Controls in the sense of really managing and not just auditing

That is where active Authorization Management comes into play. In my definition, Authorization Management defines the approaches to centrally manage authorizations in underlying systems. In best case it ends up with the management of specific entitlements (that would really be “Entitlement Management”), in most cases it is only the capability to map users (using roles and so on) to system-level roles or groups or profiles. Better than nothing… In fact, most GRC solutions are limited because the provisioning solutions used are limited as well. There are only few products which can granulary manage entitlements at least for a few target systems.

But at least using higher level policies (and thus rules) and business roles to manage authorizations, e.g. in most cases controlling provisioning systems, is a huge step forward – even more if the GRC system can use the reconciliation capabilities of provisioning solutions to detect issues on the fly and not some weeks or months later when next time going through the attestation process (that might be too late – the money might be at some strange caribeean island at that point of time).

Anyhow, the big gap of provisioning still remains. Provisioning (or GRC) are in control down to the assignment of users to groups/roles/profiles in the target systems. But what these group, roles or profiles are allowed to do is managed by someone else – the operator/administrator of these target systems. You should always keep that in mind, because it is the reason why we will need not only one level of attestation but a multi-layered attestation, starting with the sysadmin who confirms that groups, roles, or profiles still have correct access rights at that level.

There is another interesting aspect of Authorization Management: Dynamic Authorization Management. Most of today’s approaches are static, e.g. they use provisioning tools or own interfaces to statically change mappings of users to groups, profiles, or roles in target systems. But there are many business rules which can’t be enforced statically. Someone might be allowed to do things up to a defined limit. Some data – for example some financial reports – have access restrictions during a quiet period. And so on. That requires authorization engines which are used as part of an externalization strategy (externalizing authentication, authorization, auditing and so on from applications) which provide the results of a dynamic authorization decision, according to defined rules, on the fly.

Today, in most cases companies rely on a single-layer attestation – which isn’t sufficient. They have to move to multi-layered attestation, to static authorization management and to dynamic authorization management. And vendors will have to enhance their products significantly to support every aspect. There is still a long way to go for IAM-GRC vendors, not even talking about extending GRC platforms to SIEM, BSM, and other aspects.

One of the newer topics in Identity Management is the Enterprise Entitlement Management. This term describes approaches for a centralized management of the low-level entitlements (e.g. access controls) on system level from a central perspective.

That seems to be pretty complex. How shall you ever manage file server ACLs from a central tool in an efficient manner? Or other tools? Yes, it isn’t that easy to solve. But bring in services and you’re much closer to a solution – not only for entitlement management, by the way.

Think about abstracting file server resources as services (which is, by the way, not that different from shares in the Windows world). Users will understand services – a service provides the ability to store and retrieve their contracts or their personal files or their blueprints or their drafts of new marketing materials or… A service is simple to manage from a security standpoint: No access, read, write, do everything – or something like that are the relevant rights.

Services are easy to handle in accounting. Their might be restrictions like quotas applied on the service level. And managing entitlements on that level is not that complex – that can be mapped to concepts in the Enterprise Authorization Management pretty easy.

You might argue that the file system still has to be locked down. No problem – as long as you can access it only through services. There might be different overlapping services for the same resources. Administrative shares in Windows are one example for that. If that isn’t sufficient, you can still use ACLs – and the services might act as specific operating-system services which bypass that security level or (like today in Windows) combine their security settings with the operating-system level settings. The latter is pretty complicated and somewhat overengineered. From my perspective, a consequent service approach might be sufficient.

To add some web services for file system access might be helpful – but it isn’t mandatory. A service is not necessarily a web service. In fact, everything you need for such an approach is available. Some things might be improved. But with a service-focus for file server services, security is easier to manage and to audit.

In some of my last entries in this blog (here and here) I’ve mentioned the concept of Enterprise Information Management, something I will cover in depth in a report within the next few weeks. Enterprise Information Management will be sort of the long term evolution of today’s Identity Management and some of the tightly related topics, as well as the integration of IAM with some other technologies. I started thinking about this concept when I developed a simple chart which describes the future of IAM.

It starts with today’s IAM, which is sort of “Identity Management for Administrators”, e.g. solving mainly technical issues in synchronizing information, with support for single sign-on or with provisioning. I’ve titled the next level “Identity Management for Applications”, describing the service orientation and the integration into applications. It includes aspect like Application Security Infrastructures. Many vendors are working on a service layer or the integration of business applications with their IAM products.

Read the rest of this entry »

Dave Kearns, who will contribute as a track moderator and speaker to our European Identity Conference 2008, has introduced the term context-based authorization (and influenced my thoughts on this topic – thanks to Dave) as an approach for basing authorization on the context in which a user acts, which goes beyond the risk-based authorization in two ways: It’s not binary, e.g. either in or out. And it’s based potentially on more information about the context. I’d like to add some thoughts from my side to this and explain as well the difference between today’s risk-based authorization and tomorrows context-based authorization.

Risk-based authorization is an approach which has developed mainly in the financial industry. The idea is to observe and analyze user interactions to detect potential attacks and other dangerous situations. If there is a risk, the authorization to access a specific system or specific data within in a system is denied. There are several vendors in this space, including Oracle with their Bharosa acquisition and Arcot Systems.

The idea of context based authorization goes well beyond this, even while there is no hard borderline between vendors of risk-based authorization and the context-based authorization idea. It’s more sort of an evolutionary process. I personally expect that todays vendors in the risk-based authorization space (which sometimes have a some ability for context-based authorization as well) will expand their products towards context-based authorization. I assume that we as well will see some new specialists in the space of context-based authorization. And for sure the key players in the IAM space will enter the market for context-based authorization either with the make or the buy approach, e.g. building it by themselves or acquiring someone. Read the rest of this entry »