If you remain alert to the trends and changes of the information technology markets, there are moments when you feel that history repeats itself. This has been the case for the past 2-3 years with the raise of so-called Cloud Computing.
It is evident that the combination of virtualisation, hosting, web services, new security protocols, outsourcing, performance enhancements and other infrastructural capabilities has created a new panorama in our business; but how deeply new is the phenomenon?
It is impossible to ignore the fact that various business sectors are moving very rapidly to streamline their IT services by outsourcing all capabilities that can be acquired as utilities in the market. From data storage to off-the-shelf accountancy applications, firewalls and application monitoring, it has become simple, practical and advantageous to use remotely hosted, managed services.
But the novelty of these changes should not obscure the fact that Cloud-like capabilities have existed since very early in the Computing Era: remote, scalable, virtual, shared, resilient server resources were at the core of major corporate and governmental IT infrastructure. While in the past these capabilities were exclusively mainframe-based and mostly used by organisations now they are widely accessible and not restricted to a single type of platform. Their evolution has consisted not in the disappearance of the original platforms, but in the combination of many more platforms and layers of systems “on top” of the first ones. Individual use of remote capabilities has also become a fact of life.
This can be formulated in a single sentence: The history of IT technologies in all areas of business, government and daily life proceeds by multiplying the levels of indirection, the “tiers” of the environment. This is the case in software engineering as well as in hardware systems. A good overview of this progression is captured in the maturity layers described by the SOA discipline:
A) SILO
B) INTEGRATED
C) COMPONENTISED
D) SERVICES
E) COMPOSITE
F) VIRTUALISED
G) RECONFIGURABLE
Source: http://www.ibm.com/developerworks/webservices/library/ws-soa-simm/ IBM Service Integration Maturity Model (SIMM) , October 2005
I prefer to use these SOA categories, instead of assuming that the later stages somehow overcome or displace the previous ones. In fact, today all these layers and steps of the technological world coexist and none is in any danger of disappearing.
This is particularly critical when we work in socio-technical environments (corporations, organisations) where there is a high component of legacy platforms and applications. To address the relationships between the various segments and levels of maturity of the organisation, it is essential to use an SOA approach.
Today, there we see organisations collaborating and sharing information “in the Cloud” but that does not mean that they have abandoned their corporate infrastructures altogether, and it is easy to predict that cloud adoption will be uneven across sectors and geographies. On the other hand, even the most “retrograde” organisations will adopt at least partially “Cloud” services and use either federated or “identity proxy “ approaches to facilitate application access across their boundaries.
Does this sound like the end of corporate identity management? Hardly. Actually, as we analyse case after case of organisational environments, we see that techno-centric “Federated” and “Cloud” solutions do not yield business value when they are executed as a substitute for organisational transformation and identity data governance. So in real business consultancy cases, it will be the rule, not the exception that an Identity Management solution will have a very relevant, primary, foundational service oriented architecture, as the organisation progresses through normal maturity levels.
At the end of this maturation process there is a classical Service Inventory Endpoint solution, a well documented service interface for authentication and authorisation shared by most applications. In turn, this Service Endpoint can immediately become the basis for Identity Federation services; but this evolution has to happen!
For a detailed explanation of the SOA Service Inventory Pattern see:
SOA Design Patterns, Thomas Erl, Prentice Hall, 2009 ; and http://www.soapatterns.org/
Following the considerations presented above, from the n-tier and n-level reality of socio-technical systems we should immediately recognise that the factors behind the “Cloud” trend are not really new. They are not new especially in what they bring for Security Management and Identity concerns. If there are any challenges and problems, these are also not new.
From the perspective of the disciplines of Selection (where I&AM is rooted) the problems faced by an n-tier/n-level architecture are the same for a “closed” collocated corporate infrastructure, or for the outsourced, hosted, “Cloud” infrastructure. In both cases the main problem is one of identity propagation across the infrastructure. That is, the authentication and authorisation of the subject moving across the applications, executing transactions, reading or writing data, etc.
On the other hand, to be fair, the refinement of security techniques –raising precisely from the demands of an n-tier architecture–, create effective ways of offering services and securing their delivery. These techniques –Federation, WS-Security, SAML, XACML, SPML, Policy and Attribute based Access Control, allow us to solve technical requirements and facilitate the introduction of “Cloud Services”.
Let me repeat: I agree that “Cloud Computing” is exciting as it opens up better ways to energise IT delivery, reduce costs, streamline IT departments and free the business of long-standing IT burdens. I agree with this so much that I am working on a new I&AM Service Architecture. The opportunities are excellent, and the reality of the “Cloud” must be embraced and mastered.
Once the essence of the problem is understood, the real challenges of “security in the Cloud” will become clearer.
In my opinion, we have not made more progress in Identity Management Cloud Services because of the excessive influence of some limited definitions of Identity and Security Management.
In the same way as the standard techno-centric, mechanistic thinking modality defines information as an object that needs to be “protected”, the Identity in the “Cloud” debate has been affected by a limited view of the Security disciplines. My own approach is to consider four Security Perspectives, each one with its own concept of Identity:
- Identity as value/subject
- Identity as role/membership
- Identity as substance/object
- Identity as context/protocol
As explained in other posts, there are four root Security Perspectives:
-Direction
-Selection
-Protection
-Detection
For the Direction perspective, information and identity appear as value, more specifically as subjective value, according to the metaphor of “defining trust” that lies at the bottom of this perspective.
For the Selection perspective, information and identity appear as role, concretely as membership into a social or organisational group. The metaphor “allocation of trust” is the key to this.
For the Protection perspective, information and identity are understood as an object, as substance. The assumption is that identity can be reduced to data structures “flowing” in the IT machinery. The guiding metaphor is “enforcement of trust”.
Finally, for the Detection perspective, information and identity are relative and depend on the context and the administrative process. The assumption is in this case that identities will be valid or verified depending on the context as can be surmised from the “verification of trust” metaphor.
How does this help in the debate around “Cloud Computing” and “Identity in the Cloud”. The first result we obtain is to open our minds to different levels and modalities of “identity”. When considered in the whole, in a synthesis of the four perspectives as it were, Identity does not appear anymore as a static object that needs to be stored, hidden and “protected” but as a relationship, as a function, a role, a status, as moral and subjective value.
At that point the mechanisms of Identity Management become less predominant, and the disciplines of Direction, Selection and Detection become more important, actually overwhelmingly important: because we then discover that there can be no technical solution to the issues raised by cross-domain authentication, federated identity, identity provision services and privacy concerns. There can be no techno-centric solution I would say, because all the other aspects depend on the modalities of Trust definition, allocation and verification.
The technical protocols we have now do offer an excellent path to negotiate, secure and verify trust, but trust establishment is originated and actually “happens” outside of the technical realm. It is a compact based on reputation, authenticity, respect, responsiveness, viability and other values.
I believe that the lack of progress in establishing a firm grasp of “Identity in the Cloud” comes from the emphasis on identity as an object, or as a physical substance. From that limited perspective, “Identity in the Cloud” becomes a matter of storing, sending, copying, encrypting, marking, enveloping data. Hence the multiple (very valuable) protocols that have been devised to achieve this (SAML, SPML, XACML) are assumed as complete answers to the challenges of Identity in the Cloud.
Contrary to this trend I propose that we base Identity Management Cloud Services on
a) Establishing and governing Identity Data Ownership as the base of the Definition of Trust.
b) Developing new protocols for the establishment of collaborations, partnerships, customer, citizen and membership roles, as the base of the Establishment of Trust.
c) Adopting Policy, Role, Capability and Attribute Authentication and Authorisation solutions as the next step in the Enforcement of Trust.
d) Standardising Identity Data, Identity Propagation and Identity Assurance processes as the base for the Verification of Trust.
Let’s look now for a moment into a particular aspect of Security, as it related to “Cloud Computing”: Federated Identity Management.
Let’s consider a model scenario corresponding to the Federated Identity Management technology. This model case can have several (perhaps many) instantiations, but essentially such a design will respond to the question: “In the offering and delivery of online products or services that involve multiple supplier organizations and multiple categories of users, how can these organizations and their clients, members, users obtain a seamless navigation experience whilst maintaining per- organisation user identification, access control and audit trail?”
Note that these requirements arise in both consumer-facing and inter-organisation as well as internal/operational settings. The term ‘multiple supplier organisations’ here can imply any operational units that need to maintain some degree of autonomy – it can mean legal entities, companies, divisions, geographical business units, governments, departments, etc.
So the key terms are:
– online products and services
– multiple supplier organizations and multiple categories of users
– seamless navigation for end-users
– per-organisation (internal or external, inter- or extra-corporate) identification, access control and audit trail
These four conditions essentially say that the value of any federated solution lies on the fact that a supplier organization will benefit from the reception of traffic by end users who are *not registered* in a local user repository and don’t need to authenticate locally. These users are logged in with their respective Identity Provider(s).
In other words, Federated Identity Management is a response to the need of *cross-domain authentication”. In recent past, before the commercialization of Security Assertion Markup Language (SAML) this was done with external authentication servers and custom tokens in the HTTP requests. Under the impact of the SAML modality, this is done with external authentication servers and standardised tokens (SAML assertions). It is interesting to note that in both cases external authentication servers are part of the technical solution.
My point is that precisely in the ideal scenario for Federation, the benefit comes from *not* sharing user repositories, and therefore from not having to manage the users centrally to provide transparent/seamless navigation. In this extreme case/scenario, the varieties of identity of the user do not matter: once the Identity Provider has vouched for the user, the contact point on the Service Provider allows access to protected resources.
Obviously, this is an elementary case: we need to add authorisation levels to this solution when policies and roles matter. It is then necessary to modify or enrich the payload of the HTTP request (containing the assertion) to include additional (in some cases non-standard) information elements (attributes) about the user. In the more complex cases a user mapping between the domains needs to be established an there is a need for a new, separate user repository on the side of the Service Provider.
In the limit case (and I have seen many), the Federated Identity Management technologies negate themselves as they end up requiring additional user management on all endpoints. None of the Federated Identity Management products in the market can operate alone in any moderately organisational scenario, and it is essential to integrate these with other technologies, processes, governance and structures to deliver a complete solution.
My thesis is that pure Federation benefits are maximal when user management requirements are minimal.
Several colleagues have asked why I consistenly put Federated Identity Management Capabilities at the end of a specific “layer” in my I&AM layered model.
See:
https://carlos-trigoso.com/2010/09/12/iam-more-than-people-process-and-technology/I explain that this is not because it is impossible to implement a Federated Identity technology in any particular organisation, but because if it is applied without an Enterprise Architecture, if it is disconnected from the other layers and capabilities of the I&AM discipline, it automatically becomes an expensive, sub-utilised, inefficient and ineffective silo.
It is therefore essential to link Federation capabilities with the other layers of the architecture, and in particular, complete the organisational journey in terms of identity data management, role management and identity data control.
Surely more complex technology implementations are conceivable, for example introducing user self-service at the Service Provider end, user provisioning with SPML, access management with XACML, or extensions of ws-security for federated access management. But that only underlines the fact that Federation technologies need much wider Security Architecture to live.
In other words the “ideal scenario” for a single-minded Federation solution is one were user management is not required. Otherwise we don’t have a pure federation scenario but a “federated provisioning” scenario were the Federation technology is essentially a generalised form of cross-domain authentication. Shouldn’t we then think of an integral solution from the beginning?
Summing up: Yes, let’s “do Cloud”, let’s progress Identity Management Cloud Services, but not as another technological silo. The “Cloud” can and should be addressed with a Complete Enterprise Architecture.
I want to close this post by stating that the Federation solutions that make sense for business will require much more than the current protocols and technologies. Independently of these being “in the Cloud” or not –and I am sure many solutions will and should be “in the Cloud”—cross domain authentication will be properly supported by a well-rounded set of technologies, in fact, by a complete I&AM Platform that I will describe in subsequent posts.