This chapter provides answers to frequently asked questions about Service Bus security.
This chapter includes the following sections:
Service Bus leverages the WebLogic Security Framework.
The details of this framework are described in "WebLogic Security Framework" in WebLogic Security Service Architecture in Understanding Security for Oracle WebLogic Server. Before configuring security in Service Bus, you must configure an WebLogic Server security realm and other server configurations (such as SSL) in WebLogic Server, as described in Configuring the Oracle WebLogic Security Framework: Main Steps..
Transport-level security refers to the transport protocols that secure the connection over which messages are transported.
An example of transport-level security is HTTPS (HTTP over SSL). SSL provides point-to-point security, but does not protect the message when intermediaries exist in the message path. For more information, see Configuring Transport-Level Security.
Web Services Security (WS-Security) is an OASIS standard that defines interoperable mechanisms to incorporate message-level security into SOAP messages. WS-Security supports message integrity and message confidentiality.
It also defines an extensible model for including security tokens in a SOAP envelope and a model for referencing security tokens from within a SOAP envelope. WS-Security token profiles specify how specific token types are used within the core WS-Security specification. Message integrity is achieved through the use of XML digital signatures; message confidentiality is accomplished through the use of XML encryption. WS-Security allows you to specify which parts of a SOAP message are digitally signed or encrypted. Service Bus supports WS-Security over HTTP (including HTTPS) and JMS.
Oracle Web Services Manager (OWSM) is the Web Services security mechanism used by Oracle Service Bus. All newly created resources, such as business services and proxy services, use OWSM policies for security. WLS 9 policies are deprecated, and cannot be used to configure security for a new Service Bus resource.
However, you can import resources already configured with WLS 9 policies into your Service Bus project. You cannot edit or modify these WLS 9 policies, but you can replace them with OWSM policies.
The Web Services Policy Framework (WS-Policy) provides a general-purpose model and corresponding syntax to describe and communicate the policies of a web service.
WS-Policy defines a base set of constructs that can be used and extended by other web service specifications to describe a broad range of service requirements, preferences, and capabilities. See the note in What is Web Services Security? for important information about WLS9 web service policies. For more information, see Securing Oracle Service Bus Proxy and Business Services with WS-Policy.
The Web Services Policy Assertions Language (WS-PolicyAssertions) specifies a set of common message policy assertions that can be specified within a security policy. The specification defines general messaging-related assertions for use with WS-Policy.
Separate specifications describe the syntax and semantics of domain-specific assertions for security assertions and reliable-messaging assertions. See the note in What is Web Services Security? for important information about WLS9 web service policies.
No, access control policy is a boolean expression that is evaluated to determine which requests to access a particular resource (such as a proxy service, web application, or EJB) are granted and which should be denied access.
Typically access control policies are based on the roles of the requestor. WS-Policy is metadata about a web service that complements the service definition (WSDL). WS-Policy can be used to express a requirement that all service clients must satisfy, such as, all requests must be digitally signed by the client.
In a WS-Security pass-through scenario, the client applies WS-Security to the request and/or response messages. The proxy service does not process the security header, instead, it passes the secured request message untouched to a business service.
Although Service Bus does not apply any WS-Security to the message, it can route the message based on values in the header. After the business service receives the message, it processes the security header and acts on the request. The business service must be configured with WS-Policy security statements. The secured response message is passed untouched back 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. This is sometimes called a passive intermediary.
In an active intermediary scenario, the client applies WS-Security to the request and/or response messages. The proxy service processes the security header and enforces the WS-Security policy.
For example, the client encrypts and signs the message and sends it to the proxy service, the proxy 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 signs and encrypts the message. The client decrypts the message and verifies the proxy's digital signature.
Outbound WS-Security refers to security between Service Bus proxy services and business services. It includes both the request and response between business applications and proxy services.
For more information, see About Message-Level Security.
SAML (Security Assertion Markup Language) is an OASIS standards-based extensible XML framework for exchanging authentication and authorization information.
This framework allows single sign-on capabilities in modern network environments.
By default, the subject identity within an outbound SAML token is the same as the inbound user name. The format of the subject identity can be customized by writing a custom SAML name mapper-provider.
For more information, see Configuring a SAML Credential Mapping Provider in Administering Security for Oracle WebLogic Server.
The Certificate Lookup and Validation (CLV) providers complete certificate paths and validate X509 certificate chains.
The two types of CLV providers are:
CertPath Builder—receives a certificate, a certificate chain, or certificate reference (the end certificate in a chain or the Subject DN of a certificate) from a web service or application code. The provider looks up and validates the certificates in the chain.
CertPath Validator—receives a certificate chain from the SSL protocol, a web service, or application code and performs extra validation, such as revocation checking.
At least one CertPath Builder and one CertPath Validator must be configured in a security realm. Multiple CertPath Validators can be configured in a security realm. If multiple providers are configured, a certificate or certificate chain must pass validation with all the CertPath Validators for the certificate or certificate chain to be valid. WebLogic Server provides the functionality of the CLV providers in the WebLogic CertPath provider and the Certificate Registry. For more information see "The Certificate Lookup and Validation Process" in WebLogic Security Service Architecture in Understanding Security for Oracle WebLogic Server.
Yes, Service Bus supports two methods for propagating identities.
By generating SAML assertions in conformance with the Web Services Security.
This is done by setting a SAML holder-of-key or sender-vouches WS-Policy on the business service routed to by the proxy.
If a business service requires user name and password tokens, you can configure the business service's service account to pass through the user credentials from the original client request. See Working with Service Accounts.
Strictly speaking, single sign-on (SSO) is not applicable to Service Bus messaging scenarios for several reasons.
First, Service Bus is stateless; there is no notion of a session or conversation among multiple parties. Second, Service Bus clients are typically other enterprise software applications, not users behind a web browser. Therefore, it is acceptable to require that these clients send credentials such as user name and password on every request, provided that the communication is secured by means such as SSL or WS-Security. However, SSO between the Oracle Service Bus Console and the Oracle WebLogic Server Administration Console is supported. For more information, see "Single Sign-On" in Security Fundamentals in Understanding Security for Oracle WebLogic Server.
Only WS-Security errors are monitored by the Service Bus monitoring framework. Transport-level security errors such as SSL handshake errors, transport-level authentication and transport-level access control are not monitored.
However, it is possible to configure an Auditor provider to audit transport-level authentication and authorization. For more information, see Monitoring and Managing Security Policies in Administer Oracle Service Bus.
Service Bus includes two managed beans (MBeans) that configure such runtime behavior as which types of credentials are available to abstract WS-Policy statements.
By default, only users in the Admin and Deployer security roles can modify these MBeans, however you can change these defaults.