1. Architecture Security Consideration

 

Web services use a message-based approach that enables complex interactions that can include the routing of messages between and across various trust domains. In general Web services can expose message data to security threats and risks.

 

Organizations that implement Web services must be able to conduct business in a secure fashion. This implies that all aspects of Web services including publication, discovery, management, routing and use should be performed in a secure manner. Web services implementers must be able to utilize security services such as authentication, authorization, encryption and auditing.

 

Web services implementations may require, depending upon the degree of threat/risk point-to-point and/or end-to-end security mechanisms as depicted in Figures 1, 2 and 3. Implementers must note that traditional, connection-oriented, point-to-point security mechanisms as depicted in Figure 2, may not meet the end-to-end security requirements of Web services.  However, implementers must note that security is a balance of assessed risk and cost of countermeasures. Depending on implementers risk tolerance, point-to-point transport level security can provide enough security countermeasures.

 

Note: Should add figure that depicts a combined use of p2p and e2e security mechanisms

 

 

 

Figure 1: End-to-end Security Model

 

 

 

 

 

 

 

 

 

 

 


Figure 2: Point-to-point Security Model

 

 

 

 

 

 

 

 

Note: Add a paragraph to state:

The WSA work view security as a feature that could be used across the whole web services stack. The WSA architecture does not conflict with other work that is done in OASIS and W3C WG regarding security. Some of the work is being standardized and the rest may or may not be standardized.

 

1.1 Web Services Security Requirements

 

There are various threats that can affect Web Services messages. For example, message could be modified or read by unauthorized entities, or messages can be sent to Web services that lack appropriate security claims to make them processable. Listed below are the requirements for Web Services security:

 

1.      Authentication to verify identity

2.      Authorization to access resources

3.      Confidentiality such that information is accessible only to intended parties

4.      Data integrity of transactions and communications

5.      Non-repudiation so that party to a transaction cannot deny the transaction

6.      Policy enforcement within and across distributed administrative domains that ensures controlled access to systems and their components.

 

1.2 Web Services Basic Security Elements

 

Web Services can expose an organization’s business systems to make them more accessible to external customers and partners. Web Services messages can flow through firewalls, and can be tunneled through existing ports and protocols.

 

Web services security requires the use of appropriate corporate wide policies that may need to be integrated with external cross-enterprise policy and trust resolution. Organizations may need to implement the capabilities that are listed next.

 

1.2.1 Cross Distributed Domain Identities

 

Web services requestors and providers may communicate with each other using various identity verification schemes from different security domains. Many systems define role based access privileges based on identity. It is important for Web services to be able to support the mapping of identities across multiple domains and even within a single domain.

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.

 

1.2.2 Distributed Policies

 

Security Policies that are associated with client, service and discovery mechanism can be used to define the access privileges of request and responses between parties. These polices can be validated at run time in the context of interaction. Each party in an interaction validates its own policies.

 

1.2.3 Trust Policies

 

Trust Policies are distributed policies that apply to 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 trust 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 asserting the sender’s Identity. A Policy can be described in XML and attached to the service contract. Machines could process, resolve and adjust security based on the given descriptions.

 

1.2.4 Secure Discovery Mechanism

 

Secure Discovery Mechanism enforces policies that govern publication and discovery of a service. 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.

 

1.2.5 Secure Messaging

 

Secure Messaging ensures privacy, confidentiality and integrity of interactions. If digital signatures techniques are used, then it is also possible to ensure non-repudiation of interactions.

 

Techniques that ensure channel security can be used for securing messages. However, such techniques are applicable in a few limited cases. Examples include a static direct connection between a client and a service. For some applications, such mechanisms can be appropriate. However, in the general case, message security techniques such as encryption and signing of the message payload can be used in routing and reliable messaging.

 

In Figure 3, the basic security elements are illustrated.

 

 

Figure 3: Basic Security Elements

 

 

 

 

1.3 Web Services Security Architecture Roles (Concepts): Security Authority and Security Intermediary

 

1.3.1 Security Authority

 

 

In order to be able to facilitate the management of multiple identities, polices and trust relationship at every point of interaction the notion of Security Authority (SA) is introduced. The SA is depicted in Figure 4, where it acts as a facilitator for identity, policy management: authentication, authorization and audit. The SA enables cross-domain trust management, delegation and federation networks.

 

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, a 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:

 

1.3.2 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:

 

1.3.3 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.

1.3.4 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:

 

 

 

1.4 Available Standards

 

This section provides a brief description of current available standards that meets the basic web services security requirements that are illustrated in Figure 3.

 

 

1.4.1 Security Assertion Markup Language (SAML)

 

SAML is an Extensible Markup Language standard (XML) that supports Single Sign On. SAML allows a user to log on once to a web site and conduct business with affiliated but separate Web sites. SAML can be used in business-to-business and business-to-consumer transactions.

 

There are threes basic SAML components: assertions, protocol, and binding. Assertions can be one of three types:  authentication, attribute, and authorization. Authentication assertion validates the identity of the user.  The attribute assertion contains specific information about the user. While, the authorization assertion identifies what the user is authorized to do.

 

The protocol defines how SAML request and receives assertions. There are several available binding for SAML. There are bindings that define how SAML message exchanges are mapped to SOAP, HTTP, SMTP and FTP among others. The Organization for the Advancement of Structured Information Standards (OASIS) is the standards group for SAML.

 

1.4.2 XML Key Management Specification (XKMS)

 

 

XKMS is an XML-based way of managing the Public Key Infrastructure (PKI), a system that uses public-key cryptography for encrypting, signing, authorizing and verifying the authenticity of information in the Internet.

 

XKMS allow implementers to outsource the task of key registration and validation to a "trust" utility. This simplify implementation since the actual work of managing public and private key pairs and other PKI details is done by third party.

 

An XKMS trust utility works with any PKI system, passing the information back and forth between it and the Web service. Since the trust utility does the work, the Web service itself can be kept simple. XKMS is a W3C specification.

 

1.4.3 XACML: Communicating Policy Information

XACML is an Extensible Markup Language standard (XML) based standard, developed by Organization for the Advancement of Structured Information Standards (OASIS) for writing access control polices for disparate devices and applications.

XACML includes an access control language and request/response language that let developers write policies that determine what users can access on a network or over the Web. XACML can be used to connect disparate access control policy engines.

 

1.4.4 Message Integrity and Confidentiality: XML-Signature / XML-Encryption

 

XML signatures are designed for use in XML transactions. It is a standard that was developed at W3C and the IETF (RFC 2807, RFC 3275). The standard defines a schema for capturing the result of a digital signature operation applied to arbitrary data. XML signatures add authentication, data integrity, and support for non-repudiation to the signed data.

 

XML Signature has the ability to sign only specific portions of the XML tree rather than the complete document. This is important when a single XML document may need to be signed by multiple times by a single or multiple parties.  This flexibility can ensure the integrity of certain portions of an XML document, while leaving open the possibility for other portions of the document to change. Signature validation mandates that the data object that was signed be accessible to the party that interested in the transaction. The XML signature will generally indicate the location of the original signed object.