| Oracle® Retail Service Backbone Security Guide 14.0 E49442-01 |
|
 Previous |
 Next |
Security is about risk management and implementing effective countermeasures. One of the most important concepts in security is that effective security is a combination of people, process, and technology.
This chapter discusses a list of Web service security terms that are part of a coherent framework defined in the Web services architecture. The relationships between the terms are defined in the concepts and relationships section of the definitions in this document.
It is for developers who wish to expose their own services in an environment that requires protection of messages from being tampered or read in transit, or in situations in which the sender must be positively identified. The term WS-Security is usually used to refer to a group of specifications that handle encryption and digital signatures, enabling you to create a secure application.
This section covers the various aspects of Web services security.
The authentication process verifies that you are who you claim to be. Your identity is verified based on the credentials that you present, such as username/password, digital certificate, standard Security Assertion Markup Language (SAML) token, or Kerberos token. In the case of Web services, credentials are presented by a client application on your behalf.
Granting access to specific resources based on an authenticated user's entitlements or specific role (e.g., corporate buyer).
Confidentiality is keeping information secret. Personally Identifiable Information (PII) or confidential business data could be present in a Web service request or response messages. Confidentiality of such data can be achieved by encrypting the content of the request or response messages using the XML Encryption standard.
Integrity is making sure that a message remains unaltered during transit by having an authority digitally sign that message. A digital signature also validates the sender and provides a timestamp ensuring that a transaction can't be later repudiated by either the sender or the receiver. XML messages are signed using the XML signature standard.
Effective SOA security in practice includes the following measures:
Coordinating people, process, and technology.
Integrating and leveraging various levels of standards (general security standards, XML security standards, Web services security standards).
Integrating and leveraging various user stores and role stores.
Making trade-offs between user experience, technical, and business perspectives.
This section covers the various aspects of Web services security standards.
There are numerous ways to build or implement a secured service to protect the SOA infrastructure against attack. Standards allow policies to be applied to SOA, thus ensuring controlled usage and monitoring and provide security ramifications in enterprise integration. Standards such as WS-Security, SAML, WS-Trust, WS-Secure Conversation, and WS-SecurityPolicy focus on the security and identity management aspects of SOA implementations that use Web services.
The WS-* architecture is a set of standards-based protocols designed to secure Web service communication. For more information on these WS-* security standards, refer to the following sections.
WS-Policy allows Web services to define policy requirements for endpoints. These requirements include privacy rules, encryption rules, and security tokens.
WS-Security allows Web services to apply security to Simple Object Access Protocol (SOAP) messages through encryption and checks integrity on all or part of the message.
WS-Trust allows Web services to use security tokens to establish trust in a broken security environment.
WS-SecureConversation builds on top of WS-Policy, WS-Security, and WS-Trust to enable secure communications between a client and a service.
Oracle WSM is a standards-based solution that allows you to externalize Web services security and management from the applications. Oracle WSM provides declarative security and management through pre-defined policies.
Oracle WSM is based on three main operations: Define, Enforce, and Monitor.
Define consists of attaching security and management policies to the Web services to be protected. Examples of policies are Authenticate Request messages using username/password, Decrypt Messages using WS-Security, and Sign Response messages.
To secure a WebLogic Web service, configure one or more of three different types of security.
Table 1-1 Web Services Security
| Security Type | Description |
|---|---|
|
Transport-level security |
SSL is used to secure the connection between a client application and the Web service. |
|
Message-level security |
Data in a SOAP message is digitally signed or encrypted. It may also include identity tokens for authentication. |
|
Access control security |
Specifies which roles are allowed to access Web services. |
This section discusses the security options available in WebLogic.
Transport-level security secures the connection between the client application and the WebLogic server with Secure Sockets Layer (SSL). SSL provides secure connections by allowing two applications, connecting over a network, to authenticate the other's identity and by encrypting the data exchanged between the applications. Authentication allows a server, and optionally a client, to verify the identity of the application on the other end of a network connection. A client certificate (two-way SSL) can be used to authenticate you. Encryption makes data transmitted over the network intelligible only to the intended recipient. Transport-level security includes HTTP BASIC authentication as well as SSL.
Message-level security includes all the security benefits of SSL, but with additional flexibility and features. Message-level security is end-to-end, which means that a SOAP message is secure even when the transmission involves one or more intermediaries.
The SOAP message itself is digitally signed and encrypted, rather than just the connection. And finally, you can specify that only individual parts or elements of the message be signed, encrypted, or required.
Transport-level security, however, secures only the connection itself. This means that if there is an intermediary between the client and the WebLogic server, such as a router or message queue, the intermediary gets the SOAP message in plain text. When the intermediary sends the message to a second receiver, the second receiver does not know who the original sender was. Additionally, the encryption used by SSL is ”all or nothing”, that is either the entire SOAP message is encrypted or it is not encrypted at all. There is no way to specify that only selected parts of the SOAP message be encrypted. Message-level security can also include identity tokens for authentication.
Access control security answers the question ”who can do what?”. At first, you specify the security roles that are allowed to access a Web service. A security role is a privilege granted to users or groups based on specific conditions. Then, when a client application attempts to invoke a Web service operation, the client authenticates itself to the WebLogic server, and if the client has the authorization, it is allowed to continue with the invocation. Access control security secures only the WebLogic server resources. That is, if you configure only access control security, the connection between the client application and WebLogic server is not secure and the SOAP message is in plain text.
|
Note: In future releases of Oracle Service Bus (OSB), Oracle Web Services Manager policies will replace and enhance the functionality of WLS 9 security policies. While this version of Oracle Service Bus (11g Release 1 or 11.1.1.6.3) continues to support WLS 9 policies, you should consider using Oracle Web Services Manager policies for new service creation to prepare for the eventual deprecation of WLS 9 policy support.It is recommended that you use Oracle WSM policies whenever possible. You cannot mix your use of Oracle WSM and WebLogic Web service policies. You can attach only one type of security policy to a Web service, either WebLogic server security policies or Oracle WSM policies. You cannot attach both WebLogic server policies and Oracle WSM policies to the same Web service, through either the annotation mechanism, the Administration Console, Fusion Middleware Control, or a combination of the three. You can attach an Oracle WSM WS-Security policy only to a JAX-WS Web service. You cannot attach this type of policy to a JAX-RPC Web service. If you are establishing security requirements for a new business service that uses Web services security, Oracle recommends that you require clients to provide SAML tokens. SAML is the emerging standard for propagating user identities within Web services. |
Inbound security ensures that Oracle Service Bus proxy services handle only the requests that come from authorized clients. By default, any anonymous or authenticated user can connect to a proxy service. It can also ensure that no unauthorized user has viewed or modified the data sent from the client. Proxy services can have two types of clients: service consumers and other proxy services.
Outbound security secures communication between a proxy service and a business service. Most of the tasks that you complete for outbound security is for configuring proxy services to comply with the transport-level or message-level security requirements that business services specify. For example, if a business service requires username and password tokens, you create a service account, which either directly contains the username and password, passes along the username and password that was contained in the inbound request, or provides a username and password that depends on the username that was contained in the inbound request.
A key decision that must be made when designing security for Oracle Service Bus is how to handle (propagate) the identities that clients provide. You can configure Oracle Service Bus to do any of the following:
Authenticate the credentials that clients provide
Perform authorization checks
Pass client credentials to business services unchanged
Map client credentials to a different set of credentials that a business service can authenticate and authorize
Bridge between security technologies
Policies describe the capabilities and requirements of a Web service like whether and how a message must be secured, whether and how a message must be delivered reliably, and so on.
Consider the following scenarios:
If you develop WebLogic server JAX-WS Web services or clients that interact with SOA Composite Services, ADF Components, or WebCenter Services, then you should use the Oracle WSM WS-Security policies.
If you develop only WebLogic server native Java JAX-WS Web services, then you should use WebLogic server's WS-Security policies.
A subset of WebLogic Web service policies inter-operate with Oracle WSM policies. That is, for specific policy instances, you can attach an Oracle WSM policy to the Web service client or service, and an Oracle WebLogic server policy to the WebLogic Java EE Web service or client, and they will inter-operate.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
