Menu

An Enterprise Authorization Framework Requires Identity and Context

We recently completed a consulting engagement to create an authorization framework for a large financial services organization. As illustrated, the framework has three dimensions: Runtime authorization patterns, policy models, and governance structures.

authorization-framwork-cube

The “runtime authorization patterns” describe the components, interfaces, and protocols through which an IT system or application grants a user (or subject) access to resources. The policy models – group-, role-, or attribute-based access control – provide the rule base for runtime access policy enforcement. Finally, governance over the policy models and where or how authorization tools are deployed overlays the framework.

Modeling Authorization

Groups are the dominant policy model in the enterprise today. They are easy to manage organically from the bottom-up, and almost every application supports them. Often groups are managed at the application level (corresponding to the application-specific runtime authorization pattern). Groups can also be managed at the enterprise level and consumed by enterprise applications, or web enterprise applications, via a policy information point such as Active Directory, an LDAP directory, or a virtual directory service (VDS).

Role-based access control (RBAC) is used with some enterprise applications, such as SAP or Oracle Human Capital Management. The roles are typically application specific, but some of them are managed centrally via a  identity provisioning system.

When a single role (or membership in a group such as “contractors” or “employees”) is used to manage access, we call that “coarse-grained authorization.” When multiple groups, roles, and other attributes are used we call that “fine-grained authorization.” Roles and group memberships (along with session context, time of day, and information about the resource being access) can be modeled as attributes. Thus, many fine-grained authorization scenarios involve attribute-based access control (ABAC).

Too Much Application-Specific Authorization is Dysfunctional

Application-specific authorization is still the dominant runtime authorization pattern in many organizations.  This is unfortunate because one should consider every application that deals with enterprise data to be an enterprise application that should be subject to enterprise policy. Moreover, policy data should not be hard-coded into applications, nor should it be expressed in poorly-managed groups that become outdated or unnecessarily duplicate data available from enterprise repositories. Yet that’s what tends to happen with application-specific authorization, leading to many duplicate policy management processes at high risk of inappropriate or unauthorized access.

Mature identity deployments – to quote Michel Prompt, Radiant Logic’s CEO – are evolving “from groups to roles to context” where context is maintained in attributes. In fact, if we consider role occupancies and group membership as attributes, we can view ABAC as the unified field for policy modeling. 

The ABAC model is in the ascendancy of leading practice in the enterprise. But it’s not just about the technology, ABAC requires the right patterns and governance to create economies of context.

The Right Patterns

Most organizations still need to move their application portfolio’s center of gravity from application-specific authorization to some form of authorization runtime pattern that consumes enterprise policy. The core enterprise authorization patterns shown in the cube figure support users on the enterprise network, web users, and users accessing resources through an API. For inter-organizational use cases beyond the enterprise domain, federated enterprise web user patterns, or API access patterns apply. All these patterns have the potential to use enterprise PIPs to retrieve attributes for policy evaluation, or to send and receive attributes as “claims” or “assertions” with identity protocols such as SAML and Open ID Connect. The figure below displays a simplified version of the enterprise web user access pattern. In the full authorization framework, this primitive pattern is composed with the other, more complex ones.

enterprise-web-authorization-pattern

ABAC Requires Identity and Context

Like groups, ABAC models don’t tolerate excessive complexity well. Attributes, after all, describe users, resources, or environmental states. To quote Michel Prompt again, “Unless those programs, those agents, those devices, share their context, we are facing a…huge challenge.

In terms of attributes, “context” comprises additional information on events, settings, ideas, or other circumstances about an attribute value as well its relationship with other attributes. To take advantage of context in ABAC, you need tools. Policy languages – such as the eXtensible Access Control Markup Language (XACML) – can overlay context on multiple attributes to render authorization decisions. You can also get ABAC with context out of Graph APIs (such as Facebook’s or Microsoft’s). But all the policy languages and APIs in the world won’t help you if you don’t know what the attributes mean, or can’t rely on all instances of the same attribute type to contain accurate data and express consistent semantics.

Economies of Context

There are multiple ways to create what I call “economies of context”:

  • Standardize on application platforms and authoritative sources of identity from a small number of vendors with a highly-integrated application and identity ecosystem.
  • Use a single logical or physical PIP (e.g. virtual directory service (VDS) or a well-provisioned centralized directory) to provide enterprise policy data from multiple authoritative sources.
  • Use a provisioning system acting as the policy administration point (PAP) to push enterprise policy data into application-specific PIPs.
  • Use an identity-as-a-service (IDaaS) system to support complex cloud-based, federated identity environments.

Governance

In some cases, all the above approaches should be combined. But it has to be done within a coherent architectural framework, and attention to the people and process elements through identity governance.  Done well, the result should provide assurance, manageability, and satisfied auditors. In combination with the authorization framework patterns, enterprises should generally:

  • Reduce the number of disparate policy management processes (e.g. access requests, access certifications, access provisioning, role definition). Implement them consistently and robustly across the enterprise.
  • Develop a data model and a data sharing model for your key user constituencies’ (i.e., employees, contractors, retirees, customers, suppliers, and partners) data.
  • Consider implementing the externalized authorization management (EAM) pattern for centralized authorization using centralized policy.
  • Consider implementing a virtual directory service (VDS) as an identity abstraction layer that can map between disparate attribute sources to create the desired views or results that provide context for applications.

Conclusion

With the authorization framework, we provided numerous patterns, and several other architecture artifacts, such as a Decision Tree. If you’re interested in learning more, please contact us.

 

2 Responses to An Enterprise Authorization Framework Requires Identity and Context

  • Very nice article, Mr. Blum.

    I know some vendors define coarse vs. fine-grained differently than you have here, where the granularity is at the enforcement (URL or front-door is coarse-grained, where fine-grained is redacting data/content within an app) layer. It’s just an example of the way terms are over-loaded, causing confusion.

    I think one huge challenge in moving to a better model is the whole audit/certification/attestation and the integrators that implement it. When they have to answer the question of “who has access to what?” it is much easier to say “these users have these roles and these roles have these entitlements” than it is to compute a answer based on dynamic policies in an EAM. Not that the integrators do that kind of role-based certification well (over time), but they’re not incentivized to move to a different model because firms keep paying them to come redo another role model.

    Thanks for the article!

    • Thanks Matt. I guess I just find it more instructive to describe authorization as “coarse” versus “fine” based on the complexity of the policy evaluated, rather than the location. That being said, it is correct that “front door” authorization tends to be coarser than authorization to data inside the applications, but still not universally true.

Tag Cloud
Security Architects Partners Newsletter
* = required field
Categories
Archives