BT

Do we really need identity propagation in SOA and Clouds?

Posted by Michael Poulin on Aug 20, 2012 |

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 3rd 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 3rd 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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

identity propagation by Alex Garrison

Assuming a simple case not involving the cloud: User invokes service A to gather information about an asset. Service A in turn composes information from services B and C. We need to have the user identity passed all the way to services B and C to ensure the user is allowed access to the information being composed. Is this not a good case for propagating identity?

If so, take this same case and apply it to the cloud: User invokes service A inside his enterprise to gather information about a customer. Service A in turn invokes salesforce.com to get customer data. Service A also invoke mySaS.com to get a credit report on the customer. Shouldnt the user identity be propagated from service A to salesforce.com and mySaS.com to apply fine grained entitlements?

Re: identity propagation by Michael Poulin

Assuming a simple case not involving the cloud: User invokes service A to gather information about an asset. Service A in turn composes information from services B and C. We need to have the user identity passed all the way to services B and C to ensure the user is allowed access to the information being composed. Is this not a good case for propagating identity?

If so, take this same case and apply it to the cloud: User invokes service A inside his enterprise to gather information about a customer. Service A in turn invokes salesforce.com to get customer data. Service A also invoke mySaS.com to get a credit report on the customer. Shouldnt the user identity be propagated from service A to salesforce.com and mySaS.com to apply fine grained entitlements?


Alex,
thank you for the comment. The unexpected discovery of the role of service interaction/Service Contract/ownership-service boundaries is in this:

1) non-cloud example: services B and C work with service A only, they know service A only, they have trust with service and the request to them comes from A regardless of the motivations of A. Services B and C know nothing about User, they do not have a Service Contract with the User, they do not know whether the User represents another user and so on. As a result, service B and C do not know what to do with the identity of the User (they do not care about it). If B and C are independent services (i.e. there is no shared authority over them and A service, which is typical for large organisations with multiple semi-independent departments), they with create their own logs and people who analyse these logs will no nothing about User as well. Thai is, we deal not with one transaction from User to B or C but with a chain of individual transactions. This is why propagation of User identity to B or C is valueless.

2)cloud example: when "Service A in turn invokes salesforce.com to get customer data", service A has a trust with customer and permission to work with customer's data. However, salesforce.com does not know about this fact but instead, it must know service A and assign access rights to service A. Otherwise, if A pretends to be the customer (identity and authorisation attributes), it is a violation of authentication security for salesforce.com. To keep this security intact, salesforce.com must recognise the request from service A.

Since service A may serve many customers, service A has to be granted permissions (by salesforce.com) for each of them and this has to be adjusted every time when a a new customer comes or leaves. This does not scale and very difficult to manage. A centralised Authority can address scaling but not the trust. In a contrast, service A as a gateway type-of a service, which deals with salesforce.com directly as itself, is scalable and trusted entity (all what is required in a SO Ecosystem). The same relates to mySaS.com.

The key here is that service A is an independent self-contained fully-fledged entity, not a driver for the User/customer. The solution in this case should look as this: salesforce.com or mySaS.com establishes trustful relationship and special explicit Service Contract that grants service A access to private information of users of certain realm (this is how salesforce.com and mySaS.com have to obtain user's data). I a request from A comes for user's data that is not in dedicated realm, it means that this data was not properly registered by salesforce.com or mySaS.com.

Identity agency by Spencer Thomas

Michael, thank you for this cogent presentation. I think I understand what you are saying. Having worked with Shibboleth and previous attempts at federated signon, I am well aware of the issues involved here. In the cases I've worked with, there is an additional constraint, in that there are legal restrictions on what identifying information can be passed to my service by its client. Thus we have to work with a model where the client authenticates the end user, and then passes only information about the user's access rights on to the service.

I'm now thinking about a different scenario. Suppose client A has contracted with service B, giving it access to certain resources provided by service B. Further suppose that service C provides added value, using the resources of service B. Service C, in and of itself, does not have the rights to use any of service B's resources, but is able to use those resources when it is acting on behalf of service A. I need to somehow pass these rights from A to B through C. In other words, C acts as an authorized "proxy" for A with B, but cannot exceed the rights that B has granted to A.

Is there a similar model for this sort of interaction?

Re: Identity agency by Michael Poulin

Spencer, this is a great question; I did not cover it in this short article

Here is the logic I would follow.

1. From your scenario, it is unclear what “that service C provides added value” means. Is this an additional value for A or for B? I assume, it is for A, but this means, in turn, that A knows about C and vice verse, i.e. they have their own Service Contract.
2. If “Service C, in and of itself, does not have the rights to use any of service B's resources”, this means exactly what it says – when B authenticates the requestor=consumer as a C, the request is denied regardless its content. Unfortunately, this is it.
3. Since B is not aware about consumers of C (and vice verse), an expression “when it is acting on behalf of service A” does not make sense (to me). Thus, either C has no rights when approaching B or C has some rights based on the C-B Service Contract. Because the letter is set irrespective to any consumers (of B or C) but because of the business needs of B’s or C’s functionality, rights of A cannot be considered in the C-B Service Contract.
4. Any service may offer a functionality as a proxy (in your example) or as a gateway service in my article. Such service acts as a Janus – it has a ‘proxy’ face to its consumers and a ‘real consumer’ face to its service/provider (the letter does not know about the ‘proxy’ face).
5. Thus, services B and C can identify their consumer as the same A only if A uses the same identity in the Service Contracts with B and C. However, this is up to A and neither B or C can control this. In other words, a statement “C, in and of itself, … is able to use those resources when it is acting on behalf of service A” has no value for B in general.
6. A solution for your task I see as this: consumer A plays a moderator role for all interactions with the service it works with; A, and only A, can reuse information from its Service Contract with B for its Service Contract with C and reverse. We may not assume that services B and C are stateful or stateless and can or cannot store information about its consumers beside Service Contracts (which is private from the service view). Consumer A can request ‘beta’ results from B and, additionally, request ‘gamma’ results from C, and then combine them as needed. There is no guarantee that C will go for additional functionality to service B or to an analogous service D – this is the internal design of C and A has nothing to say about it. There is no power that can dictate certain behaviour to B _and_ C – they are independent services and have to survive on their own (i.e. having redundant resources for their own business continuity).

I have observed a general case of fully independent services. This does not mean that someone cannot or may not create dependent services in certain way suitable for your example. However, the more specific these services in their dependencies on each other, the low their re-usability, shorter life-cycle, and lower ROI.

Finally, how to work with an Agency, e.g., Borikerage in Insurance. It is assumed that the Insurer hires a Broker for 3 business tasks 1) find a Consumer=Insured; 2) advice the Insured on this business, and 3) pass information between the Insurer and Insured. At the same time, Broker does not insure the consumer. Here we have two possible scenarios: an Insured may not interact with the Insurer or may.

In the first scenario, Insured performs all insurance risk writing work, receives a premium from and pays claims to the Broker that, in turn, transfers everything to the Insured and reverse. Everything what the Insurer can offer is in the Service Contract between the Insurer and the Broker; an information about Insured exchanged between the Insurer and Broker is accompanied by an ID=insurance policy but the owner of this policy – the Insured – has no rights to communicate or interact with the Insurer.

In the second scenario, the situation is much more complex because it has an additional risk or discrepancy between an Insurer-Insured agreement and Broker-Insured agreement. However, this does not change the Insurer-Broker relationships and the Broker still accesses the Insurer on its own rights, not on behalf of Insured though many business people would say so (just to simplify the legal contract for the sake of conversation); these rights are the part of the overarching agreement between the Insurer and Broker; otherwise, a Broker and Insurer will die under the pressure of individual contract papers.

Thus, the method I described in the article has a solid ground in the modern business practice.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT