Do we really need identity propagation in SOA and Clouds?

IT developers and, especially IT Security specialists struggled for years trying to create an identity control at the enterprise level. The most known initiative and model in this area is Single Sign On (SSO) where an identity of an end-user can be propagated between systems and can be recognized across an enterprise.

In today’s IT reality, security has to deal with service-oriented environment and Cloud Computing (Clouds for short). Many corporate security specialists and vendors are concerned about SSO for services and Clouds. However, a simple question - "Is it feasible having SSO in SOA and Clouds from a business perspective?" - is still to be answered. Before developing such SSO, we have to understand that the security execution context for identity controls had changed when we stepped into the Service-Oriented Ecosystem (SO Ecosystem) and Clouds.

Service-Oriented Ecosystem

OASIS Reference Architecture Foundation (SOA-RAF) ^[1] extends a notion of service-oriented architecture (SOA) to the concept of SO Ecosystem, which includes SOA for architectural concerns. SO Ecosystem may be explained as "a space in which people, processes and machines act together to deliver business capabilities as services in order to further both their own objectives and the objectives of the larger community".

In a SO Ecosystem, there "may not be any single person or organization that is really "in control" or "in charge" of the whole ecosystem." Any "centralized" infrastructure, management or control functions, such as security, exist only to the extent of freely agreed contracts between individual services, i.e. between their providers or owners. A SO Ecosystem resides between Business and Technology, and within each one of them. This allows operation with both technical and business concerns. For example, in the Clouds, technical aspects of identity management are affected by financial relationships and constraints between Clouds providing businesses.

Constraints of Ownership

SOA-RAF defines a viewpoint on ownership in a SO Ecosystem as, "This viewpoint addresses the concerns involved in owning and managing SOA-based systems within the SO ecosystem. Many of these concerns are not easily addressed by automation; instead, they often involve people-oriented processes such as governance bodies."

SOA-RAF continues, "Ownership ... in a SO ecosystem raises significantly different challenges to owning other complex systems - such as Enterprise suites - because there are strong limits on the control and authority of any one party when a system spans multiple ownership domains."  A concept of ownership was not really considered in enterprise security because of a single ownership realm constituted by the enterprise itself.

This single ownership realm is the enabler of SSO despite the mixture of old and new systems, applications with embedded security or no security at all. In an enterprise, security specialists have unconstrained access to every system in IT and are responsible to all business units (BU) for the safety of their information systems. In a SO Ecosystem penetrated by ownership boundaries, security specialists have to deal with multiple ownership realms that may have different commercial, technical and security preferences.

Service Ownership Boundaries

SOA-RAF states that each service owner or provider may have its special rights and policies. Since the most important services in the enterprise are Business Services, they usually have business owners such as BU, groups or teams, departments or line of business (LOB), which are outside of IT authority. IT in this case is only a development and maintenance arm, not an owner. And this affects security solutions a great deal.

SOA-RAF explains, "Even... within a single organization, different groups and departments nonetheless often have ownership boundaries between them. This reflects organizational reality as well as the real motivations and desires of the people running those organizations... Thus, an early consideration of how multiple boundaries affect SOA-based systems provides a firm foundation for dealing with them in whatever form they are found rather than debating whether the boundaries should exist."

Business as well as Technical Services may belong to the same security/identity realms that are formed in line with business ownership and related boundaries. Also, one realm may cover one or many business ownerships, which recognize the realm’s Authentication Authority.

A concept of business service ownership may be summarized via "Knight Rules of SOA Ownership" ^[2]:

• A Service of my Service, is not my Service
• A Consumer of my Consumer, is not my Consumer
• A Partner of my Partner, is not my Partner
• A Supplier of my Supplier, is not my Supplier

In other words, services or consumers have knowledge and visibility of their immediate contacts only. They do not care about how their contacts operate or who they serve in their business transactions. If in reality anyone of them does care, this indicates that service-orientation is not in place yet.

Business Ownership Boundaries

The problem with business ownership is that its boundaries are not transparent to the technical solutions including services and related security controls. Within an identity realm, participants may agree to recognize an identity of each other, and the whole system works like in any enterprise with SSO. Equally, participants may disagree to open their boundaries. Every business or service ownership is totally independent from another (otherwise, it is not an ownership). This means that security specialists have to obtain permission from the owners if security related changes have to be made to the services.

Furthermore, IT cannot simply enforce using specialized Security Services like Policy Enforcement, Authentication Service, Authorization Service, Identity Management Service, and alike - business services and their consumers have to agree on these services first. Such agreements exist in the form of a Service Contract, defined in SOA-RAF. Actually, a chain of Service Contracts replaces centralized authentication and authorization in a SO Ecosystem.

Service Contracts and Financial Boundaries

A Service Contract includes service interfaces, interaction and execution policies, special functional agreements, communication channels, expected results and SLAs, at a minimum. While a Service Contract is the foundation on which consumer-service relationship and interactions are based, in Clouds it plays a special additional role.

A Service Contract connects two business entities in the Cloud and demonstrates different interests and objectives of these entities. Though inside an enterprise it is possible to agree on sharing identity tokens across service ownership boundaries (because of the single enterprise authority), in Clouds financially independent businesses would not trust foreign identities (as an adoption of PKI has demonstrated).

Each Cloud Provider preserves its financial interests above all. Financial feasibility in the Clouds is more important than a sensible technical solution. For instance, if a Cloud Provider maintains an Authentication Authority for its consumers, why would it accept that external consumers would pay security fees to an external Authentication Authority? Why wouldn’t these consumers pay the Cloud Provider instead? It is a matter of business sense, not technology.

To Propagate or not to Propagate?

The business reality of ownership and commercial boundaries for services leads to a simple conclusion - a propagation of identity in the chain of interacting services in a SO Ecosystem, especially in the Clouds, makes sense only between directly communicating consumers and services. Further propagation is useless because services contract their consumers only. The identities of other consumers have no value and constitute no obligations for the service.

There have been arguments surrounding a need for a business transaction audits that pass across several services and about related propagation of an end-user identity. This requirement may be a part of the terms of an authentication cover if services belong to the same Authentication Authority control. If not, each independent service has its own audit according to its own policies. For independent services, there is no a single business transaction crossing their boundaries; instead each pair of interacting consumer-service constitutes individual transaction, which contributes in a chain of transactions for an outside-in view.

This, however, does not prevent services from receiving and transmitting whatever external data including the identities of end-users. However, these identities have no security implications on those services.

Federated Identity vs. Identity Federation

Corporate security has widely used Federated Identity (FID) methodology that utilizes an identity "token" associated with an entity - person, or system, or application. This token is "federated" because it is trusted in different identity realms. Such trust is usually based on a super-Authority situated above identity realms, which cannot exist in a service environment split by ownership boundaries.

Service and commercial boundaries constitute a new execution context and reality for an identity control. Particularly, when working in Clouds we cross the line from Technology to Business where values, intents and solutions have different reasoning and justification and where the value of revenue prevails over the value of technical dexterity. For instance, Tim Mather published in RSAConference.com, "When it comes to federated identity management (FIM) in the (public) cloud, FIM is 'broken'.  It is not the technology that is broken... It is the business process (i.e., credential acceptance) for FIM that breaks" ^[3]. Talking about a 3^rd Party authentication based solution, he explained, "The problem has not been technology, but business considerations, and specific legal issues around accepting an authentication credential issued by another organization.  (OpenID effectively skirts this issue by not being trustworthy enough for business transactions.)"

A Cloud PaaS illustrates the problem with FID. The PasS is supposed to offer specialized development tools to work on the platform but unfortunately, no PaaS Provider can offer developers the full spectrum of development and testing tools used today in "internal" IT. Either this Provider or developer will end-up with a dozen of different offerings of development tools from different Cloud Providers. Is IT going to open its security realm for all of them? Additionally, if just one of those Providers appears to be a Public Cloud Provider, IT risks opening its systems and applications to the entire world. Ask corporate Business what they think about such an opportunity.

This, however, does not disturb Microsoft’s Identity Architect Kim Cameron who announced a modern Microsoft’s vision on FID named Identity Management as a Service (May, 2012) that is based on Azure Active Directory ^[4]. It offers the same centralized identity control ignoring service independence and ownership boundaries. This solution brings no additional value to a Clouds consumer beside an additional high risk of getting all enterprise identities out of the enterprise’s control. About 6 years ago, Eric Norlan wrote, "companies would find identity data too important to hand-over to others" ^[5]. This statement still stands.

In contrast with FID, an Identity Federation (IDF) is a structure of distributed Authentication Authorities that serve only their own members but can federate an authentication request based on trust relationships between them. Members of these authentication realms rely on their own authentication mechanisms (resident Authentication Authority) that include two options. In the first option, every service in the identity realm engages its resident Authentication Authority to confirm an identity of the user or requester of the same residential realm. In the second option, if an identity of the user is unknown to the resident Authentication Authority, the request for identity verification is propagated through a federation of Authentication Authorities until it is verified or denied. The problem is in that the local business does not trust even federated Authentication Authorities and will not accept their verification. That is, another federation mechanism is needed.

Solution based on the Identity Federation Model

Among "SOA Design Patterns", there is a pattern-candidate known as Federated Identity Pattern ^[6]. Unfortunately, this pattern suffers from the same illness of a vague name as Web Services technology does. While the name of this pattern points to FID, its content is closer to the IDF. This pattern respects the independence of identity realms and does not try to link them with an unified token. Instead, it proposes having a Cloud Authentication Broker between different identity realms, e.g. A and B, which relate to their Authentication Authorities. The Cloud Authentication Broker utilizes its trustful relationships with A and B and will convert an identity token from A to an identity token for B. The Cloud Authentication Broker will then provide the converted B-identity token to the requester in A so that the requester in A can directly engage the services in B with the B-identity token.

However this pattern says nothing about what might happen if a requester in A shares the B-identity token with his or her friend in the C realm. This propagation pattern continues through other realms and can reach a malicious entity, which might be interested in working around the trust and control required in B. Hence the appropriate IDF solution should be based on a direct agreement between resident Authentication Authorities thus eliminating the need for a 3^rd Party Cloud Authentication Broker.

Assume you control the Authentication Authority in your identity realm. One of the services in your realm may be also a member of an external authentication realm. A reverse case is also true - each external partner’s realm may have a service that operates under the authentication riles in your realm. We call such services Realm Representatives (RR). Apparently, every service may be a member of every identity realm but maintenance of such membership is too complex and is an unnecessary extra.

Thus, your RR represents all requests from your resident consumers for the capabilities of an external identity realm. At the same time, as a member of an external identity realm, your RR may be authenticated as a service consumer in that external realm. The RR plays the role of an ambassador or delegate in an external realm. The same relates to the RR of external realms in your resident realm. Your identity realm may have as many RR as many different identity realms you work with.

The main difference between the RR and centralized FID is in that an authentication provider in FID exists as a separate infrastructure entity while the RR is a real business service operating under residential identity controls and, therefore, may be trusted by local business participants. Relationships between consumer and service depicted in the Services Contracts make cross-realm authentication authorities unneeded.

Finally, it is necessary to outline that a notion of RR is very well in line with the concept of service orientation in Business. The RR fulfills one of the fundamental requirements of service-oriented Business -"in order to conduct a business with someone, we have to know this someone". That is, before a service interaction may take place, a consumer has to set up trustful relationships with the provider or owner of that service. In the IDF, this is the relationships between a real consumer and related RR in the role of service delegate as well as between the RR and a service in another identity realm, as shown in Figure 1.

(Click on the image to enlarge it)

Figure 1. Realm Representatives for two identity realms.

A RR may be viewed as an intermediary, which reminds one of the ESB system. Technology tends to place an ESB system between consumers and services to de-couple them to the level where they do not know about each other. It is regrettable because it violates ^[7] both business interaction requirement and the service interaction model defined in SOA-RAF. If an ESB wants to hide the service and manage anything in the service interaction besides message routing and endpoint resolutions then it has to become a service or service delegate itself. It cannot be a part of the infrastructure, which implies it has to possess and provide all related business responsibilities to consumers like a RR does.

A Practical Example

Assume we have a consumer company, Ace Corporation and two services, Catering and FoodPro. The Ace Corp. and Catering service belongs to the identity realm Town while FoodPro belongs to the identity realm Vill. Ace has established trust and agreed on certain contractual terms with Catering to serve Ace’s canteen. Thus, Ace may invoke certain functions/operations of Catering. The contract between Ace and Catering states that Ace is interested in and ready to pay an agreed price for local food ingredients only and will not cover delivery from outside of Town.

Some information abut Town and Vill is public and known in both realms. However, it is not enough for operating in these realms, which requires compliance with residential policies.

Apparently, Catering has to engage an additional capability similar to the one provided by FoodPro because of the size of Ace’s orders. Catering is aware of Vill but cannot deal with its members directly not being a member of Vill. At the same time, it is known that Town’s Truck service has a membership in the Vill realm already. The Truck service promotes its capability to deliver products from business services in Vill.

(Click on the image to enlarge it)

Figure 2. Interaction of Business across security boundaries.

So, Catering contracts Truck service in Town. Truck served FoodPro before and can get some discounts on the delivery, i.e. it can use certain functionality of FoodPro available for the Vill residents only. Moreover, Truck service can contract any food supplier in Vill and take advantage of local service competition. This is an additional business aspect that appeals to Catering and affects its decision to go with Truck service rather than become a member of the Vill realm itself and struggle for the market share over there.

When Ace sets up a service contract with Catering, the latter sets up a supporting service contract with Truck service, which, in turn, sets up a related service contract with FoodPro as shown in Figure 2. It is possible that Truck signs a service contract with Catering even before signing a supporting service contract with FoodPro. When FoodPro receives a contractual request from Truck service, FoodPro does not ask questions about how it was triggered because the request is made in Vill. So, if FoodPro accidentally receives an identity of Ace from Truck, then FoodPro simply would not know what to do with it.

Thoughts to Take Away

In a real-world SO Ecosystem and in Clouds, propagation of end-user identity is useless and even insecure (one business service can learn who are the consumers of another business). We have established the fact that different authentication or identity realms, as well as different service and business ownerships, are in competition in Clouds because of antagonistic commercial interests. So, investments into the propagation of end-user identity beside the scope of directly interacting entities are a waste or resources and funds.

We have learned that services are only concerned about their immediate consumers and suppliers and do not want to deal with consumers of other services. Services or consumers may need the functionality provided by services in foreign identity realms and the one commercially sound solution for crossing realm boundaries (as well as the ownership boundaries) is the proposed RR-based Identity Federation model. In this federation, all services and consumers stay in their identity realms under the controls and protection of their residential Authentication Authorities while the latter federate with each other via shared realm representatives.

Resources

1. Reference Architecture Foundation for Service Oriented Architecture Version 1.0 . Committee Specification Draft 03 / Public Review Draft 02, July 2011. On-line resource
2. Michael Poulin, "Knight Rules of Ownership in Service-Oriented Ecosystem" Business Ecology Initiative & Service-Oriented Solution, ebizQ, Jun 2012. On-line resource
3. Tim Mather, "Federated Identity Management in the Cloud" Experienced Security ,Dec 2010. On-line resource - Federated Identity Management in the Cloud
4. Kim Cameron, "Identity Management As A Service" Kim Cameron’s Identity Weblog, May 2012. On-line resource
5. Eric Norlan, "Identity management as a service" Digital ID World, Apr 2006. On-line resource
6. Federated Identity Pattern . SOA Patterns, a Community Site for SOA Design Patterns. On-line resource
7. Michael Poulin, "Does ESB fit with Business Service?" Business Ecology Initiative & Service-Oriented Solution, ebizQ, Aug 2009. On-line resource

About the Author

Dr. Michael Poulin is a Head of Business and Technology Architecture at consulting company BuTechCon, Ltd., in London, UK, that helps clients in enterprise-level architectural solutions for business and technology in the EMEA region. He authored a book "Ladder to SOE" (Service-Oriented Enterprise) and several articles on SOA governance (published by InfoQ) and Cloud Computing. He is a Member of OASIS and works in the SOA Technical Committee, Reference Architecture Foundation (RAF) sub-Committee where he contributed in all three drafts of the Committee Specification of SOA RAF. He authored SOA Module for certification programme for Associate Architect Curriculum,  included in IASA Body of Knowledge, and currently publishes a BLOG with ebizQ.