The science of enterprise security

In the conventional enterprise application security realm, there is an underlying concept of a trusted computing base (TCB). The TCB provides mechanisms for enforcing a security policy that protects the resources within the controlled environment. This is equivalent to providing a security perimeter that protects valuable resources.

Web services do not have a clear notion of a security perimeter. SOA is a new approach to distributed computing, where application functionality is abstracted as business services that are location-independent and discoverable on the network. Web services architecture allows service composition, which may engage many different service providers distributed across different platforms and enterprises. In such an open environment, distinguishing legitimate service requests from illegitimate ones becomes a challenge.                                                                                                                         

Messaging Security       

A message usually hops through various intermediaries to reach its final destination. It is critical to maintain the confidentiality of sensitive information so that no unauthorized entity can gain access to it. It is also be important to evaluate whether or not a message payload was modified in transit ensuring message integrity. In most B2B scenarios, it is essential to establish the message authentication, which guarantees that the message was created by the claimed identity. Non-repudiation is also an important requirement in B2B message payloads. Non-repudiation guarantees that the sender cannot later claim that they never sent the message.

Trust  

The primary intent of SOA is the loose coupling of services. This loose coupling makes the issue of trust quite explicit. The WS-Security specification defines trust as "…the characteristic that one entity is willing to rely upon another entity to execute a set of actions." A truly compliant SOA manages trust between internal entities via ‘single-sign-on’ design and trust between B2B entities through a ‘target authenticated’ design. [1]

 

 

Single-Sign-On design  

Distributed Policies

Enterprise must ensure that any communication with an external entity (a user or application) is compliant with the security policies in force. Policies are used to describe a broad range of service requirements and capabilities. For example, an organization may use a policy to define a security requirement for encryption. Policies are validated at the time of interaction and within the context of the interaction.  

Identity Management

A client uses an identity to gain access to the service it needs. Internally, a single-sign-on strategy is the ultimate goal with iterative phases in the journey. Externally, there could be several identities attached to a single user in different security domains resulting in the impracticality of a single-sign-on policy. The security infrastructures may vary among the various backend systems, so users may need to be authenticated for each system. The other problem is related to the SOA service composition layer, which might be calling many different atomic services falling under different security domains. The absence of overall security context makes it difficult to associate multiple user identities.  

Interoperability

For different IT systems and infrastructures to be able to work seamlessly together, they need to be able to communicate. Which means they need to use the same set of protocols or standardized structures. The foundation of the OpenWare SOA Compliant Interoperability module is WS-Security.

WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies.

WS-Security also provides a general-purpose mechanism for associating security tokens with messages. No specific type of security token is required by WS-Security. It is designed to be extensible to support multiple security token formats. For example, a client might provide proof of identity and proof that they have a particular business certification.

Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message.

The following parts of the standard, authored by IBM, Microsoft, RSA Security and VeriSign, are of particular relevance:

1. WS-Trust describes a framework for managing, establishing and assessing trust relationships to enable Web services to securely interoperate.
2. WS-SecureConversation describes a framework to establish a secure context for parties that want to exchange multiple messages
3. WS-SecurityPolicy describes general security policies that can be associated with a service.

What WS Security does, and why it is such an important first step, is it enables companies doing business with WS to encrypt selected parts of a transaction and automatically share security token information (regardless of platform or protocol), as opposed to the more commonly used SSL, which is simply a way to encrypt an entire channel of communication. By allowing selected, messaged-based encryption, WS Security facilitates data sharing while giving senders the peace of mind of knowing sensitive information is only viewed by those they authorize.

Security Standards  

Additional standards are complimentary and join with the WS Security specification to form a Security stack that looks like this:

• Policy defines the methods in which the capabilities and constraints of security policies can be expressed.
• WS-Trust is a model for establishing both direct and brokered trust relationships.
• WS-Privacy is a specification that addresses how privacy practices can be stated and implemented by Web Services.
• WS-Secure Conversation describes how message exchanges can be securely managed. It also deals with security context exchange and establishing and deriving session keys.
• WS-Federation relates to managing and brokering trust relationships in a heterogeneous distributed environment. It also includes support for distributed computing.
• WS-Authorization, is a standard for authorization data and policy management for Web Services.

How to adopt a world-class services security model

OpenWare Technologies has developed a framework to enable the design and building of a truly secure enterprise and trading partner/order fulfillment extraprise. We give you choices that vary from licensed products developed by openservice.com to an open source solution called WSS4J.

OpenService’s product, Security Management Center (SMC), sets a new benchmark in integrated security risk management by delivering a framework to enable superior threat management, log management, security policy compliance, and regulatory compliance – all via a uniform, real-time security dashboard with minimal maintenance.

WSS4J is an implementation of the OASIS Web Services Security (WS-Security) from OASIS Web Services Security TC. WSS4J is a primarily a Java library that can be used to sign and verify SOAP Messages with WS-Security information. WSS4J uses Apache Axis and Apache XML-Security projects and is interoperable with JAX-RPC based server/clients and .NET server/clients.