This chapter provides answers to frequently asked questions about Oracle Service Bus security.
This chapter includes the following sections:
Section 46.1, "How are Oracle Service Bus and Oracle WebLogic Server Security related?"
Section 46.6, "Are Access Control Policy and Web Service Policy the same?"
Section 46.8, "What is a Web Services Security Active Intermediary?"
Section 46.12, "What is the Certificate Lookup And Validation Framework?"
Section 46.13, "Does Oracle Service Bus support identity propagation in a proxy service?"
Section 46.11, "Is it possible to customize the format of the subject identity in a SAML assertion?"
Section 46.15, "Is single sign-on supported in Oracle Service Bus?"
Oracle Service Bus leverages the WebLogic Security Framework. The details of this framework are described in "WebLogic Security Framework" in "WebLogic Security Service Architecture" in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server. Before configuring security in Oracle Service Bus, you must configure an Oracle WebLogic Server security realm and other server configurations (such as SSL) in Oracle WebLogic Server, as described in Section 45.7, "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 Chapter 49, "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 lets you specify which parts of a SOAP message are digitally signed or encrypted. Oracle Service Bus supports WS-Security over HTTP (including HTTPS) and JMS.
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. For more information, see Chapter 51, "Using WS-Policy in Oracle Service Bus Proxy and Business Services."
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.
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 Oracle 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 Oracle Service Bus proxy services and business services. It includes both the request and response between business applications and proxy services. For more information, see Section 52.1, "About Message-Level Security."
SAML (Security Assertion Markup Language) is an OASIS standards-based extensible XML framework for exchanging authentication and authorization information, allowing single sign-on capabilities in modern network environments.
By default, the subject identity within an outbound SAML token is the same as the inbound username. 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 Oracle Fusion Middleware Securing 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. Oracle 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 Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.
Yes, Oracle 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 Chapter 2, "Creating Service Account Resources."
If both transport authentication and message-level authentication exist, the message-level subject identity is propagated.
Strictly speaking single sign-on (SSO) is not applicable to Oracle Service Bus messaging scenarios for several reasons. First, Oracle Service Bus is stateless; there is no notion of a session or conversation among multiple parties. Second, Oracle 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 username 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 Administration Console and the Oracle WebLogic Server Administration Console is supported. For more information, see "Single Sign-On" in "Security Fundamentals" in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.
Only WS-Security errors are monitored by the Oracle Service Bus monitoring framework. Transport-level security errors such as SSL handshake errors, transport-level authentication and transport-level access control are not monitored. For more information, see "Monitoring Oracle Service Bus at Runtime" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus. However, it is possible to configure an Auditor provider to audit transport-level authentication and authorization.
Oracle 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. See "Create JMX Policies" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.