3 Service Integration

This chapter discusses Oracle Service Bus service integration and adaptive messaging concepts and its capabilities which support high-speed reliable service mediation and provisioning. It is intended for IT deployment specialists who are responsible for configuring services in an SOA.

This chapter includes the following topics:

3.1 Adaptive Messaging

Oracle Service Bus provides capabilities to extend and integrate applications into enterprise-class services (web and legacy). It also provides facilities for mediating and exposing services for reuse, through intelligent brokering functionality.

Figure 3-1 Adaptive Messaging in Oracle Service Bus

Description of Figure 3-1 follows
Description of "Figure 3-1 Adaptive Messaging in Oracle Service Bus"

Using Oracle Service Bus, service providers and clients exchange messages with an intermediary proxy service instead of directly with each other, eliminating complexities resulting from heterogeneous communication protocols and messaging formats. It leverages the following operational capabilities to provide high-speed and reliable service mediation:

  • Support for multiple Web Service transports - HTTP/SOAP, WS-I, WS-Security, WS-Policy, WS-Addressing, SOAP v1.2 and v1.1

  • Support for traditional messaging transports - JMS, MQ, EJB/RMI, Tuxedo, FTP, SMTP, File, EJB/RMI on WebSphere

  • Support for Java messaging

  • Facility for database lookup

  • Support for native transport for Oracle Data Service Integrator.

  • Support for enterprise-specific custom transports creation, using the Oracle Service Bus Transport SDK

  • Facility to create and configure generic proxy-services that can accept any SOAP or XML message, using generic proxy service templates

  • Interoperability with Web service integration technologies including .NET, Tibco EMS, IBM MQ, IBM WebSphere, Apache Axis, Cyclone B2B Interchange, and iWay 5.5 adapters

Its industry-leading support for Web services, traditional messaging protocols, and compatibility with legacy and proprietary integration technologies, make Oracle Service Bus an ideal service integration and adaptive messaging solution. For more details on The following topics describe concepts related to service integration and adaptive messaging using Oracle Service Bus.

3.1.1 Services

In Oracle Service Bus, service integration relationships are implemented dynamically by configuring policies and proxy services. Both, proxy services and business services invoked by proxy services, are modeled as services that have the following attributes:

  • A set of concrete interfaces called ports (also called an endpoint), each with a transport address and associated configuration. A set of ports constitutes load balancing and failover alternatives for a business service. A proxy service has only a single port.

  • A single optional abstract interface which is the definition of the structure of message parts in the interface, optionally broken down by operations. Operations are equivalent to methods of a Java interface.

  • A single binding that defines the packaging of message parts in the abstract interface to a concrete message.

  • Policies on Web Service Security (WS-Security).

3.1.2 Service Types

Oracle Service Bus supports varied service types ranging from conventional Web services (using XML or SOAP bindings in WSDLs) to non-XML (generic) services. The service type is selected by the individual doing the service registration when the business and proxy services are created, and it defines the protocols that can be used to communicate with the service end point. Oracle Service Bus service types include:

  • SOAP services: SOAP messages are constructed by wrapping the contents of the header and body variables inside a <soap:Envelope> element. If the body variable contains a piece of reference XML, it is sent as is. In other words, the referenced content is not substituted into the message. If attachments are defined in the attachments variable, a MIME package is created from the main message and the attachment data. Content handling for each attachment part is similar to how it is handled for messaging services.

  • XML services (non-SOAP): Messages to XML-based services are XML, but can be of any type the proxy service configuration allows. In messages that include attachments, their content is a MIME package that includes the primary XML payload as one of its parts—typically the first part or the one identified by the top-level content-type header.

  • Messaging services: Messaging services are those that can receive messages of one data type and respond with messages of a different data type. Supported data types include XML, Message Format Language (MFL), text, untyped, binary and attachments where interface is not described by WSDL.

Oracle Service Bus supports request and response as well as one-way paradigms, for both the HTTP and the JMS asynchronous transport protocols. If the underlying transport supports ordered delivery of messages, Oracle Service Bus also extends the same support.

3.1.3 Transport Protocols

Oracle Service Bus supports the following service transport protocols:

  • EJB/RMI

  • Email (POP/SMTP/IMAP)

  • File

  • (S)FTP

  • HTTP(S)

  • JCA

  • JEJB

  • JMS (including MQ using JMS, and JMS/XA)

  • Local (Oracle Proprietary for inter-ESB communication)

  • MQ (WebSphere MQ)

  • SB (RMI support)

  • SOA-DIRECT (Oracle SOA Suite)

  • Tuxedo (Oracle Tuxedo)

  • WS (WSRM, Web Services Reliable Messaging

The service type selected defines the protocol to be used for communicating with the service end point. The following table shows the service types and supported transports:

Service Type Transport Protocols

SOAP WSDL or XMLnic

HTTP(S), JCA, JMS, Local, SB, SOA-DIRECT, WS

JMS request and JMS response are not supported if WS-Security is enabled.

SOAP (no WSDL)

HTTP(S), JMS, Local, SB

JMS request and JMS response are not supported if WS-Security is enabled.

Transport Typed

EJB, Flow (Split-Join), JEJB

XML (no WSDL)

Email, File, FTP, HTTP(S), JMS, Local, MQ, SB, SFTP, Tuxedo

HTTP GET is only supported for XML with no WSDL.

Messaging Type (Binary, Text, MFL, XML)

Email, File, FTP, HTTP(S), JMS, Local, MQ, SFTP, Tuxedo

Oracle Service Bus also provides a Transport SDK to enable addition of native custom connectivity options.

For information on how to configure transport for a proxy service using the Oracle Service Bus Administration Console, see "Proxy Services: Creating and Managing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

For information on how to configure transport for a business service using the Oracle Service Bus Administration Console, see "Business Services: Creating and Managing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.1.4 Service Interfaces

Oracle Service Bus relies on WSDLs for the formal description of Web services. For Web services, a WSDL describes what the Web Service's interface is, where it resides, and how to invoke it. Oracle Service Bus defines proxy services and business services in terms of two WSDL entities:

  • The abstract WSDL interface, which defines the operations in that interface and the types of message parts in the operation signature

  • The binding WSDL interface, which defines the binding of the message parts to the message (packaging), and the binding of the message to the transport

WSDLs can be imported into the WSDL repository using the Oracle Service Bus Administration Console. The Oracle Service Bus Administration Console can also be used to resolve the references in the WSDLs, to ensure all schemas and WSDLs are linked correctly. After WSDLs are stored in the repository, they are available for use when adding proxy services and business services. Oracle Service Bus uses its own representation of the interface for messaging services.

For information on how to import and resolve WSDLs using the Oracle Service Bus Administration Console, see "Adding WSDLs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.1.5 Messaging Models

Oracle Service Bus accommodates multiple messaging paradigms and supports the following types of communication:

  • Synchronous request/response

  • Asynchronous publish one-one

  • Asynchronous publish one-many

  • Asynchronous request/response (synchronous-to-asynchronous bridging).

In sync-async bridging, a synchronous client issues a request to an asynchronous provider. For this pattern, Oracle Service Bus provides the capability to publish a message on one JMS queue and configure a second JMS queue for the response, with a timeout value for listening for the response. This type of service appears as a synchronous service to the service consumer. Using asynchronous request/response messages has these advantages:

  • No blocking by the request thread, removing thread management issues that can occur when numerous blocking request/response invocations are made.

  • More reliable messaging

3.1.6 Message Formats

Oracle Service Bus supports the following message formats:

  • Email with or without attachments

  • JMS with headers

  • MFL (Message Format Language)

  • Raw Data. (Raw data is opaque non-XML data with no known schema (no MFL file)

  • Text

  • SOAP and SOAP with attachments (SOAP described or not described by a WSDL)

  • XML and XML with attachments (XML described or not described by a WSDL or a schema)

3.1.7 Message Context

All messages sent to and received by the proxy service are defined internally in the proxy service by a set of properties that holds the message data and meta-data related to that message. This set of properties is known as the Message Context (context) and is implemented using Context Variables. It is defined by an XML schema. Each Context Variable relates to a different property. Some Context Variables are predefined and others are user defined. The heart of the proxy service is the Message context. For a complete description of the Message Context and context variables used in the message flow, see "Message Context" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

Predefined context variables contain information about the message, transport headers, security principals, metadata for the current proxy service, and metadata for the primary routing and publish services invoked by the proxy service. You typically use an XQuery expression to manipulate context variables in a message flow. You can also modify context variables using transformation and in-place update actions.

The message-related context variables $header, $body, and $attachments represent the canonical format of the message in the message flow. These are wrapper variables that contain the SOAP header elements, the SOAP body element, and the MIME attachments, respectively. The context gives the impression that all messages are SOAP messages, and non-SOAP messages are mapped to this paradigm. The following table lists the mappings for each message type.

Table 3-1 Message mappings

Message Type What Happens

XML

The Body element in $body contains the XML document. Attachments are in $attachments.

binary

The Body element in $body contains a reference XML document.

Attachments are in $attachments.

MFL

The document is transparently converted from and to XML, and appears as an XML document in the Body element in $body.

Attachments are in $attachments.

text

The Body element in $body contains the text.

Attachments are in $attachments.

File, FTP, and Email

In the case of pass-by-reference documents, a reference XML document in the Body element in $body refers to the URI of the document stored in the file system by the transport.

Attachments are in $attachments.

SOAP

The Body element in $body contains the SOAP body. The Header element in $header contains the SOAP header.

Attachments are in $attachments.

In the case of attachments, $attachments contains the following for each attachment:

  • attachment, if the attachment is XML

  • a reference XML, if the attachment is binary

  • text, if the attachment is text

3.1.8 Content Types

To support interoperability with heterogeneous end points, Oracle Service Bus lets service configurations control the content type, JMS type, and encoding used. It does not make assumptions about what the external client or service needs, but instead uses the service-definition information that has been configured for this purpose. Oracle Service Bus derives the content type for outbound messages from the service type and interface and uses the following specifications:

  • XML or SOAP (with or without a WSDL), the content type is text/XML

  • Messaging and the interface is MFL or binary, the content type is binary/octet-stream

  • Messaging and the interface is text, the content type is text/plain

  • Messaging and the interface is XML, the content type is text/XML.

The content type can be overridden in the outbound context variable ($outbound) for proxy services invoking a service, and in the inbound context variable ($inbound) for a proxy service response. Additionally, there is a JMS type (byte or text) which can be configured when the service is defined in the Administration Console. Encoding is also explicitly configured in the service definition for all outbound messages.

3.2 Oracle Service Bus Resources

Oracle Service Bus resources are reusable definitions or descriptions of entities that typically include metadata for those entities. Resources can be used by multiple services and provide standardized definitions or descriptions for use across an enterprise or department.

Resources and services in Oracle Service Bus are grouped into a set of projects, each with a hierarchy of folders. Organizing resources and services into projects eliminates name conflicts and provides a convenient way to organize resources and services by business categories and search for them.

This section discusses the following includes the following Oracle Service Bus resources:

3.2.1 Schemas and Data Types

Schemas describe types for primitive or structured data. XML Schemas are an XML vocabulary that describe the rules that XML business data must follow. XML Schemas specify the structure of documents, and the data type of each element and attribute contained in the document. XML schemas can import or include other XML schemas. For information on how to create schemas using the Oracle Service Bus Administration Console, see "Adding XML Schemas" in XML Schemas in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

Oracle Service Bus uses a metadata language called Message Format Language (MFL) to describe the structure of typed non-XML data. The Oracle Format Builder tool creates and maintains metadata as a data file called an MFL document. For information on how to create MFL documents, see the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

3.2.1.1 Type System

Oracle Service Bus has a built-in type system that is available for use at design time. When creating an XQuery expression in a condition, in-place update action, or transformation, the variable can be declared to be of a given type in an editor to assist in easily creating the XQuery. The types can be the following:

  • XML schema types or elements

  • WSDL types or elements

  • MFL types

3.2.2 Transformation Maps

Transformation maps describe the mapping between two disparate data types of different source and destination services. Oracle Service Bus supports data mapping using either XQuery or the eXtensible Stylesheet Language Transformation (XSLT) standard. In addition, MFL described data is automatically converted to the equivalent XML for transformation with XQuery or XSLT. The resulting XML is automatically converted to MFL if the target service requires it.

3.2.3 JARs

A JAR (Java ARchive) is a zipped file that contains a set of Java classes. It is used to store compiled Java classes and associated metadata that can constitute a program. A JAR acts like a callable program library for Java code elements (so that a single compilation link provides access to multiple elements, rather than requiring bindings for each element individually).

JAR files can be registered as reusable Oracle Service Bus resources. They are used in Java callout actions that provide a Java exit mechanism, EJB-based business services, and Tuxedo-based business services. For more information on JAR resources, see "JARs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.2.4 WSDLs

A WSDL (Web Service Definition Language) interface defines a service interface for a SOAP or XML service. It describes the abstract interface of a service including the operations in that interface and the types of message parts in the operation signature. It can also describe the binding of the message parts to the message (packaging), and the binding of the message to the transport. In addition a WSDL can describe the concrete interface of the service (for example, the transport URL).

For information on how to configure WSDLs using the Oracle Service Bus Administration Console, see "Adding WSDLs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.2.5 Proxy Services

Proxy services are Oracle Service Bus definitions of intermediary Web services that are hosted locally on Oracle Service Bus used to route messages to multiple business services. They are generic services that can be configured with an interface that is independent of the business services. Using generic proxy templates, the proxy service can be defined in terms of an interface, message flow definitions, and policies, that dynamically route messages to appropriate business services, based on content-based routing logic. For more information on proxy templates, see Chapter 5, "Service Composition", topic Section 5.1.1.2, "Business Services."

A proxy service can also map message data into appropriate protocol formats required by the end-point business service, allowing for dynamic runtime protocol switching. If the proxy service requires credential-level validation, a service key provider can be created to manage security credentials, using the Oracle Service Bus Administration Console.

For information on how to configure a proxy service using the Oracle Service Bus Administration Console, see "Proxy Services: Creating and Managing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.2.6 Service Key Providers

Service Key Provider resources contain Public Key Infrastructure (PKI) credentials that proxy services use for decrypting inbound SOAP messages and for outbound authentication and digital signatures. PKI credentials are private keys paired with certificates that can be used for digital signatures and encryption (for Web Service Security) and for outbound SSL authentication. The certificate contains the public key that corresponds to the private key. For information on how to configure a service key provider using the Oracle Service Bus Administration Console, see "Adding Service Key Providers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.2.7 Alert Destinations

Alert Destination resources capture a list of recipients that can receive alert notifications from the Oracle Service Bus. They are used by Alert actions configured in the message flow, and by SLA alert rules. An Alert destination could include one or more of the following types of destinations: Reporting Data stream, SNMP trap, email, JMS queue, or JMS topic. In the case of email and JMS destinations, a destination resource could include a list of email addresses or JMS URIs, respectively. Alert Destinations can be reused across alert configurations for services.

For more information on Alert Destination resources, see "Alert Destinations" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.2.8 JNDI Providers

JNDI Providers in Oracle Service Bus are globally available resources that provide the connection and authentication details needed to access JNDI-named objects. For example, in a business service used to invoke an EJB, you include the name of a JNDI Provider resource in the endpoint URI. When the business service is invoked, Oracle Service Bus uses the details in the referenced JNDI Provider resource to make the initial connection to the JNDI provider.

JNDI Providers offer a great deal of flexibility. If a JNDI connection changes, you need only modify the JNDI Provider resource, and anything that references the JNDI Provider automatically uses the updated configuration.

For more information on JNDI Providers, see "Adding JNDI Providers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.2.9 SMTP Servers

SMTP Server resources specify the address of SMTP servers corresponding to email destinations, port numbers, and, if required, authentication credentials. They are global resources that are used in Alert Destination resources across projects in an Oracle Service Bus domain.

For more information on SMTP Server resources, see "Adding SMTP Servers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.2.10 JCA Bindings

JCA Binding resources in Oracle Service Bus let you create business and proxy services that interact with external services through Oracle SOA Suite JCA adapters. A JCA Binding is made up of a service WSDL and a corresponding .jca file created in Oracle JDeveloper.

For more information, see "JCA Bindings" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.3 Oracle Service Bus Security

Oracle Service Bus uses the proven Oracle WebLogic Security Framework in Oracle WebLogic Server as the building blocks for higher-level security services including authentication, identity assertion, authorization, role mapping, auditing, and credential mapping. Oracle WebLogic Server security is configured before the Console can be used to configure security.

The Console has predefined rules that simplify using the Oracle WebLogic Server security providers at several different levels in its operation. For more information on supported security levels, see section Section 3.3.4, "Security Levels.".

For more information on Oracle Service Bus security functionality, see topic "Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

3.3.1 Oracle Web Services Manager

You can secure your services by using Oracle Web Services Manager policies with your Oracle Service Bus services. Oracle Web Services Manager is a component of the Oracle Enterprise Manager Fusion Middleware Control, a runtime framework that provides centralized management and governance of Oracle SOA Suite environments and applications.

For more information, see "Security Oracle Service Bus with Oracle Web Services Manager" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

3.3.2 WS-Policies

Web Services Policy (WS-Policy) is a standards-based framework for defining a Web service's security constraints and requirements. It expresses security constraints and requirements in a collection of XML statements called policies, each of which contains one or more assertions. In Oracle Service Bus, WS-Policy assertions are used to specify a Web service's requirements for digital signatures and encryption, along with the security algorithms and authentication mechanisms that it requires.

WS-Policy policies may be included directly in a WSDL document or included by reference, and a WSDL document may import other WSDL documents that contain or refer to WS-Policy policies. An XML file that contains these policies can be used by multiple proxy services or business services. The WebLogic Web Services runtime environment recognizes two types of WS-Policy statements:

  • Concrete WS-Policy statements: specify the security tokens that are used for authentication, encryption, and digital signatures. These WS-Policy statements are created if the type of authentication required (such as using X.509 or SAML tokens), multiple private key and certificate pairs from the keystore used for encryption and digital signatures, are known at runtime.

  • Abstract WS-Policy statements: that do not specify security tokens.

The Oracle Service Bus runtime environment determines which security token types an abstract policy will accept. For information on configuring the runtime environment, see "Using WS-Policy in Oracle Service Bus Proxy and Business Services" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

Policies are referenced by an URI, either embedded within a WSDL, an HTTP URI, or a policy URI (for example. policy:myPolicy). Policy URIs can reference in-built policies. For more information on WS-Policy, see the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

3.3.3 Service Accounts

Service Account resources provide a user name and password that proxy services and business services use for outbound authentication or authentication to a local or remote resource, such as an FTP server or a JMS server. For example, if a business service is required to supply a user name and password for transport-level authentication with a Web Service, a service account can be created to specify the user name and password. The business service can then be configured to include the service-account credentials in its outbound requests. One service account can be used for multiple business services and proxy services. For more information on Service Account resources, see "Service Accounts" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.3.4 Security Levels

Oracle Service Bus provides the following types of security features:

  • Authentication

  • Identity assertion

  • Authorization

  • Auditing

  • Credential mapping

The following topics discuss the security features available in the Oracle Service Bus security model.

3.3.4.1 Inbound Security

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 as it was sent from the client.

Proxy services can have two types of clients: service consumers and other proxy services. Inbound security is set up when proxy services are created and is determined by varying security requirements.For outward-facing proxy services which receive requests from service consumers, strict security requirements such as two-way SSL over HTTPS are used. For proxy services that are guaranteed to receive requests only from other Oracle Service Bus proxy services, less secure protocols are used. If a proxy service uses public key infrastructure (PKI) technology for digital signatures, encryption, or SSL authentication, create a service key provider to provide private keys paired with certificates.

For each proxy service, the following inbound security checks can be configured:

  • Transport-level security: applies security checks as part of establishing a connection between a client and a proxy service. The security requirements that you can impose through transport-level security depend on the protocol that you configure the proxy service to use. For information about configuring transport-level security for each supported protocol, see Configuring Transport-Level Security. For more information, see Section 3.3.4.6, "Transport-Level Security."

  • Custom Authentication: for message-level security and client-specified custom authentication credentials for inbound transport- and message-level requests. The custom authentication credentials can be in the form of a custom token, or a username and password. For more information, see Section 3.3.5, "Custom Security Credentials."

  • Message-level security: for proxy services that are Web Services. This is part of the WS-Security specification. It applies security checks before processing a SOAP message or specific parts of a SOAP message. For more information, see Section 3.3.4.7, "Message-Level Security."

3.3.4.2 Outbound Security

Outbound security secures communication between a proxy service and a business service. Most of the tasks involve configuring proxy services to comply with the transport-level or message-level security requirements that business services specify. If a business service requires the use of PKI technology for digital signatures, or SSL authentication, a service key provider is created, which provides private keys paired with certificates. For more information, see "Service Key Providers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.3.4.3 Options for Identity Propagation

Options for Identity Propagation allows for decision making when designing security for Oracle Service Bus, including how to propagate the identities that clients provide. Oracle Service Bus can be configured 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

For detailed descriptions of these Oracle WebLogic Server security providers and Oracle WebLogic Server security architecture in general, see Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server

Oracle Service Bus security supports the WS-Policy specification. For more information on WS-Policy specification, see the Web Services Policy Framework (WS-Policy) and Web Services Policy Attachment (WS-PolicyAttachment) which is available at http://specs.xmlsoap.org/ws/2004/09/policy/.

Using the Oracle Service Bus Administration Console, it is possible to configure a service with security policies that apply to messages in its interface. A security policy can be specified for a service or for individual messages associated with the operations of a service. When a security policy is specified for a service, the policy applies to all messages sent to that service.

Oracle Service Bus enables you to use the Oracle WebLogic Server security providers at several different levels in its operation. The following levels of security are supported:

For more information on security levels, see the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

3.3.4.4 User Management

Oracle Service Bus user management is built on the unified Oracle WebLogic Server security framework. This framework enables the Oracle Service Bus Administration Console to support task-level authorization based on security policies associated with roles assigned to named groups or individual users. For more information on the Oracle WebLogic Server security framework, see the Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.

The Oracle Service Bus Administration Console is used to manage Oracle Service Bus users, groups, and roles. For information on how to manage Oracle Service Bus users, groups, and roles using the Oracle Service Bus Administration Console, see "Security Configuration" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.3.4.5 Administrative Security

To give users access to administrative functions such as creating proxy services, they can be assigned to one of four security roles with pre-defined access privileges. A security role is an identity that can be dynamically conferred upon a user or group based on conditions that are evaluated at runtime. The access privileges for the Oracle Service Bus administrative security roles cannot be changed but the conditions under which a user or group is in one of the roles can be changed.

By default, the first user created for an Oracle Service Bus domain is an Oracle WebLogic Server Administrator. This user has full access to all Oracle Service Bus objects and functions, and can execute user management tasks to provide controlled access to Oracle Service Bus Administration Console functionality.

The following is a list of default roles to which Oracle Service Bus users can be assigned:

  • IntegrationAdmin

  • IntegrationDeployer

  • IntegrationMonitor

  • IntegrationOperator

For information on configuring administrative security, see "Configuring Administrative Security: Main Steps" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

For information on how to manage Oracle Service Bus users, groups, and roles using the Oracle Service Bus Administration Console, see "Security Configuration" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

3.3.4.6 Transport-Level Security

Oracle Service Bus supports transport-level confidentiality, message integrity, and client authentication for one-way requests or request/response transactions (from clients to Oracle Service Bus) over HTTPS. It allows HTTP(S) proxy services or business services to be configured to require one of the following types of client authentication:

  • BASIC (username/password) client authentication

  • CLIENT CERT (two-way SSL) client authentication

  • No client authentication

When a proxy service is activated, Oracle Service Bus generates and deploys a thin Web application. Oracle Service Bus relies on Oracle WebLogic Server for server-side SSL support, including session management, client certificate validation and authentication, trust management and server SSL key/certificate manipulation.

Transport security for transports other than HTTP is supported in Oracle Service Bus as follows:

  • For the Email and FTP transports, security is provided using credentials to connect to a FTP or email server.

  • For the file transport, security is provided using a login control to the machine on which the files are located.

For more information, see the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

3.3.4.7 Message-Level Security

Oracle Service Bus supports OASIS Web Services Security (WSS) 1.0. For more information on the WSS specification, see the OASIS Web Services Security TC which is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.

WSS defines a framework for message confidentiality, integrity, and sender authentication for SOAP messages. Using WSS, Oracle Service Bus provides support for securing messages using digital signatures, encryption, or both. Though it is not a substitute for transport-level security, WSS is ideal for end-to-end message confidentiality and integrity.

It is more flexible than SSL since individual parts of the SOAP envelope can be signed, encrypted or both, while other parts are neither signed nor encrypted. This is a powerful feature when combined with the ability of Oracle Service Bus to make routing decisions and perform transformations on the data based on the message content. Oracle Service Bus currently supports WSS over HTTP/S and JMS.

3.3.5 Custom Security Credentials

There are several ways to authenticate a client's identity in Oracle Service Bus—using Basic Authentication, client certificates (2-way SSL), and Web Service Security. Client credentials associated with a business service and a proxy service are managed directly using Oracle WebLogic Server. Client-specified custom authentication credentials for both transport- and message-level inbound requests are also supported. The custom authentication credentials can be in the form of tokens, or a username and password token combination.

Oracle Service Bus accepts and attempts to authenticate:

  • A custom token passed to a proxy service in an HTTP header, SOAP header (for SOAP-based proxy services) or in the payload (for non-SOAP proxy services).

  • A username and password token passed in a SOAP header (for SOAP based proxy services), or in the payload for non-SOAP proxy services.

  • The custom authentication mechanisms work alone or in concert with the message-level security for Web services.

For more information on custom security credentials, see "Configuring Custom Authentication" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.

3.3.6 Related Topics