Security Requirements in a Services-Oriented Architecture

Positioning of Computer Associates for discussion in the W3C Web Services Architecture Group.

By Igor Sedukhin (igor.sedukhin@ca.com)

 

Security is an overarching concern. It affects every advertisement, discovery and interaction of services and applications in an SOA environment. Corporate-wide policies must govern the SOA network. External relationships require cross-enterprise policy and trust resolution.

 

The next sections outline security requirements by defining architectural elements that form and realize a secure SOA environment. We start with basic security elements and then focus on a Security Authority and a Security Intermediary.

 

Initial terms defined:

 

·         Principal owner: a person, an organization, an institution or a named part of an application (such as a stock quote service).

·         Identity: digitally certifies the presence of a principal owner.

·         Credentials: a set of digital artifacts that constitute an identity (such as an encoded binary number).

·         Policy: rules governing all kinds of interactions, resource ownership, etc.

·         Domain (simplified): a named set of identities and policies that are either public or belong to an organization.

·         Impersonation: executing a function in the security context of a given identity; in other words, on behalf of its principal owner.

Basic Security Elements

Figure 3 - Security Elements in an SOA

Let us outline the basic elements in a secure SOA environment (Figure 3)

 

Secure Messaging ensures privacy, confidentiality, integrity and non-repudiation of interactions. Channel security is applicable in a few limited cases, such as a static direct connection between a client and a service. Message security (that is encryption and signing of the message payload) is mostly used to allow routing and reliable, queued messaging.

 

Distributed Identities that client and service possess. There could be several identities from different security domains. These may include Microsoft Passport and Liberty Alliance in the public domain, and LDAP, Windows Domain account, NIS account, Portal user account, and others in the corporate domain. A client uses an identity to gain access to the service it needs. A service and a client may use their identities to encrypt and sign messages that they exchange. Service and client may exchange identity credentials within a context of initial messages (handshake). That allows further trusted interactions. Service’s identity is optional, and it is perfectly possible to implement a business service without an identity if it always acts on behalf of a client (that is, impersonating the client). Not having a client’s identity translates into anonymous access, which is rarely allowed for business services.

 

Distributed Policies are associated with all involved parties: client, service and discovery mechanism. These policies are a distributed set of rules that define whether a client can request a function from a service and if a service can respond to such a request. Policies are validated at the time of interaction and in the context of the interaction. For example, “allow orders before 4 p.m. for overnight shipping”. Each party in an interaction validates its own policies. For example, a client may not allow interaction with an earlier discovered bandwidth-hungry service when the client is roaming.

 

Trust Policies are distributed policies that apply to the safety of the environment of the other side’s party in an interaction. A client needs to “trust” the environment of a service and the service needs to “trust” the environment of the client. Trust policies may be recursive – they may be defined against trust policies of involved parties and even whole domains. An example of this is “I will trust you if you trust my friend, and my friend trusts you”.

 

Distributed Identities, Policies and Trust can be described and processed by a machine. For example, an X.509 certificate can be embedded in an XML message, thus describing the sender’s Identity. A Policy can be described in XML and attached to the service contract. This allows security to apply to loosely coupled systems without explicit human involvement. Machines could process, resolve and adjust security based on the given descriptions. This is one of the most important advantages of SOA.

 

Secure Discovery Mechanism enforces policies that govern publication of a service and discovery of it by clients. For example, developers of SOA applications for the procurement department may not be allowed to discover services available in the human resources department, if those developers are not entitled to use Human Resources services. When publishing a service, an identity is usually necessary to assert service publication policies, except for some cases of peer-to-peer discovery. When a client discovers a service, it may or may not provide an Identity; discovery may well be anonymous.

 

Security Shield protects service and client in the interaction. For example, the shield would verify that all messages are coming from the same party at the other end, which would protect from malicious intrusion, for example. In many cases, security shield takes on all of the security-related activities for the client and for the service, respectively. Usually a security shield is part of the environment, or platform, that hosts the service or the client. It will let the client and the service perform their semantically important tasks, such as actually placing a purchase order.

 

As with any secure distributed system the following basic processes have to happen in the secure SOA environment:

 

·         Authentication: both parties need to recognize each other’s Identities.

·         Authorization: the client’s rights to interact with the service have to be established according to the superposition of client’s and service’s policies.

·         Audit: actions of the client and the service are monitored and analyzed to prevent threats, such as “denial of service” attack.

·         Trust Resolution: client and service have to decide if they trust each other in the current conditions and with the respective set of policies.

 

Trust resolution is different from regular policy verification in that it governs the safety of execution and the rights to impersonate. For example, a client may not trust a service that trusts another security domain known to publicly share e-mail addresses – a composed privacy violation. A service, in turn, may not trust a client that explicitly trusts a security domain known for violent “denial of service” attacks. In this case, a service implementation does not want to impersonate the client’s identity with the given possibility of an attack.

Security Authority

Managing multiple identities, policies and trust relationships at every point of interaction, every service and every client is difficult and unreasonable. Most policy and trust definitions are corporate-wide and identities that belong to the same principal owner can be easily correlated. Therefore a security authority (SA) is introduced (Figure 4).

 

The SA facilitates identity and policy management: authentication, authorization and audit. It also facilitates cross-domain trust management and enables delegation and federation networks, which are explained in the following two subsections.

 

Figure 4 - Security Authority in an SOA

The SA directly manages internal identity pools, policies and trust. It establishes and maintains relationships with external (public or partner’s) identity pools, policies and trust. LDAP directory or Windows domains are examples of internal identity pools. Microsoft Passport is an example of an external, public identity pool.

 

The SA provides unified service-like interfaces for authentication, authorization, trust resolution and provisioning. Client, service and discovery mechanism use the SA to offload most of the security-related decision making by issuing simple assertion requests. For example, service may assert authorization policy against the SA. Given proper administrative credentials, client, service or a management application may issue provisioning requests to configure and administer the SA. For example, a new public identity can be correlated with an internal identity using a provisioning request. 

 

The SA issues tokens to the principal owners of one or more known or trusted identities. Tokens associate principal owners with the SA and are usually valid for one SA only. A chosen type of identity can be treated as a token (such as with Kerberos or X.509).

 

The requestor uses a regular message handshake (as described before) to authenticate and authorize access to the SA. The requestor can use trusted or transparent mode. In the first case, it is authenticated with a trusted token and sends identity credentials within the request to the SA. In the latter case, it uses the identity credentials (or the respective token) to authenticate and sends the request to the SA transparently, as if it came directly from the principal owner of the identity in question.

 

In addition to policy assertion requests, the SA handles identity requests: assertions and retrievals. An identity assertion request is for the SA to verify that given credentials actually define an identity and that the identity is legitimately owned (proof of possession). For example, the SA can verify the validity of an X.509 certificate. An identity retrieval request is when for a given known identity the SA finds and returns another identity that exists for the same principal owner, but is defined in a different domain or for a different purpose. This process is also known as single sign on. It allows a service to properly choose the available client’s identity to impersonate for execution on a hosting platform or to access legacy systems.

 

Similar to securing interactions, the SA provides for secure discovery of services by clients. Corporate service discovery and publication policies are asserted by a secure discovery mechanism, such as a UDDI registry, against the SA. This provides common, corporate policies application to clients, services, their interactions, advertisement and discovery all together.

 

Essentially, a basic SA provides:

 

Trust

A client and a service typically belong to different security domains when supporting transactions with external business partners. Even internally, departments in a large corporation may be separated into their own security domains. Boeing is a good example of a large scale manufacturer that operates as a federation. Security domains can also be public, as with Microsoft Passport or Liberty Alliance.

 

An SA directly serves only one security domain. For reasons of control and ownership, cross-domain SAs do not exist. An SA serving public security domain can obviously be shared by many businesses and individual users, but it is not cross-domain in any way. Cross-domain discovery of a service could be asserted against a public domain SA.

 

Figure 5 - Cross-Domain Trust Resolution

A client and a service use different SAs in a cross-domain scenario (Figure 5), but still have to interact with each other. The client and service may use different identification mechanisms. The policies of each side have to be reconciled before the interaction starts. It is important to determine if the client can trust the service and its environment to request execution of a function, as well as the reverse. In this scenario, trust resolution cannot be mandated by a central SA and must happen via a bilateral negotiation process.

 

Rather than have a complex negotiation and decision process at every point of the interaction, an SA usually takes it on. This ensures that all involved policies and trust relationships are taken into account. The negotiation is necessary to:

 

1.       Resolve trust between domains and on behalf of the client and the service,

2.       Reconcile policies applicable in one domain to the client and in the other domain to the service (that is, final policy assertions are against a superposition of all applicable policies),

3.       Correlate identities used by the service and the client. For example, to safely impersonate, a service implementation needs the client’s identity in a trusted domain controlled by a trusted SA.

 

An SA either negotiates automatically, when solicited, or in a controlled manner. Automatic negotiation happens any time a cross-domain interaction is initiated. A policy assertion request may incur automatic trust resolution. A solicited negotiation happens on behalf of a party that wants to have a “premeditated” trusted relationship with the domain controlled by an SA. For example, a client may receive a digital certificate that encapsulates a time-bound license to use a number of services. The controlled negotiation happens when it is not possible to resolve automatically. For example, automatic negotiation cannot happen when an end-user has to accept a license agreement or a payment before proceeding with a service.

 

The negotiation process may be implemented separately (such as SA directly to SA) or within the client-service interactions, but decisions are always governed by the respective SAs. For example, a service may assert with its SA that a license certificate is necessary and then would directly request one from the client. The client would therefore request a proper license certificate from its own SA and then submit it to the service directly.

 

In summary, for cross-domain interactions, an SA provides:

 

Delegation and Federation

So far we have described the SA as a role rather than a concrete implementation. An SA may be implemented as a separate entity that is contacted over a network or may be part of a platform hosting a service or running a client. For example, a service run in a Java or .NET virtual machine may use system methods to retrieve an impersonated identity, verify local policies, and so on. Essentially it becomes a point SA.

 

A point SA controls policies, identities and trust for a particular node, platform and running applications. For example, a development server would only allow developers to use hosted services. The higher-level policies, identities and trust are controlled by higher-level SAs, which are usually separate from hosting points: corporate SA, departmental SA, etc., according to the business organization (Figure 6).

 

A corporate SA delegates some policies, identities and trust relationships to a departmental SA, and a departmental SA may delegate some to a point SA. Therefore, a policy assertion escalates up to the corporate SA unless a departmental SA or a point SA can make a conclusive decision. Most decision processing is done by multiple delegated SAs and only a few decisions need to be asserted by top-level SA. This makes it scaleable and well reflects the reality of doing business.

 

Direct delegation is only possible if both SAs are owned and controlled by the same domain (business, organization, individual). As we have outlined earlier, two SAs from different domains need to negotiate as peers to resolve trust, reconcile policies and correlate identities. This peer negotiation process is referred to as federation. Federation happens by the rules and standards laid out in public. This includes protocols and patterns of negotiation. Even though the negotiation process is bilateral, it can be moderated by a third-party facilitator trusted by both sides. For example, a public SA may facilitate identity correlation (both sides map to and from the same public identity pool).

 

Figure 6 - Federation and Delegation Networks

Delegation and federation are logical processes; actual SA implementations may vary. To improve efficiency, a logical SA may be implemented as a load-balanced cluster of SAs or as a number of distributed, replicated SAs.

Security Intermediary

When describing security in an SOA, we have outlined the role of a security shield that protects the service and the client. SOA is based on messages and messages compose into interactions. Security applies to interactions, and therefore, it is reasonable to apply common security activity (authentication, authorization, audit, and trust resolution) to the messages themselves, rather than to particular implementations of a service or a client. A security intermediary is introduced to enforce secure interactions (Figure 7).

 

Figure 7 - Security Intermediary in an SOA


A security intermediary moderates message traffic in client-service interactions. It interrogates messages looking for security-related information, such as protocol requirements and headers. Then it contacts an SA to assert policies, retrieve correlated identities, and solicit trust resolution. An intermediary may change messages according to the policies and capabilities of a service and a client. For example, it may swap identity credentials to allow a service to properly impersonate on the hosting platform.

 

A security intermediary is not simply a protocol firewall. An intermediary is aware of the business semantics of the interactions, capabilities and requirements of both the client and service. This specifically applies to cross-domain interactions. A service may require a license certificate. A client-side intermediary detects that (it may interrogate the service contract) and requests a certificate from the respective SA. A client-side SA may decide that according to the policy, the licensed service cannot be used (after 5 p.m., for instance). The intermediary enforces that decision by sending a fault message to the client.

 

A security intermediary may moderate interactions for multiple distributed services and multiple clients. That provides fewer points of enforcing common security for many service and client implementations. It also allows services and clients to migrate from one hosting node/platform/network to another without affecting the level of protection of their interactions.

 

While the cross-domain scenario is the most compelling reason to use security intermediaries at both sides, an intermediary can take on some burdens when building internal, secure, loosely-coupled SOA applications.

 

Figure 8 - Security of Interactions

Modern software products offer built-in services, and even hardware appliances are envisioned as being services-enabled. It would be a daunting task to keep this kind of SOA infrastructure in compliance with changing standards. Adapting to new protocol features, adapting to new security models and keeping corporate policies in check for every system that hosts services is a major challenge. Therefore, it is reasonable to allow trusted, highly secure point interactions between an intermediary and granular services such as appliances, and let the intermediary proxy those interactions to produce generic, standards-compliant, controlled interactions with any other SOA application (Figure 8). For example, trusted interactions may use a certificate-authenticated secure channel and generic interactions may use flexible authentication and message security over a routed protocol.

 

In summary, a security intermediary provides distributed: