Manage Learn to apply best practices and optimize your operations.

Extended enterprise poses identity and access management challenges

Cloud and distributed computing have caused many enterprise IAM challenges. Eve Maler details how Forrester's Zero Trust model can help.

At Forrester Research, we often hear our clients are struggling with an identity and access management (IAM) landscape that increasingly crosses enterprise boundaries. They tell us: “[Software as a Service] SaaS apps are making our existing methods of access management useless.” “We can’t just Kerberize our apps anymore… If we keep on doing security in domains, it’s pointless.”

The Zero Trust identity vision, with its emphasis on the open Web paradigm, plays into a larger vision that some security pros label Enterprise 2.0.

These comments shed light on the growing disconnect between traditional IAM and the new extended-enterprise reality, in which a business function is rarely, if ever, a self-contained workflow within the infrastructure confines of a company. The extended enterprise challenges IAM in three unique aspects: 1) stumbling blocks in cross-domain user provisioning; 2) weakened control of authentication and authorization; and 3) siloed IAM approaches to different purposes and populations.

To unify and improve access control across the extended enterprise, an IAM approach must be able to withstand extreme heterogeneity in the business infrastructure. This, we believe, starts with Forrester’s Zero Trust information security model, which eliminates the idea of distinct, trusted internal networks versus untrusted external networks. It is a stance toward access that requires security pros to verify and secure all resources, limit and strictly enforce access control, and inspect and log all network traffic.

To take the concept a step further and realize a Zero Trust identity paradigm in the enterprise, security pros must apply three important rules: 1) plan for both outward and inward identity propagation; 2) formalize and protect the interfaces for IAM functions; and 3) use and advocate standards for IAM interfaces. The realities of today’s hybrid IT infrastructures and complex business demands dictate that if an enterprise only utilizes traditional approaches suitable for the non-extended enterprise of the past, it could be forced to pay – to address integration costs, agility, or regulatory compliance -- whenever users cross security domain boundaries to use technology functions that form a virtual part of the business. To avoid this scenario, follow the three rules below.

Rule No. 1: Plan for both outward and inward identity propagation
Your organization is authoritative for the identities of its own employees, of course. But others are authoritative for additional populations who need access to your systems, access you must control. Enterprises must prepare to “consume” external identities, such as from companies representing partners and customers. This will require work to accept inbound single sign-on authentication by users coming from outside the organization, limiting responsibility for managing those users, yet supporting the need for secure external access to internal systems. This rule requires a change in mindset.

Rule No. 2: Formalize and protect the interfaces for IAM functions
For many years, security pros have begged line-of-business developers to stop baking authentication and user management functions into applications. Ideally all apps should concentrate only on their central business functions and outsource authentication to a specialty service. Why is it more important than ever to externalize and centralize this function? Because it's likely to serve apps other than the ones controlled by your organization, and by users who are reaching in from outside your firewall.

More information security models

Study for the CISSP exam with these information security models.

Utilize information security models to evaluate the process maturity of security functions.

The secret to making progress is to push Identity as a Service (IDaaS) to its logical limit, into the realm of the open Web platform. Enterprises must expose their authentication, provisioning and authorization functions with application programming interfaces (APIs) that can serve both internal and external client apps in need of access protection.

In so doing, in a sense each enterprise will become its own IAM cloud service provider. These services, of course, must be protected as you would any open Web APIs exposing core business functions. The IAM services themselves can recursively play a role in this protection. Intuit Inc., the company behind the popular Quicken software, built a central identity service that could be hosted on-premises or in the cloud. It then built a layer over all of its own apps that could test all inbound traffic using this service.

Rule No. 3: Use and advocate standards for IAM interfaces
The Zero Trust identity vision, with its emphasis on the open Web paradigm, plays into a larger vision that some security pros label Enterprise 2.0. The goal: To couple systems as loosely as possible, avoiding dependencies on technologies such as Integrated Windows Authentication (IWA), Active Directory, LDAP or Kerberos wherever feasible. Extended enterprises can’t rely on internal-only communications, and thus it’s not a good idea to invent proprietary IAM APIs where alternatives exist. Strive for interfaces based on global standards that define well-accepted and loosely coupled messaging around IAM functions.

Zero Trust identity is a model, not a product
When starting from scratch, an enterprise may be tempted to buy its way into Zero Trust with a cloud identity system or service, but IAM functions -- such as provisioning, authentication and authorization -- must first be conceived as APIs. This model can benefit your efforts to improve identity and access management services even when you apply it strictly to internal applications and users.

About the author:
Eve Maler is a Principal Analyst at Forrester Research, serving Security & Risk professionals. 

This was last published in July 2012

Dig Deeper on Privileged access management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.