Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle Service Bus
11g Release 1 (11.1.1.7)

Part Number E15866-09
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

45 Understanding Oracle Service Bus Security

This chapter provides an overview of the Oracle Service Bus security model and its features, including inbound and outbound 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 Oracle 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.

This chapter includes the following sections:

45.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. Figure 45-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 45-1 Inbound and Outbound Security

Description of Figure 45-1 follows
Description of "Figure 45-1 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 the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

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

45.2 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 Section 2.1.15, "Creating Service Account Resources."

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 the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

45.3 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 45-1 describes the decisions that affect how Oracle Service Bus propagates client identities to business services.

Table 45-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 Section 45.9, "Using 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 Chapter 53, "Using SAML with Oracle Service Bus."

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 Administration 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 Administration 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 authorize only specific, authenticated users to have 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 authorize only specific, authenticated users to have 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 Section 54.1, "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 supplied by clients to the credentials required by the business service. The more clients for a business service, the more work will be required to maintain this credential mapping.


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

Table 45-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 Section 49.2.1, "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 Section 49.2.2, "Configuring Outbound HTTP Security: Main Steps."

Be sure to create a pass-through service account and attach the account to the business service.

Same as previous requirement.

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 Section 49.2.1, "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 Section 49.2.2, "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 Section 49.2.1, "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 Section 49.2.2, "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 Section 49.2.1, "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 Section 49.2.2, "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 Section 2.1.15, "Creating Service Account Resources."


Table 45-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 45-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 Section 49.2.1, "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 Section 2.1.15, "Creating Service Account Resources."

Same as previous requirement.

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 Section 49.2.1, "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. SeeSection 2.1.15, "Creating Service Account Resources."

Same as previous requirement.

Map the client credentials to a SAML token. Oracle Service Bus asserts the user identity.

  1. Configure inbound HTTP security. See Section 49.2.1, "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 Section 53.1, "Mapping Identity to a SAML Token."

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 Section 2.1.15, "Creating Service Account Resources."

Same as previous requirement.

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 Section 2.1.15, "Creating Service Account Resources."

Same as previous requirement.

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 Section 53.1, "Mapping Identity to a SAML Token."

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 Section 49.2.1, "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 Section 49.2.2, "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 Section 49.2.1, "Configuring Inbound HTTP Security: Main Steps."

  2. Configure a SAML credential mapping provider. See Section 53.1, "Mapping Identity to a SAML Token."

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 Section 52.3.1, "Creating an Active Intermediary Proxy Service: Main Steps."

Same as previous requirement.

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 Section 52.3.1, "Creating an Active Intermediary Proxy Service: Main Steps."

  2. Configure a SAML credential mapping provider. See Section 53.1, "Mapping Identity to a SAML Token."

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 Section 52.3.1, "Creating an Active Intermediary Proxy Service: Main Steps."

  2. Configure a SAML credential mapping provider. See Section 53.1, "Mapping Identity to a SAML Token."

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 Section 53.3, "Authenticating SAML Tokens in Proxy Service Requests."

  2. Configure a SAML credential mapping provider. See Section 53.1, "Mapping Identity to a SAML Token."

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 Section 52.3.1, "Creating an Active Intermediary Proxy Service: Main Steps."

  2. Create a business service that enforces one of the token profiles. See Section 52.4, "Configuring Business Service Message-Level Security: Main Steps" or Section 53.2, "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 Chapter 35, "Tuxedo Transport."

45.3.1 Example: Authentication with a User Name Token

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

  • Require clients to provide user names and passwords in their requests

    You can require Web services clients to provide credentials at the transport level, the message level, or both. If you require clients to provide credentials at both levels, Oracle Service Bus uses the message-level credentials for identity propagation and credential mapping.

  • Authenticate clients

Figure 45-2 How Service Accounts Are Used

Description of Figure 45-2 follows
Description of "Figure 45-2 How Service Accounts Are Used"

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.

    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.

  2. The proxy service asks the domain's authentication provider if the user exists in the domain's authentication provider store.

    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.

  3. 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.

    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.

  4. The proxy service sends its outbound request with the user name and password that was returned from the service account.

45.4 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 Oracle WebLogic Server or other resources on Oracle WebLogic Server. When assigning administrative users to roles, assign at least one user to the Oracle WebLogic Server Admin role. The Oracle WebLogic Server security roles are described in Table 47-2.

For more information, see Chapter 47, "Configuring Administrative Security."

45.5 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 Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.

Oracle Service Bus relies on Oracle 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 Section 47.1, "Administrative Security Roles and Privileges." When a user attempts to access an Oracle Service Bus resource, Oracle 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 an Oracle WebLogic Server administrator can define security policies or edit security roles in the Oracle Service Bus Administration 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 Administration Console contains a Security Configuration module for viewing and configuring users, groups, and security roles. Additionally, the Oracle Service Bus Administration Console lets you view and configure credentials.

45.5.1 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 Administration Console, as described in "Editing Transport-Level Access Policies" and "Editing Message-Level Access Policies."

45.5.2 Access Control Policy Management

Access control policies are persisted in authorization providers, and there is a reference to them in the Oracle Service Bus 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 Administration 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, Oracle WebLogic Server instances, data sources, and so forth from the Oracle WebLogic Server Administration 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.

45.5.2.1 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.

45.5.2.2 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.

45.5.2.3 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.

45.5.2.4 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.

45.6 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:

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

45.6.1 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:

  • Proxy service security and policy configuration:

    • A reference to the service key provider.

    • The set of WS-Policies that are bound directly to the service through the Policies tab.

      Note:

      If the service is using WSDL-based policies, the policies are not preserved by this check box. This is because the WSDL might itself be updated and the service must reflect the WSDL.

      The control also preserves the type of the WS-Policy Binding, either Custom (through the Policies tab) or WSDL-based.

    • The state of the Process WS-Security Header option.

    • Message-level custom authentication configuration.

  • Proxy service transport-specific security configuration:

    • For HTTP, the HTTPS flag and the authentication mode (anonymous, BASIC, client certificate, or custom token).

    • For JMS, the JMS and JNDI service accounts.

    • For email and FTP, the service account reference.

    • The SFTP authentication configuration.

  • Business service security and policy configuration:

    • WS-Policy bindings

    • The Pass Caller's Subject setting.

    • A reference to the service account for outbound WS-Security.

  • Business service transport-specific security configuration:

    • For HTTP, the authentication mode (anonymous, BASIC, or client certificate) and the service account reference.

    • For JMS, references to the JMS and JNDI service accounts.

    • For FTP, EJB, Tuxedo, and DSP, the service account reference.

    • The SFTP authentication configuration.

45.6.2 Preserve Credentials Check Box

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

  • PKI credentials in service key providers.

    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 Oracle Fusion Middleware Securing Oracle WebLogic Server.

  • Username and passwords in service accounts.

  • Username and password in SMTP server, JNDI provider, and UDDI registries.

45.6.3 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.

45.7 Configuring the Oracle WebLogic Security Framework: Main Steps

Many of the initial configuration tasks for Oracle Service Bus security require you to work in the Oracle 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 Administration 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 Oracle WebLogic Server Administration Console, configure identity and trust. See "Configuring Identity and Trust" and "Important Information Regarding Cross-Domain Security Support" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

    2. In the Oracle WebLogic Server Administration Console, configure SSL. See "Configuring SSL" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

    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 Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.

    • In a production environment, make sure that Host Name Verification is enabled. See "Using Host Name Verification" in "Configuring SSL" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

  2. In the Oracle WebLogic Server Administration Console, configure authentication providers, which your proxy services use for inbound security.

    Table 45-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 Oracle Fusion Middleware Securing Oracle WebLogic Server.

    Table 45-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 Administration Console to enter the user names and passwords of the clients that you want to allow access.

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

    See "Adding Users" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

    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" in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.

    • 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

    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.

    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 Oracle Fusion Middleware Oracle 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.


  3. If needed, in the Oracle 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 Oracle Fusion Middleware Securing Oracle WebLogic Server.

  4. 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.

    See "Configure Certification Path Providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

  5. 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 Oracle 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.

      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 Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

    2. For each authentication provider that you configured, in the Oracle WebLogic Server Administration Console, select the Password Digest Enabled check box.

    3. For each identity assertion provider that you configured, in the Oracle WebLogic Server Administration Console set wsse:PasswordDigest as one of the active token types.

  6. If you plan to create a service key provider (which passes key-certificate pairs in outbound requests), use the Oracle WebLogic Server Administration Console to configure a PKI credential mapping provider. In any Oracle WebLogic Server domain that hosts Oracle Service Bus, you can configure at most one PKI credential mapping provider.

    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 Oracle Fusion Middleware Securing Oracle 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 Oracle WebLogic Server's identity keystore or in a separate keystore. Configure each Oracle 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 Oracle WebLogic Server, see "Identity and Trust" in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.

    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.

  7. To enable security auditing, do the following:

    1. In the Oracle WebLogic Server Administration Console, configure an auditing provider. See "Configuring the WebLogic Auditing Provider" in Oracle Fusion Middleware Securing Oracle 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:

      -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 "Enabling Configuration Auditing" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

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

45.8 Context Properties Are Passed to Security Providers

Context Properties provide 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.

45.8.1 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 Oracle WebLogic Server ContextHandler. There is no user configuration required for this feature.

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

  • To Authentication providers, if the proxy is configured for HTTP BASIC authentication.

  • To Identity Assertion providers, if the proxy is configured for CLIENT-CERT identity assertion.

  • To Identity Assertion providers, if the proxy is configured for HTTP custom token identity assertion.

Table 45-5 ContextHandler Properties for HTTP Transport Authentication

Property Name Type Property Value
com.bea.contextelement.alsb.service-info
com.bea.wli.sb.services.ServiceInfo

An instance of ServiceInfo that contains information about the proxy service.

com.bea.contextelement.alsb.transport.endpoint
com.bea.wli.sb.transports.TransportEndPoint

This is the HTTP or HTTPS endpoint.

com.bea.contextelement.alsb.transport.http.http-request
javax.servlet.http.HttpServletRequest 

This is the HttpServletRequest object.

com.bea.contextelement.alsb.transport.http.http-response
javax.servlet.http.HttpServletResponse

This is the HttpServletResponse object.


45.8.2 ContextHandler Properties for Access Control and Message-Level Custom Authentication

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

  • To Authentication providers when performing message-level custom username/password authentication.

  • To Identity Assertion providers when performing message-level custom token identity assertion.

  • To Authorization providers when performing transport-level or message-level access control.

Table 45-6 ContextHandler Properties for Message-Level Custom Authentication and Access Control

Property Name Type Property Value
com.bea.contextelement.alsb.router.ProxyService
java.lang.String

The service name (full-name; for example /myproject/myfolder/svc-a).

com.bea.contextelement.alsb.router.ServiceUri
java.net.URI

The base URI from which the message was received.

com.bea.contextelement.alsb.router.inbound.TransportProvider
java.lang.String

The Id of the transport provider that received this message.

com.bea.contextelement.alsb.router.inbound.request.MessageId
java.lang.String

This is the transport provider-specific message identifier. Ideally it should uniquely identify the message among other messages going through the Oracle Service Bus runtime. However, Oracle Service Bus does not depend on the message Id being unique. The message Id is added to the message context and thus visible in the pipeline.

com.bea.contextelement.alsb.router.inbound.request.CharacterEncoding
java.lang.String

Character encoding used in the message payload, or null.

com.bea.contextelement.wli.Message
java.io.InputStream

The request message as an input stream.


45.8.3 Additional Transport-Specific Context Properties

In addition to the properties in Table 45-7, 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 45-3 are also available.

Table 45-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.


45.8.4 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.

45.8.5 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 through 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, Example 45-1 shows how to get the HttpServletRequest property from a provider that you write.

Example 45-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.

45.8.6 Oracle WebLogic Server Administrative Channel is Supported

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

As described in "Understanding Network Channels" in Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server, a Oracle WebLogic Server network channel is a configurable resource that defines the attributes of a network connection to Oracle 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 Oracle WebLogic Server secure network channel.

Administration traffic is comprised of all communication with the Oracle 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 Oracle 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 Oracle 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 Oracle 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" in Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server.

    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.

  3. Open a browser connection to the new URL for the Oracle Service Bus Administration Console for the domain.

    The URL is https://hostname:9002/sbconsole if you enabled the domain-wide administration port and accepted the default port number.

  4. 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.

45.9 Using Security Providers

This section provides instructions on using security providers with Oracle Service Bus.

This section includes the following topics:

45.9.1 Configuring Authentication Providers

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

  • The WebLogic Authentication provider accesses user and group information in Oracle WebLogic Server's embedded LDAP server. This is the default out-of-the-box authentication provider. This provider is not optimized for use with very large numbers of users.

  • LDAP Authentication providers access external LDAP stores. You can use an LDAP Authentication provider to access any LDAP server. Oracle WebLogic Server provides LDAP Authentication providers already configured for Open LDAP, Oracle Directory Server Enterprise Edition, Microsoft Active Directory, and Novell NDS LDAP servers.

  • RDBMS Authentication providers access external relational databases. Oracle WebLogic Server provides three RDBMS Authentication providers: SQL Authenticator, Read-only SQL Authenticator, and Custom RDBMS Authenticator.

  • The SAML Authentication provider, which authenticates users based on Security Assertion Markup Language 1.1 (SAML) assertions.

See "Improving the Performance of WebLogic and LDAP Authentication Providers" in Oracle Fusion Middleware Securing Oracle WebLogic Server for guidance on improving the performance of these authentication providers.

As described in "Why Customize the Default Security Configuration" in Oracle Fusion Middleware Securing Oracle WebLogic Server, you may want to use an Authentication provider that accesses a database other than Oracle 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 Oracle WebLogic Server administrative user accounts.

Using the WebLogic Authentication provider for all Oracle 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 Oracle 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" in Oracle Fusion Middleware Securing Oracle WebLogic Server for instructions on how to configure this Authentication provider in the Oracle WebLogic Server Administration Console.

If none of the Authentication providers included in Oracle WebLogic Server suits your needs, you (or a third-party) must first write a custom Authentication provider and then use the Oracle WebLogic Server Administration Console to add that provider to the security realm, as described in the following steps:

Note:

Only a broad overview of the required tasks is included here. You will need to consult the Oracle WebLogic Server documentation to actually complete the tasks.

Adding a Provider to a Security Realm 

  1. "Create Runtime Classes Using the Appropriate SSPIs" (in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server).

  2. "Generate an MBean Type Using the WebLogic MBeanMaker"

  3. "Configure the Custom Authentication Provider Using the Administration Console"

45.9.2 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.

45.9.2.1 WebLogic Authorization Provider Usage Information

This section briefly describes the Oracle WebLogic Server Authorization provider SSPI. See "Authorization Providers" in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server for complete information.

You protect resources by binding access control policies to resources through the Oracle Service Bus Administration Console, third-party tools or scripts. The Oracle 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 getId() or toString() method as a lookup key, as described in "Looking Up WebLogic Resources in a Security Provider's Runtime Class" in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server. 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 lets you 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 Administration Console user interface does not provide pages for protecting proxy services at the folder, project or domain level.

45.9.2.2 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:

  • path is the full-name of the proxy service. For example, path=project/folder1/folder2

  • proxy is the name of the proxy service. For example, proxy=myProxy

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

    The action attribute is used to distinguish between transport-level and message-level access control. invoke is used for transport-level access control. wss-invoke is used for message-level access control; that is, access control on WS-Security active intermediaries or proxies with custom message-level authentication. The operation attribute is only allowed when action is wss-invoke.

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

    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.

45.9.2.2.1 ALSBProxyServiceResource Examples

The following examples show various uses of the ALSBProxyServiceResource object.

  • Using ALSBProxyServiceResource for transport-level access control for proxy project/folder/myProxy:

    type=<alsb-proxy-service>, path=project/folder, proxy=myProxy, action=invoke
    
  • Using ALSBProxyServiceResource for message-level access control for operation processPO on proxy project/folder/myProxy:

    type=<alsb-proxy-service>, path=project/folder, proxy=myProxy, action=wss-invoke, operation=processPO
    
  • Using the parentage hierarchy for an ALSBProxyServiceResource, from fine-grained to coarse-grained:

    type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy, action=wss-invoke, operation=foo
    type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy, action=wss-invoke
    type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy
    type=<alsb-proxy-service>, path=myProject/f1/f2
    type=<alsb-proxy-service>, path=myProject/f1
    type=<alsb-proxy-service>, path=myProject
    type=<alsb-project>, project-name=myProject
    type=<alsb-proxy-service>
    

45.9.2.3 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.

45.9.2.4 ConsoleResource Object

The com.bea.wli.security.resource.ConsoleResource object is used for access control to the Oracle Service Bus Administration Console. However, we do not recommend that you set access control policies for ConsoleResource objects through 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 Oracle 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.

45.9.3 About Errors When Using Security Provider Policies

If you are using a plug-in security provider with Oracle WebLogic Server to store policies for use with Oracle Service Bus, you may encounter an error that says Oracle Service Bus cannot determine whether or not required policies are available; for example, error BEA-387896, as described in the Oracle Fusion Middleware Messages for Oracle Service Bus.

An error message like that does not necessarily mean the policies do not exist, or that you have a connection or configuration problem with the security provider. Oracle Service Bus uses an Oracle WebLogic Server SSPI to read policies that security providers can implement. However, the SSPI read functionality is optional. It is possible that a security provider does not allow read access by not implementing this SSPI. In such a case, Oracle Service Bus cannot reliably determine whether or not the security provider contains the required policies, even when the required policies could very well exist in the security provider.

To determine whether or not such a warning indicates a real problem, try creating or modifying resources in the Oracle Service Bus Administration Console. Also, try securing a proxy service with an access control policy and test it. See "Editing Message-Level Access Policies" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus for more details on how to configure an access control policy on a proxy service. If you can successfully create or manipulate resources as well as test a secured proxy service while using the security provider, then the security provider is configured correctly and you can safely ignore the error message.