2 Retail Service Backbone Security

This chapter provides an overview of security in the Retail Service Backbone (RSB) and discusses how security applies to it.

The RSB is an enterprise infrastructure for service oriented communication. RSB provides an architectural approach which involves Oracle Retail applications being exposed as ”Service Providers”, and OSB core components called ”Decorator Services” wrap the edge-app-services to provide virtualized and operational visibility to Oracle Retail services infrastructure. Lastly, the decorator services expose proxy WSDL's that are called by ”Service Consumers” which could be Retail applications or third party applications capable of making a SOAP invocation.

The RSB key components can be loosely coupled across platform, technology, and physical topologies. In order to establish an end-to-end security in RSB system, one has to secure all the intermediary layers that are part of a communication channel through RSB. As discussed earlier, there are three main layers, Service Provider, Decorator and the Service Consumer. Each of these must participate in configuring security in order to achieve effective security while making Web service calls.

Security decisions are mostly Service Provider driven; Decorators and Consumers will need to adhere to the chosen security mechanism by the provider in an integrated system. RSB provides numerous tools to ease the security configuration and automate the process which otherwise is quite cumbersome.

Recommended Security Approach for RSB

As RSB embeds networks of interconnected Web services, it does present key challenges, particularly in terms of security and administration. Oracle Retail, at an enterprise level, will not try to dictate customers on the security policy they must use in their enterprise. Oracle Retail will have security recommendations for our applications.

RSB services security principles must be able to fit into the customer's predefined corporate security policies and guidelines. Oracle Retail applications test, certify, and document a few commonly used security policies that work out-of-the-box with minimal effort.

You are free to reconfigure to a higher or lower level of Web service security than that certified by Oracle Retail. In such situations, Oracle Retail does not provide setup/configuration documentation. You should follow the Fusion Middleware documentation and set up the system on your own. The security configuration is supported (as long as Fusion Middleware supports it) but not certified by Oracle Retail.

Securing an RSB system involves following components. Each of these components is a layer in the RSB security architecture.

1. Edge App Services

2. Decorator Business Services

3. Decorator Proxy Services

Edge App Services

These services are deployed as part of ear files on the WebLogic server and it is not required to have Fusion Middleware components in that environment. In such environments, OWSM is not available to secure Web services. Therefore, these services are secured using the WebLogic Web service policies.

Decorator Services

The decorator proxy and business services are deployed in an OSB server where OWSM components can be used for Web service policies. Therefore, decorator proxy and business services use those OWSM policies which are compatible with the WebLogic policies applied to edge app services.

The policy files for business and proxy services depend on which policy has been attached to the corresponding edge app service. Business service needs to be configured with an OWSM client policy file which is corresponding to the policy file attached to the edge app service. The proxy services need to be configured with an OWSM service policy file that should have configuration matching with edge app policy file. The client of the proxy service needs to use a client policy file which matches the service policy for OSB proxy service.

Table 2-1 Decorator Services

Proxy Service Client	Proxy Service	Business Service	App Service
OWSM client policy	OWSM service policy	WebLogic compatible policy	WebLogic Web service policy

Active-Intermediary

The proxy service processes the header in the client's SOAP messages and enforces the message-level access control policy on the messages.

For example, a client encrypts and signs its SOAP message and sends it to a proxy service. The proxy service decrypts the message and verifies the digital signature, then routes the message. Before the proxy service sends the response back to the client, the proxy service signs and encrypts the message. The client then decrypts the message and verifies the proxy service's digital signature.

Pass-Through

Instead of processing the header in the client's SOAP messages, the proxy service passes the message untouched to a business service. Although the proxy service does not process the secured sections of the SOAP message, it can route the message based on values in the header. When the business service receives the message, it processes the security header and acts on the request. Note that the business service must use the Web Services Policy (WS-Policy) framework to describe which of its operations are secured with message-level security. The business service sends its response to the proxy service, and the proxy service passes the response untouched to the client.

For example, the client encrypts and signs the message and sends it to the proxy service. The proxy service does not decrypt the message or verify the digital signature; it simply routes the message to the business service. The business service decrypts the messages and verifies the digital signature, and then processes the request. The response path is similar.

Oracle Retail Enterprise Level Out-of-the-Box Certified Policies

There are two types of security configurations certified for RSB by Oracle Retail. For ease of use these are classified and referred in this document as Policy A and Policy B.

Each of these certified approaches involve a set of security policies. The following table describes the required set of policies for Policy A and B.

Service providers are the endpoint services which are invoked by the decorator proxy and business services; therefore edge app services must be secured first and based on the message-level and transport-level authentication required by them, the proxy and business services are secured with similar configurations.

Policy A (Default Policy)

Policy A is a Username Token over HTTPS. This security configuration is referred to as Policy A in this document.

• Wssp1.2-2007-Https-UsernameToken-Plain.xml

  
  

Policy A is selected as the default policy for the following reasons:

• Most widely (SSL) used policy

• Easy to configure and setup

• Data going over the wire is encrypted and is secure

• Interoperable between WebLogic and OWSM policy

• Good performance for the level of security provided

• Good support from all programming languages

Policy B

Policy B is a Message Protection plus username token. This security configuration is referred to as Policy B in this document.

• Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128

• Wssp1.2-2007-EncryptBody

• Wssp1.2-2007-SignBody

  
  

  It is highly recommended that the personnel who implement security carefully consider their options and take a strategic decision that benefits their business.

  The following facts are true for the encrypted username/password/payload Policy B:

  • Payload is encrypted/decrypted in the SOAP infrastructure layer and not in the TCP/IP layer.

  • The policy is complicated to set up in the WebLogic server and OWSM.

  • Since encryption and decryption is happening higher up in the stack, the performance is slower.

  • Limited support from other programming languages.