Guest Commentary
Enterprise identity management: Essential SOA prerequisite
by Jason Bloomberg, Senior Analyst, ZapThink, LLC
On first glance, enterprise identity management and service-oriented architectures (SOAs) are unrelated initiatives aimed at solving different problems. Identity management involves establishing an enterprisewide IT user directory and policy management infrastructure that coordinates the identification and authentication of users, as well as the policy-based authorization of those users' activities on systems and applications across the enterprise. Among many other access control functions, identity management enables single sign-on (SSO) for users, allowing them to log in once to access multiple applications across the enterprise. Identity management also provides the policy-based administration capabilities companies need to manage their application security.
SOAs are a different kind of initiative. They represent an approach to distributed computing that provides an abstraction layer that exposes application functionality as business-oriented services that are both location independent and discoverable on the network. As ZapThink has discussed throughout our research, SOAs can help companies embrace heterogeneous IT environments, squeezing additional value out of existing systems and applications while providing a more flexible approach to IT, leading to increased business agility.
Building an SOA can clearly benefit an enterprise's identity management initiatives -- by exposing user directories, policy repositories, and applications' authorization APIs as services, SSO software can enable companies to implement an enterprise identity management initiative in a flexible, cost-effective manner. However, we're discussing the flip-side of this argument: not only are SOAs beneficial to identity management initiatives, but identity management is an essential prerequisite for an enterprise-class SOA as well.
A simple example: Calculating sales commissions
The figure below shows an example of an enterprise portal that allows certain human resources (HR) users to calculate sales commissions by accessing a getSalesCommission Web service in an SOA. The fundamental benefit of the SOA is provided by the service composition layer, which takes the fine-grained Web services that wrap the various back-end systems and exposes coarse-grained business services like getSalesCommission to the business user.
In this example, the getSalesCommission business service touches upon two different back-end systems -- an ERP system that provides a getSalary API call, and a CRM system that exposes a getSalesData API call, each wrapped in a fine-grained Web service. The ERP and CRM systems each have their own security policies, with separately defined users, indicated by yellow and red.
The HR users log into the portal, which authenticates them at the user interface. The ERP and CRM systems, however, each have their own security infrastructure. They might have separate users, separate administrators, and separate policies. In fact, most traditional distributed computing security falls into such islands of security, which describe systems and users on isolated networks or subnetworks. Sometimes the network acts as an island, with its own perimeter security, but users within the network were considered to be trusted. In other cases, the application is its own island. The security policy for the getSalesCommission service, however, is related to, but different from the policies governing the underlying systems.
Sinking the islands of security
There are two areas where traditional approaches to application security break down in the SOA world. First, the identity mechanisms and policies might vary among the various back-end systems -- users might have different passwords and privileges for each system, so when they log into the portal, they may still need to be authenticated to each back-end system.
The second problem area, however, is even more telling, and goes to the essence of how the SOA works: because the service composition layer acts as a layer of abstraction, masking the details of the underlying technology implementation from the users, each service abstracts the user identity context from the underlying applications, making it difficult to associate the users of the overall functionality since the SOA itself provides no overall security context. For example, when the getSalary API call on the ERP system comes in through the Web services interface, how is the ERP system supposed to know whether that call is authorized? The calling party is the getSalesCommission service, or maybe the service composition software that service runs on.
Therefore, the "islands of security" approach breaks down in a service-oriented model, because users can access services located on different systems at different times, and the underlying applications no longer have the user context they require to authorize specific actions. To provide the necessary security for these services, the enterprise needs a single identity management and security policy infrastructure that governs the access to the four interfaces in the example (the portal, the business service, and the two atomic services) in a way that provides the overall security context for the systems, services, and applications. Enterprises must institute policies that apply to their entire enterprise network (including participants invited from outside), and administer that security in a tiered, hierarchical fashion with a centralized root administrator. Departments or other organizational groups may then have their own administrators, but those administrators must in turn be administered by a more senior admin at a higher level within the enterprise.
Extending the example to the real world
The sales commission example above highlights a single task users may wish to complete, but in the real world of business, users execute and participate in a variety of business processes that incorporate application functionality at different points in the process. For example, individuals may calculate sales commissions as a part of a complex payroll process. In an SOA, such processes are themselves service-oriented -- they consist of orchestrated services that may themselves be processes. It is simply impossible to imagine securing such a dynamic, flexible environment without a comprehensive, enterprise identity management infrastructure in place.
In fact, this situation is even more challenging in a B2B environment. As companies build SOAs that expose services for other companies to access, allowing the formation and operation of service-oriented processes that cross company boundaries, companies will need to implement federated identity management that allows multiple companies to interact under a single trust umbrella.
Securing open, loosely coupled systems in an SOA requires a much more sophisticated security approach than traditional distributed computing architectures, involving multiple administrators that support distributed users. Different systems now have different policies and possibly different security mechanisms. As a result, administrators within the enterprise must manage security much more actively than was necessary in the closed, "islands of security" model. In addition, enterprises should centralize their administration capabilities, and implement a hierarchical, delegated administration model to maintain a coherent, yet scalable enterprise security policy. Likewise, when companies seek to work together in a trust relationship, they must federate their enterprise identity management capabilities. Such federation can both take advantage of SOAs within the participating companies, and also forms an essential prerequisite for extending SOAs beyond the edge of the enterprise.
Copyright 2003. Originally published by ZapThink LLC, reprinted with permission. ZapThink LLC provides quality, high-value, focused research, analysis, and insight on emerging technologies that will have a high impact on the way business will be run in the future. To register for a free e-mail subscription to ZapFlash, click here.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.
