Security Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Understanding Oracle Service Bus Security

Oracle Service Bus supports open industry standards for ensuring the integrity and privacy of communications and to ensure that only authorized users can access resources in an Oracle Service Bus domain. It uses the underlying WebLogic security framework as building blocks for its security services.

The WebLogic security framework divides the work of securing a domain into several components (providers), such as authentication, authorization, credential mapping, and auditing. You configure only those providers that you need for a given Oracle Service Bus domain.

The following sections introduce the Oracle Service Bus security model and its features:

 


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. Figure 2-1 illustrates that communication between proxy services and their clients is secured by inbound security, while communication between proxy services and business services is secured by outbound security.

Figure 2-1 Inbound and Outbound Security

Inbound and Outbound Security

You set up inbound security when you create proxy services and you can modify it as your needs change. For outward-facing proxy services (which receive requests from service consumers), consider setting up strict security requirements such as two-way SSL over HTTPS. For proxy services that are guaranteed to receive requests only from other Oracle Service Bus proxy services, you can use less secure protocols.

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 more information, see Service Key Providers in Using the Oracle Service Bus Console.

For each proxy service, you can configure the following inbound security checks:

 


Outbound Security

Outbound security secures communication between a proxy service and a business service. Most of the tasks that you complete for outbound security are 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 user name and password tokens, you create a service account, which either directly contains the user name and password, passes along the user name and password that was contained in the inbound request, or provides a user name and password that depend on the user name that was contained in the inbound request. For more information, see Service Accounts in Using the Oracle Service Bus Console.

If a business service requires the use of PKI technology for digital signatures, or SSL authentication, you create a service key provider, which provides private keys paired with certificates. For more information, see Service Key Providers in Using the Oracle Service Bus Console.

 


Options for Identity Propagation

A key group of decisions that you must make 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:

Table 2-1 describes the decisions that affect how Oracle Service Bus propagates client identities to business services.

Table 2-1 Options for Identity Propagation
Decision
Description
Which type of credentials do you require clients to provide?
For transport-level security, Oracle Service Bus adapts to your existing security requirements. Clients of Oracle Service Bus can supply user name and password tokens, SSL certificates, or any other type of custom authentication token that is supported by an Identity Assertion provider that you configure.
For message-level security, Oracle Service Bus supports the Username Token, X.509 Token, any other type of custom authentication token that is supported by an Authentication or Identity Assertion provider that you configure, and SAML Token profiles (see Supported Standards and Security Providers).
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. See Using SAML for Authentication.
Do you require Oracle Service Bus to authenticate clients or to simply pass the client-supplied credentials to business services for authentication?
When you require clients to authenticate with Oracle Service Bus, you add an additional layer of security. In general, the more security layers you add, the more secure you make a domain.
To enable Oracle Service Bus to authenticate users, you must create user accounts in the Oracle Service Bus Console. If your set of users is very large, you must consider whether maintaining a large database of user accounts in the Oracle Service Bus Console is worth the effort.
If Oracle Service Bus authenticates clients that provide X.509 tokens or SAML tokens, which Oracle Service Bus user maps to the tokens?
Oracle recommends that you require clients to authenticate with Oracle Service Bus and that you modify the default access-control policies to allow (authorize) only specific, authenticated users access to your proxy services.
To authenticate and authorize clients who supply X.509 certificates, SAML tokens, or other types of credentials other than user names and passwords, you must configure an identity assertion provider that maps the client’s credential to an Oracle Service Bus user. Oracle Service Bus will use this user name to establish a security context for the client.
If Oracle Service Bus authenticates clients that provide custom authentication tokens, which Oracle Service Bus user maps to the tokens?
Oracle recommends that you require clients to authenticate with Oracle Service Bus and that you modify the default access-control policies to allow (authorize) only specific, authenticated users access to your proxy services.
To authenticate and authorize clients who supply custom authentication tokens other than user names and passwords, you must configure an Identity Assertion provider that maps the client’s credential to an Oracle Service Bus user. Oracle Service Bus will use this user name to establish a security context for the client.
If Oracle Service Bus authenticates clients that provide user name and password tokens, decide whether you want to:
  • Pass the client’s user name and password to the business service
  • Map the client’s user name to a new user name and password and pass the new credentials to the business service
If a custom username/password token is used, as described in What Are Custom Authentication Tokens?, then the username and password in the custom token can be used for outbound HTTP BASIC or outbound WS-Security Username Token authentication if a pass-through service account is used.
If you pass the client-supplied user name and password to the business service, then clients are responsible for maintaining the credentials that the business service requires. If the business service changes its security requirements, then you must notify each client to make corresponding changes.
If you expect a business service to change its requirements frequently, then consider mapping the credentials that clients supply to the credentials that the business service requires. The more clients for a business service, the more work will be required to maintain this credential mapping.

Table 2-2 describes all combinations of the requirements that you can impose for inbound and outbound transport-level security.

Table 2-2 Combinations of Transport-Level Security Requirements
This Inbound Requirement...
Can Be Used With This Outbound Requirement...
How to Configure
Client supplies user name and password in the HTTP header and Oracle Service Bus authenticates the client.
Pass the client’s credentials in an HTTP header.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Configure outbound HTTP security. See Configuring Outbound HTTP Security: Main Steps.
    Be sure to create a pass-through service account and attach the account to the business service.
Map the client’s credentials to a different Oracle Service Bus user and pass the new credentials in an HTTP header.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Configure outbound HTTP security. See Configuring Outbound HTTP Security: Main Steps.
    Be sure to create a user-mapping service account and attach the account to the business service.
Client supplies user name and password in the HTTP header and Oracle Service Bus does not authenticate the client.
Pass the client’s credentials in an HTTP header.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
    Be sure to configure the proxy service for HTTP, no authentication or HTTPS, one-way SSL, no authentication.
  2. Configure outbound HTTP security. See Configuring Outbound HTTP Security: Main Steps.
    Be sure to configure the business service for HTTP BASIC authentication or HTTPS, one-way SSL, BASIC authentication.
    Also create a pass-through service account and attach the account to the business service.
   
Client supplies custom authentication token in the HTTP header. Oracle Service Bus authenticates the client.
Map the client’s credentials to a different Oracle Service Bus user and pass the new credentials in an HTTP header.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Configure outbound HTTP security. See Configuring Outbound HTTP Security: Main Steps.
    Be sure to create a user-mapping service account and attach the account to the business service.
   
Any form of local authentication (HTTP or HTTPS BASIC, HTTPS CLIENT CERT with credential mapping)
Pass the client’s credentials to an EJB over RMI. The EJB container authenticates the user.
Create a pass-through service account and attach the account to the business service. See “ Service Accounts” in Using the Oracle Service Bus Console.
   

Table 2-3 describes all combinations of the requirements that you can impose for inbound and outbound message-level security. In some cases, the inbound requirement for transport-level security affects the requirements that you can impose for outbound message-level security.

Table 2-3 Combinations of Message-Level Security Requirements
This Inbound Requirement...
Can Be Used With This Outbound Requirement...
How to Configure
Client supplies user name and password, or custom authentication token, in the HTTP header and Oracle Service Bus authenticates the client.
Pass the client’s credentials in a SOAP header.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Create a pass-through service account and attach the account to the business service. See “ Service Accounts” in Using the Oracle Service Bus Console.
Map the client’s credentials to a different Oracle Service Bus user and pass the new credentials in a SOAP header.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Create a user-mapping service account and attach the account to the business service. See “ Service Accounts” in Using the Oracle Service Bus Console.
Map the client credentials to a SAML token. Oracle Service Bus asserts the user identity.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Configure a SAML credential mapping provider. See Configuring SAML Credential Mapping: Main Steps.
Client supplies custom user name and password, or custom authentication token, in the message header or body and Oracle Service Bus authenticates the client.
Pass the client’s credentials in a SOAP header.
  1. Configure an Authentication or Identity Assertion provider to handle the custom token or username and password.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Create a pass-through service account and attach the account to the business service. See “ Service Accounts” in Using the Oracle Service Bus Console.
Map the client’s credentials to a different Oracle Service Bus user and pass the new credentials in a SOAP header.
  1. Configure an Authentication or Identity Assertion provider to handle the custom token or username and password.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Create a user-mapping service account and attach the account to the business service. See “ Service Accounts” in Using the Oracle Service Bus Console.
Map the client credentials to a SAML token. Oracle Service Bus asserts the user identity.
  1. Configure an Authentication or Identity Assertion provider to handle the custom token or username and password.
    Be sure to add the client’s user name to the Oracle Service Bus Security Configuration module.
  2. Configure a SAML credential mapping provider. See Configuring SAML Credential Mapping: Main Steps.
Client supplies user name and password in the HTTP header and Oracle Service Bus does not authenticate the client.
Pass the client’s credentials in a SOAP header.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
    Be sure to configure the proxy service for HTTP, no authentication or HTTPS, one-way SSL, no authentication.
  2. Configure outbound HTTP security. See Configuring Outbound HTTP Security: Main Steps.
    Be sure to configure the business service for HTTP BASIC authentication or HTTPS, one-way SSL, BASIC authentication.
    Also create a pass-through service account and attach the account to the business service.
Client supplies a certificate as part of HTTPS CLIENT-CERT authentication (two-way SSL) and Oracle Service Bus authenticates the client.
Map the client credentials to a SAML token. Oracle Service Bus asserts the user identity.
  1. Configure inbound HTTP security. See Configuring Inbound HTTP Security: Main Steps.
  2. Configure a SAML credential mapping provider. See Configuring SAML Credential Mapping: Main Steps.
An active intermediary proxy service enforces Web-Services Security with the User Name Token Profile.
Encode the credentials as a user name and password token in the SOAP message.
Create an active intermediary proxy service with a WS-Policy statement that requires passwords (not password digests). See Creating an Active Intermediary Proxy Service: Main Steps.
Encode the credentials as a SAML token in the SOAP message.
  1. Create an active intermediary proxy service with a WS-Policy statement that requires passwords. See Creating an Active Intermediary Proxy Service: Main Steps.
  2. Configure a SAML credential mapping provider. See Configuring SAML Credential Mapping: Main Steps.
An active intermediary proxy service enforces Web-Services Security with the X.509 Token Profile.
Encode the credentials as a SAML token in the SOAP message.
  1. Create an active intermediary proxy service with a WS-Policy statement that requires digital signatures and optionally requires authentication with an X.509 token. See Creating an Active Intermediary Proxy Service: Main Steps.
  2. Configure a SAML credential mapping provider. See Configuring SAML Credential Mapping: Main Steps.
An active intermediary proxy service enforces Web-Services Security with the SAML Token Profile.
Generate a new SAML token in the outbound SOAP message.
  1. Create an active intermediary proxy service with a WS-Policy statement that requires a SAML token. See Authenticating SAML Tokens in Proxy Service Requests.
  2. Configure a SAML credential mapping provider. See Configuring SAML Credential Mapping: Main Steps.
A pass-through proxy service, which can pass user names and passwords, X.509 tokens, or SAML tokens.
A business service that uses either the User Name Token Profile, the X.509 Token Profile, or the SAML Token Profile.
  1. Create a pass through proxy service. See Creating an Active Intermediary Proxy Service: Main Steps.
  2. Create a business service that enforces one of the token profiles. See Configuring Business Service Message-Level Security: Main Steps or Configuring SAML Pass-Through Identity Propagation.

For inbound Tuxedo requests, you can configure any of the following security requirements:

For information about using Tuxedo with Oracle Service Bus, see Interoperability Solution for Tuxedo.

Example: Authentication with a User Name Token

Figure 2-2 illustrates how user identities flow through Oracle Service Bus when you configure Oracle Service Bus as follows:

The illustration begins with the inbound request and ends with the outbound request:

  1. A client sends a request to a proxy service. The request contains the user name and password credentials.
  2. Clients can send other types of tokens for authentication, such as an X.509 certificate or a custom authentication token. If a client sends an X.509 certificate token or a custom token, you must configure an identity assertion provider to map the identity in the token to an Oracle Service Bus security context.

  3. The proxy service asks the domain’s authentication provider if the user exists in the domain’s authentication provider store.
  4. If the user exists, the proxy service asks the domain’s authorization provider to evaluate the access control policy that you have configured for the proxy service.

  5. If the proxy service’s access control policy allows the user access, the proxy service processes the message. As part of generating its outbound request to a business service, the proxy service asks the business service to supply the user name and password that the business service requires.
  6. The business service asks its service account for the credentials. Depending on how the service account is configured, it does one of the following:

    • Requires the proxy service to encode a specific (static) user name and password.
    • Requires the proxy service to pass along the user name and password that the client supplied.
    • Maps the user name that was returned from the authentication provider to some other (remote) user name, then requires the proxy service to encode the remote user name.
  7. The proxy service sends its outbound request with the user name and password that was returned from the service account.
  8. Figure 2-2 How Service Accounts Are Used


    How Service Accounts Are Used

 


Administrative Security

To secure access to administrative functions, such as creating proxy services or business services, Oracle Service Bus provides four security roles with pre-defined access privileges:

A security role is an identity that can be dynamically conferred upon a user or group at runtime. You cannot change the access privileges for these administrative security roles, but you can change the conditions under which a user or group is in one of the roles.

The Oracle Service Bus roles have permission to modify only Oracle Service Bus resources; they do not have permission to modify WebLogic Server or other resources on WebLogic Server. When assigning administrative users to roles, assign at least one user to the WebLogic Server Admin role. The WebLogic Server security roles are described in Table 9-2.

For more information, see Configuring Administrative Security.

 


Access Control Policies

Access control determines who has access to the resources in Oracle Service Bus. An access control policy specifies conditions under which users, groups, or roles can access a proxy service. For example, you can create a policy that always allows users in the GoldCustomer role to access a proxy service and that allows users in the SilverCustomer role to access the proxy service only after 12pm on weeknights.

An access control policy is an association between a WebLogic resource and one or more users, groups, or security roles. A security policy protects the WebLogic resource against unauthorized access. Access control policies are boolean expressions assigned to specific resources. When there is an attempt to access the resource, the expression is evaluated. The expression consists of one or more conditions joined by boolean operators, such as a role (operator) and access time (8 am to 5 pm). For more information about access control policies, see Security Fundamentals in Understanding WebLogic Security.

Oracle Service Bus relies on WebLogic Server security realms to protect its resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and (access control) security policies. To access any resources belonging to a realm, a user must be assigned a security role defined in that realm, as described in Administrative Security Roles and Privileges. When a user attempts to access an Oracle Service Bus resource, WebLogic Server authenticates and authorizes the user by checking the security role assigned to the user in the relevant security realm and relevant security policy.

Note: Only a WebLogic Server administrator can define security policies or edit security roles in the Oracle Service Bus Console.

For all proxy services, you can create a transport-level policy, which applies a security check when a client attempts to establish a connection with the proxy service. Only requests from users who are listed in the transport-level policy are allowed to proceed.

For proxy services that are WS-Security active intermediaries, or that implement message-level custom authentication, you can also create a message-level policy. This type of policy applies a security check when a client attempts to invoke one of the secured operations. Only users who are listed in the message-level policy are allowed to invoke the operation.

The Oracle Service Bus Console contains a Security Configuration module for viewing and configuring users, groups, and security roles. Additionally, the Oracle Service Bus Console allows you to view and configure credentials.

Configuring Proxy Service Access Control

You can configure transport-level access control for all proxy services. You can also configure access control at the message-level for any WS-Security active intermediary proxy service, or for any proxy service that implements message-level custom authentication,. To configure access control, you must assign an access control policy to the proxy service, either at the transport-level or message-level (or both).

The default transport-level and message-level access control policy for all proxy services is to allow access to all requests. You must assign an access control policy to the proxy service to protect it.

You configure transport-level and message-level access control policies in the Oracle Service Bus Console, as described in Editing Transport-Level Access Policies and Editing Message-Level Access Policies respectively.

Access Control Policy Management

Access control policies are persisted in authorization providers. However, as of ALSB 3.0, there was a reference to them in the ALSB repository.

Access control policies are managed within an Oracle Service Bus design session and not outside the session, as was the case in releases prior to 3.0. Because the changes are made within a session, you can commit or discard the changes as with other resources.

Although ACLs can be managed from the Oracle Service Bus console, you can change policies outside Oracle Service Bus. However, changing policies outside of Oracle Service Bus can make the reference in Oracle Service Bus out-of-date and invalid.

Therefore, for consistent management, either completely manage ACLs outside of Oracle Service Bus sessions (using the authorization provider MBeans or third-party authorization provider tools) or completely manage them from within Oracle Service Bus sessions. Any combination of the two approaches can result in an inconsistent view of policies.

Oracle Service Bus manages access control policy only for proxy services. You must manage access control policy management for other server resources, such as JMS queues, JNDI entries, EJBs, applications, WebLogic Server instances, data sources, and so forth from the WebLogic Server console.

Note: When you clone a service, ACLs are also cloned in the session. If the user commits the session, ACLs on the service will be committed to the authorization provider. Therefore, when you clone a service you need to decide if you want the clone to have the same ACLs as the original. If you do not want this, then make sure to edit the ACLs of the clone.
Note: In releases prior to ALSB 3.0, when you cloned a service, access control policies were not cloned.

Deleting a Proxy Service

Deleting a proxy service deletes all of the ACLs referenced by the proxy from the repository controlled by Oracle Service Bus, as well as from the appropriate authorization provider.

Deleting the Access Control Policy Assigned to a Proxy Service

You can also delete the access control policies assigned to a service without deleting the service. To do this:

  1. Create a session.
  2. From the View a Proxy Service -> Security tab, use the edit Transport Access Control option to delete the policies.
  3. Commit the session.

Moving or Renaming a Proxy Service

Renaming a proxy service correctly moves all of the policies. You need only rename or move the service in an Oracle Service Bus session.

Renaming a Proxy Service Operation

When an operation is renamed, the existing operation is transparently deleted and a new operation is created.

However, when an operation name is changed by changing the WSDL, Oracle Service Bus considers any policies for the old operation to be invalid, removes the reference from the Oracle Service Bus repository, and deletes the policies from the appropriate authorization provider.

In this case Oracle Service Bus does not know that the old operation is renamed to the new operation, and it does not add anything new for the new operation. That is, Oracle Service Bus considers that there are no policies for this new operation.

You need to add the appropriate policy to the new operation manually. You can do this in the same session as the rename of operation, after the rename is done.

 


Preserving Security Configuration During Import

As of this release of Oracle Service Bus, you can export or import Oracle Service Bus resources without losing any associated security configuration data.

Oracle Service Bus includes import check boxes that you can use to determine whether to preserve or overwrite the existing security configuration.

For example, assume that you want to configure your credentials in a staging area, export a project that contains these credentials, and then import the project in your production environment. When you export the project, the security configuration is included in the Oracle Service Bus configuration jar. When you then import the project on your target system, how the resources are treated depends on whether they already exist on the target system:

The three import check boxes allow you to decide which, if any, aspects of the security configuration must be preserved during import:

Note: These check boxes work the same way for Oracle Service Bus configuration files created for a project-level export and for an individual resource export.

These check boxes are described in more detail in the sections that follow.

Preserve Security and Policy Configuration Check Box

When the Preserve Security and Policy Configuration check box is set (the default), the following configuration parameters are preserved:

Preserve Credentials Check Box

When the Preserve Credentials check box is set (the default), the following credentials are preserved during the import process:

Preserve Access Control Check Box

When the Preserve Access Control Policies check box is set (the default), all access control policies for the imported proxy services are preserved during the import process.

 


Configuring the WebLogic Security Framework: Main Steps

Many of the initial configuration tasks for Oracle Service Bus security require you to work in the WebLogic Server Administration Console to configure the WebLogic security framework. After these initial tasks, you can complete most security tasks from the Oracle Service Bus Console.

To configure the WebLogic security framework for Oracle Service Bus:

  1. If you plan to use SSL as part of transport-level security, do the following:
    1. In the WebLogic Server Administration Console, configure identity and trust. See Configuring Identity and Trust and Important Information Regarding Cross-Domain Security Support in Securing WebLogic Server.
    2. In the WebLogic Server Administration Console, configure SSL. See Configuring SSL in Securing WebLogic Server.
    3. Oracle recommends the following for your SSL configuration:

    • If you configure two-way SSL, you must choose between two modes: Client Certificate Requested But Not Enforced or Client Certificates Requested and Enforced. Oracle recommends that whenever possible you choose Client Certificate Requested and Enforced. For more information, see “Secure Sockets Layer (SSL)” in Security Fundamentals in Understanding WebLogic Security.
    • In a production environment, make sure that Host Name Verification is enabled. See “Using Host Name Verification” in Configuring SSL in Securing WebLogic Server.
  2. In the WebLogic Server Administration Console, configure authentication providers, which your proxy services use for inbound security.
  3. Table 2-4 describes the authentication providers that are commonly configured for Oracle Service Bus. For a description of all authentication providers that you can configure, see Security Providers in Securing WebLogic Server.

    Table 2-4 Authentication Providers
    If You Require Clients to Provide...
    Configure...
    Simple user names and passwords
    The WebLogic Authentication provider and use the Oracle Service Bus Console to enter the user names and passwords of the clients that you want to allow access.

    Note: As described in Configuring Authentication Providers, Oracle recommends that you use the default WebLogic Authentication provider for all WebLogic Server and Oracle Service Bus administrative accounts.

    See “Adding a User” under Security Configuration in Using the Oracle Service Bus Console.
    X.509 tokens for inbound HTTPS and two-way SSL authentication
    All of the following:
    • The WebLogic Identity Assertion provider, which can validate X.509 tokens but does not by default. Make sure that you enable this provider to support X.509 tokens. In addition, enable this provider to use a user name mapper. See “Identity Assertion and Tokens” under “Authentication” in Security Fundamentals in Understanding WebLogic Security.
    • WebLogic CertPath Provider, which completes and validates certificate chains by using trusted Certificate Authority based checking.
    Custom authentication and username/password tokens for inbound HTTP and message-level authentication
    All of the following:
    • An Identity Assertion provider, possibly user-written or from a third-party, that can validate the token type. Make sure that you enable this provider to support the token. See “Identity Assertion and Tokens” under “Authentication” in Security Fundamentals in Understanding WebLogic Security.
    X.509 tokens for inbound Web Services Security X.509 Token Authentication
    If any of your proxy services or business services are Web services that use abstract WS-Policy statements, you must also configure the following:
    • In the Web Service security configuration named __SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__ add the UseX509ForIdentity property and set it to true. See Use X.509 Certificates to Establish Identity in the WebLogic Server Administration Console Online Help.
    SAML tokens
    All of the following:
    • WebLogic SAML Identity Assertion Provider V2, which authenticates users based on Security Assertion Markup Language 1.1 (SAML) assertions.
    • WebLogic SAML Credential Mapping Provider V2, which maps Oracle Service Bus users to remote users.

  4. If needed, in the WebLogic Server Administration Console, configure one or more Identity Assertion providers to handle the token types, such as X.509 or custom token types, for which you require support. For a description of all Identity Assertion providers that you can configure, see Security Providers in Securing WebLogic Server.
  5. If you plan to create proxy services or business services that require WS-Security digital signatures on inbound requests, enable the Certificate Registry provider, which is a Certification Path provider that validates inbound certificates against a list of certificates that you register.
  6. See Configure Certification Path Providers in WebLogic Server Administration Console Online Help.

  7. If you configure message-level security (in inbound requests or outbound requests) to require user name and password tokens, and if you want messages to provide a password digest instead of cleartext passwords, do the following:
    1. In the WebLogic Server Administration Console, find the two Web Service security configurations that Oracle Service Bus provides and set the value of the UsePasswordDigest property to true.
    2. The Oracle Service Bus Web Service security configurations are named:
      __SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__ and
      __SERVICE_BUS_OUTBOUND_WEB_SERVICE_SECURITY_MBEAN__

      For information on setting the values in Web Service security configurations, see Use a Password Digest in SOAP Messages in the WebLogic Server Administration Console Online Help.

    3. For each authentication provider that you configured in step 2, in the WebLogic Server Administration Console, select the Password Digest Enabled check box.
    4. For each identity assertion provider that you configured in step 2, in the WebLogic Server Administration Console set wsse:PasswordDigest as one of the active token types.
  8. If you plan to create a service key provider (which passes key-certificate pairs in outbound requests), use the WebLogic Server Administration Console to configure a PKI credential mapping provider. In any WebLogic Server domain that hosts Oracle Service Bus, you can configure at most one PKI credential mapping provider.
  9. A PKI credential mapping provider maps Oracle Service Bus service key providers to key-pairs that can be used for digital signatures and encryption (for Web Services Security) and for outbound SSL authentication. For more information, see “Configuring a PKI Credential Mapping Provider” in Configuring WebLogic Security Providers in Securing WebLogic Server.

    You store the key-pairs that the PKI credential mapping provider uses in a keystore. You can store the PKI credential mappings in WebLogic Server’s identity keystore or in a separate keystore. Configure each WebLogic Server instance to have access to its own copy of each keystore. All entries referred to by the PKI credential mapper must exist in all keystores (same entry with the same alias). For information about configuring keystores in WebLogic Server, see “Identity and Trust” in Security Fundamentals in Understanding WebLogic Security.

    Note: When you create an Oracle Service Bus domain, by default the domain contains a user name/password credential mapping provider, which you can use if you need credential mapping for user names and passwords. In addition to this user name/password credential mapping provider, you can add one PKI credential mapping provider. An Oracle Service Bus domain can contain at most one user name/password credential mapping provider, one PKI credential mapping provider, and multiple SAML credential mapping providers.
  10. If you want to enable security auditing, do the following:
    1. In the WebLogic Server Administration Console, configure an auditing provider. See Configuring a WebLogic Auditing Provider in Securing WebLogic Server.
    2. To enable auditing of events related to WS-Security, when you start each Oracle Service Bus server, include the following Java option in the server’s startup command:
    3. Note: -Dcom.bea.wli.sb.security.AuditWebServiceSecurityErrors=true

      Oracle Service Bus supports the auditing of security events but it does not support configuration auditing, which emits log messages and generates audit events when a user changes the configuration of any resource within a domain or invokes management operations on any resource within a domain. See Configuration Auditing Securing WebLogic Server.

  11. If you have not already done so, in the WebLogic Server Administration Console, activate your changes. If you have made changes that require you to restart WebLogic Server, the Administration Console will indicate that a restart is required. If you see such a message, restart all WebLogic Server instances that host Oracle Service Bus so your modifications to the security providers will be in effect for the remaining configuration steps.

 


Context Properties Are Passed to Security Providers

Context Properties provides a way (the ContextHandler interface) to pass additional information to the WebLogic Security Framework so that a security provider can obtain contextual information beyond what is provided by the arguments to a particular provider method. A ContextHandler is a high-performing WebLogic class that obtains additional context and container-specific information.

Oracle Service Bus makes use of the ContextHandler interface and passes several context properties to the security framework for transport-level and message-level authentication, transport-level and message-level access control, and credential mapping.

This section describes the situations in which Oracle Service Bus-specific context properties are used.

Context Properties for HTTP Transport-Level Authentication

When an HTTP proxy service is configured for authentication, the HTTP transport provider passes an Oracle Service Bus implementation of the WebLogic Server ContextHandler. There is no user configuration required for this feature.

The ContextHandler properties in Table 2-5 are passed at runtime, under the following conditions:

ContextHandler Properties for Access Control and Message-Level Custom Authentication

The ContextHandler properties shown in Table 2-6 are passed at runtime, under the following conditions:

Additional Transport-Specific Context Properties

In addition to the properties in Table 2-6, other transport-specific properties may be present. For each transport request-header (see the transport SDK), a property with the name

com.bea.contextelement.alsb.router.inbound.request.headers.<provider-id>.<header-name>

is present, where provider-id is the transport provider id, and header-name is one of the request-headers declared in the provider's schema file.

The type and semantics of these properties is transport-specific. For HTTP proxy services, the properties in Table 2-7 are also available.

Table 2-7 Additional Message-Level Security ContextHandler Properties for HTTP Proxy Services
Property Name
Type
Property Value
com.bea.contextelement.alsb.router.inbound.request.metadata.http.relative-URI
java.lang.String
The relative URI of the request.
com.bea.contextelement.alsb.router.inbound.request.metadata.http.query-string
java.lang.String
The query string that is contained in the request URL after the path.
com.bea.contextelement.alsb.router.inbound.request.metadata.http.client-host
java.lang.String
The fully qualified name of the client that sent the request.
com.bea.contextelement.alsb.router.inbound.request.metadata.http.client-address
java.lang.String
The Internet Protocol (IP) address of the client that sent the request.

Administrator-Supplied Context Properties for Message-Level Authentication

Both custom username/password authentication and custom token authentication allow users (who are in the IntegrationAdmin or IntegrationDeployer roles) to pass additional context information to the security provider in the Context Properties field on the Security tab.

You can configure additional context properties by entering the Property Name as a literal string, and the Value Selector as a valid XPath expression. (XPath expressions can also be literal strings.)

The XPath expression is evaluated at runtime against the same message part that is used for the custom token or custom username/password. That is, the Value Selector XPath expressions are evaluated against the header for SOAP-based proxy services, and against the body for non-SOAP-based proxy services.

Security Provider Must Have Knowledge of the Property Name

A ContextHandler is essentially a name/value list and, as such, it requires that a security provider know what names to look for. Therefore, for both transport- and message-level custom authentication, the XPath expressions are evaluated only if an Authentication provider or Identity Assertion provider asks for the value of one of these properties.

This means that your configured Authentication or Identity Assertion provider must explicitly know which property names to request via the ContextHandler.getValue(propertyName)method. The only way to satisfy this requirement is for you, or a third party, to write a custom Authentication or Identity Assertion provider.

For example, Listing 2-1 shows how to get the HttpServletRequest property from a provider that you write.

Listing 2-1 Getting the HttpServletRequest Property
:
Object requestValue = handler.getValue("com.bea.contextelement.alsb.transport.http.http-request");
if ((requestValue == null) || (!(requestValue instanceof HttpServletRequest)))
return;
HttpServletRequest request = (HttpServletRequest) requestValue;
log.println(" " + HTTP_REQUEST_ELEMENT + " method: " + request.getMethod());
log.println(" " + HTTP_REQUEST_ELEMENT + " URL: " + request.getRequestURL());
log.println(" " + HTTP_REQUEST_ELEMENT + " URI: " + request.getRequestURI());
return;

If the security provider does not need the value of the user-defined property, then the XPath expression is not evaluated.

WebLogic Server Administrative Channel is Supported

This release of Oracle Service Bus can use the WebLogic Server administrative channel.

As described in Understanding Network Channels, a WebLogic Server network channel is a configurable resource that defines the attributes of a network connection to WebLogic Server.

You can configure a particular type of network channel, called an administrative channel, to isolate “administration” and application (“business”) traffic in a WebLogic domain. The administrative channel is a secured channel that accepts only SSL connections.

In Oracle Service Bus, business traffic is comprised of all messages sent to and from Oracle Service Bus proxy services and business services. SSL business traffic must use the default WebLogic Server secure network channel.

Administration traffic is comprised of all communication with the WebLogic Server Administration Console, Oracle Service Bus Administration console, internal traffic within a cluster, and traffic between administration scripts and admin or managed servers.

When an administrative channel is enabled in a domain, all of the administration traffic in that domain must go through that channel. Otherwise, the administration traffic also uses the default WebLogic Server secure network channel.

Using the Administrative Channel: Main Steps

  1. Close any open browser connections to the Oracle Service Bus Administration Console for the domain.

    As soon as you activate the administrative channel in WebLogic Server, the Oracle Service Bus Administration Console for the domain becomes unavailable at the current URL. The Help system also becomes unavailable.
  2. Enable the domain-wide administration port in the WebLogic Server Administration Console (which configures an administrative channel on your behalf), or explicitly create an administrative channel. Both of these tasks are described in Configuring Network Resources.
  3. The domain-wide administration port control is located on the Domain > Configuration > General page. The default administration port is 9002.

    Be sure to activate the change.

  4. Open a browser connection to the new URL for the Oracle Service Bus Administration Console for the domain.
  5. The URL is https://hostname:9002/sbconsole if you enabled the domain-wide administration port and accepted the default port number.

  6. Revise any startup scripts that refer to the old URL. If you are using the Windows graphical interface to launch the Oracle Service Bus Administration Console for the domain, revise the shortcut property to reflect the new URL.

 


Supported Standards and Security Providers

This release of Oracle Service Bus supports the following standards.

Table 2-8 Web Services Security and Related Standards
Standard
Version
WS-Security
1.0
WS-Policy
Previous releases of WebLogic Server, released before the formulation of the WS-SecurityPolicy specification, used security policy files written under the WS-Policy framework, using a proprietary Oracle schema for security policy.
As of release 3.0, Oracle Service Bus provides limited support for security policy files that conform to the WS-SecurityPolicy 1.2 specification, and continues to support the files written under the Oracle Web Services security policy schema first included in WebLogic Server 9.
Oracle Service Bus supports the WebLogic Server-proprietary format that is based on the assertions described in the December 18, 2002 version of the Web Services Security Policy Language (WS-SecurityPolicy) specification. This release of Oracle Service Bus does not incorporate the latest update of the specification (13 July 2005).
WS-Policy Attachment
1.0
WS-Security: Username Token Profile
1.0
WS-Security: X.509 Token Profile
1.0
WS-Security: SAML Token Profile
1.0
SAML
1.1

For information about the standards that WebLogic Server supports, see “Standards Support” under What's New in WebLogic Server in WebLogic Server Release Notes.

Support for WebLogic Security Providers

Oracle Service Bus supports the security providers that are included with WebLogic Server, such as the WebLogic authentication providers, identity assertion providers, authorization providers, role-mapping providers, credential mapping providers, and Certificate Lookup and Validation (CLV) providers. Additionally, Oracle Service Bus supports the WebLogic SAML Identity Assertion Provider V2 and WebLogic SAML Credential Mapping Provider V2.

Oracle Service Bus supports the WebLogic XACML Authorization provider and XACML Role Mapping provider, which use the OASIS standard eXtensible Access Control Markup Language (XACML). Support for the WebLogic Default Authorization provider and Default Role Mapping provider was deprecated in Oracle Service Bus 2.5. These providers are not supported anymore. If you are upgrading from a previous release of Oracle Service Bus in which you used the WebLogic Default Authorization provider and Default Role Mapping provider, use the WebLogic Server Administration Console to import authorization and role-mapping data into the XACML providers. See Upgrading Oracle Service Bus Environments in Oracle Service Bus Upgrade Guide.

Third-party security providers have not been tested and therefore have not been certified in Oracle Service Bus. However, the Oracle Service Bus security architecture supports the use of third-party authentication, authorization and role-mapping providers. Contact Oracle customer support if you are interested in third-party security provider support in Oracle Service Bus.

For more information about the security providers, see “WebLogic Security Providers” in the WebLogic Security Service Architecture in Understanding WebLogic Security.

Configuring Authentication Providers

Check the provided WebLogic Server Authentication providers to see if one meets your needs. WebLogic Server includes a broad array of Authentication providers, including the following:

See Improving the Performance of WebLogic and LDAP Authentication Providers for guidance on improving the performance of these authentication providers.

As described in Why Customize the Default Security Configuration, you may want to use an Authentication provider that accesses a database other than WebLogic Server's embedded LDAP server. For example, you might want to use a different authentication provider for the majority of user accounts, but continue to use the default authentication provider (embedded LDAP) for Oracle Service Bus and WebLogic Server administrative user accounts.

Using the WebLogic Authentication provider for all WebLogic Server and Oracle Service Bus administrative user accounts provides reliable access in the event of a network or database problem. Oracle recommends that you use the default WebLogic Authentication provider for all WebLogic Server and Oracle Service Bus administrative accounts for this reason.

If one of the bundled Authentication providers meets your needs, see Configuring Authentication Providers for instructions on how to configure this Authentication provider in the WebLogic Server Administration Console.

If none of the Authentication providers included in WebLogic Server suits your needs, you (or a third-party) must first write a custom Authentication provider and then use the WebLogic Server Administration Console to add that provider to the security realm. To do this, follow these steps:

Note: Only a broad overview of the required tasks is included here. You will need to consult the WebLogic Server documentation to actually complete the tasks.
  1. Create Runtime Classes Using the Appropriate SSPIs
  2. Generate an MBean Type Using the WebLogic MBeanMaker
  3. Configure the Custom Authentication Provider Using the Administration Console

See Authentication Providers in Developing Security Providers for WebLogic Server for additional information.

Using a Custom Authorization Provider to Protect Oracle Service Bus Resources

You can use Oracle Service Bus resources with custom Authorization providers, but those providers must understand the type and format of the Oracle Service Bus resources.

There are three possible resource objects for Oracle Service Bus that an Authorization provider must be able to detect and handle:

These resource objects are described in the sections that follow.

WebLogic Authorization Provider Usage Information

This section briefly describes the WebLogic Server Authorization provider SSPI. See Developing Security Providers for WebLogic Server for complete information.

You protect resources by binding access control policies to resources via the Oracle Service Bus console, third-party tools or scripts. The WebLogic Server Security Service Provider Interface (SSPI) requires containers, such as Oracle Service Bus, to implement the Resource SPI. These implementations represent concrete resources.

The Authorization provider database contains a map from resource to policy. When an attempt is made to access a resource, the container calls the runtime SSPI to get an access control decision. The container passes a resource instance indicating which resource is being accessed.

An Authorization provider has one method, getAccessDecision(). The getAccessDecision() method obtains the implementation of the AccessDecision SSPI. The AccessDecision SSPI itself has one method, isAccessAllowed(). isAccessAllowed has five parameters, one of which is the Resource object for which access is being requested.

isAccessAllowed determines if the requestor should be allowed to access the named resource. To do this, the Authorization provider must find the right access control policy to evaluate. The provider must first look for a policy bound to the resource passed in. The lookup can use either the Resource.getId() or Resource.toString() method as a lookup key. If no policy is found, the Authorization provider must then get the parent resource and look again. This process is repeated until a policy is found or the parent is null, in which case no policy is found. When no policy is found, isAccessAllowed must return false.

This algorithm allows you to create coarse-grained policies that protect all proxy services in a given project or folder, all resources in a project, or all Oracle Service Bus proxy services in an Oracle Service Bus domain. More specific, finer-grained policies take precedence over coarse-grained policies.

Note: The Oracle Service Bus console user interface does not provide pages for protecting proxy services at the folder, project or domain level.

Oracle Service BusProxyServiceResource Object

The ALSBProxyServiceResource object is used for transport-level and message-level access control to Oracle Service Bus proxy services. The ALSBProxyServiceResource resource extends weblogic.security.service.ResourceBase, which itself implements weblogic.security.spi.Resource.

ALSBProxyServiceResource implements the following methods, as described in weblogic.security.spi.Resource:

getType()

Returns the type, where type is "<alsb-proxy-service>"

getKeys()

Returns up to four key-value properties: path, proxy, action, and operation. The properties are defined as follows:
An ALSBProxyServiceResource has from 1 to 4 keys. The following table explains how the various combinations protect proxy services. The most specific policies take precedence.

If the Resource Contains These Keys
A Policy Bound to the Resource Protects:
path
The policy protects all proxy services in the given path
path and proxy
The policy protects all access to the given proxy service (transport-level as well as message-level)
path, proxy, and action
If action="invoke":
  • The policy is the transport-level policy to the given proxy
- If action="wss-invoke":
  • The policy is the message-level policy to the given proxy (for all operations)
path, proxy, action="wss-invoke", and operation
The policy is a message-level policy for the given proxy and operation

getPath()

Gets the path (project and folders) to the proxy service. This is the path where the proxy service exists within the Oracle Service Bus configuration framework.

getProxyServiceName()

Gets the name of the proxy service. For example, proxy=myProxy.

getAction()

Gets one of two values, invoke or wss-invoke. For example, action=invoke.

getOperation()

Gets the name of the operation to invoke, and is used only when action is wss-invoke. For example, operation=processPO.

makeParent()

Creates a new ALSBProxyServiceResource object that represents the parent of the current ALSBProxyServiceResource resource. makeParent() uses the path of the proxy service to create the parent.
ALSBProxyServiceResource Examples

The following examples show various uses of the ALSBProxyServiceResource object.

ProjectResourceV2 Object

The ProjectResourceV2 is the root resource for all ALSBProxyServiceResource objects in a given project. ProjectResourceV2 extends ResourceBase.

Setting an access control policy on a ProjectResourceV2 provides a coarse-grained access control policy for all proxy services in the given project that do not have more specific policies.

ProjectResourceV2 has the following methods:

getType()

Returns the type, where type is "<alsb-project>".

getKeys()

Returns the key, where key is "project-name”.

getName()

Gets the name of the ProjectResourceV2 object.

makeParent()

There is no parent for an ProjectResourceV2 object. This method therefore returns the object name that was used to create the ProjectResourceV2 object, or null if ProjectResourceV2 does not exist.

ConsoleResource Object

The com.bea.wli.security.resource.ConsoleResource object is used for access control to the Oracle Service Bus console. However, we do not recommend that you set access control policies for ConsoleResource objects via a custom Authorization provider. This is because these policies are subject to change in future Oracle Service Bus releases.

We instead recommended that even if you need to use a custom Authorization provider, you also continue to use the WebLogic Server XACML Authorization provider to maintain the policies for the ConsoleResource object. In this case of two Authorization providers, you must also configure an Adjudication provider.


  Back to Top       Previous  Next