Do we really need identity delivery in SOA and in the cloud?

It developers, especially IT security professionals, have struggled for years to create an enterprise-class identity control mechanism. One of the most well-known initiatives and models in this field is single sign-on (SSO), where the identity of a single end-user can be passed between systems and recognized throughout the enterprise.

In today's IT environment, security issues also have to deal with service-oriented environments and cloud computing (cloud). Many corporate security professionals and vendors have concerns about services and the SSO aspect of the cloud. Still, a simple question needs to be answered: Is it possible to establish SSO for SOA and cloud from a business perspective? Before developing this SSO, we must understand that the security execution environment for identity control has changed as we move into service-oriented ecosystems (so ecosystem) and clouds.

Service-oriented ecosystems

The Oasis Reference Architecture Foundation (SOA-RAF) [1] extends the service-oriented Architecture (SOA) to the concept of so ecosystem, which focuses on the SOA architecture. So ecosystems can be interpreted as "a space in which people, processes, and machines act together to deliver business capabilities as services to themselves and to larger communities to achieve their goals".

In an so ecosystem, there may not be a single person or organization that can really control or take charge of the entire ecosystem. Any "centralized" infrastructure, management or control function, for example, exists only in the case of a single service that has entered into a free commercial contract, such as between their suppliers or the owners. An so ecosystem is associated with both business and technology. This allows the maintainer to focus on both the technology and the business. In the cloud, for example, technical identity management is influenced by the financial relationships and other constraints that provide the cloud business.

The constraint of Ownership

Soa-raf defines a perspective for the ownership of so ecosystems: "This perspective focuses on the concerns of the so ecosystem with respect to owning and managing soa-based systems." Rather than being automated to solve many of these concerns, they often contain a human-based process, such as a governance body. ”

Soa-raf continued to emphasize that "ownership ... There are a number of different challenges to having other complex systems in the so ecosystem, such as the Enterprise suite. Because when a system spans multiple owning domains, either party has strict restrictions on control and authorization. "The concept of ownership is not really taken into account in corporate security, because the enterprise itself is composed of a single ownership domain."

The single ownership domain allows SSO, while ignoring the mix of old and new systems, whose applications are embedded in security or not at all. In the enterprise, security experts often have unrestricted access to each system in it and are responsible for the security of all enterprise units in their information systems. An so ecosystem permeates the boundaries of ownership, and security experts need to deal with a variety of ownership domains that have different business, technical, and security requirements.

Service ownership boundaries

Soa-raf declares that each service owner or provider may have its own special rights or policies. Since the most important services in an enterprise are commercial services, they generally have business owners who are not part of it jurisdiction, such as BU, group or team, department or line of Business (LOB). In this case, it is just a development and maintenance assistant, not an owner. This, in turn, greatly affects the security solution.

Soa-raf explained, "even if ... is within a single organization, and there is often a problem of ownership boundaries between different teams and departments. This reflects the reality of the Organization, but also reflects the organizational management of the real intentions and motives ... Therefore, early consideration of the impact of multiple boundaries on an soa-based system provides a solid basis for dealing with any form of existence, rather than considering whether or not these boundaries exist. ”

The business and its technical services may belong to the same security/identity domain, forming a consistent commercial ownership and a corresponding boundary line. In addition, a domain may cover the ownership of one or more businesses and form the authentication authority for that domain.

The concept of business services may be summed up by the "Knight Rule of SOA ownership" [2]:

The service is mine, but it's not mine.

The customer is mine, but not mine.

The partner is mine, but it's not mine.

The supplier is mine, but it's not mine.

In other words, the service or customer only knows and sees their direct contact. They do not care how their contacts are executed or who they serve in their business dealings. If in reality, any one of them is concerned, it shows that the service-oriented is not fully implemented.

Commercial ownership boundaries

The problem with commercial ownership is that its boundaries are opaque to technical solutions, including services and their associated security controls. In an identity domain, participants may agree to recognize each other's identities, and the entire system will work as an enterprise with any SSO. Similarly, participants may refuse to open their borders. Any business or service ownership is independent of each other (otherwise it is not a title). This means that if a security professional needs to modify security information related to the service, it needs to obtain consent from its owner.

Further, it cannot simply enforce the use of specific security services, such as policy enforcement, authentication services, licensing services, identity management services, and so on. It is necessary to obtain the permission of the commercial service and its customers first. The Soa-raf stipulates that such agreements exist in the form of service contracts. In fact, in the so ecosystem, the service contract set replaces the centralized authentication and authorization.

Service contracts and financial boundaries

A service contract includes at least service interfaces, interaction and execution policies, special function agreements, communication channels, expected results, and SLAs. As the basis of customer-service relationship and interaction, service contract also plays a special role in the cloud.

Service Contracts link business entities in two of clouds to verify the different interests and purposes of these entities. While it may be possible within the enterprise to agree to share identities across service-ownership boundaries (as a result of a single authorization from the enterprise), in the cloud, financially independent businesses do not believe in foreign identities (which has been validated by the adoption of PKI).

For each cloud vendor, the financial benefits are always above all. Financial viability in the cloud is more important than a sensible solution. For example, if a cloud vendor maintains its certification authority for its customers, why should he accept that external consumers pay security fees to external certification authorities? Why don't these customers pay directly to the cloud provider? It's a business problem, not a technology.