Defining Access Security for Oracle Service Bus

11 Defining Access Security for Oracle Service Bus

This chapter describes how to create users, groups, and roles for use in Service Bus inbound security and administrative security. Inbound transport-level security and message-level security use the user, group, and role data to authenticate inbound client requests, and apply access control policies to determine which authenticated users are authorized to use proxy services and business services. Administrative security uses the user, group, and role data to determine which authenticated users are authorized to create or modify Service Bus resources or to monitor Service Bus performance.

This chapter includes the following sections:

11.1 Understanding Oracle Service Bus Application Security

For authentication and authorization, Service Bus uses Oracle Application Development Framework (ADF) security, which is built on Oracle Platform Security Services (OPSS).

For more information about OPSS, see Introduction to Oracle Platform Security Services in Oracle Fusion Middleware Securing Application wit Oracle Platform Security Services. For information about ADF security, see ADF Security Framework in Understanding Oracle Application Development Framework.

You define user accounts, groups, application roles, and policies in order to configure security for Service Bus components and to grant specific permissions to each user. To give users access to administrative functions, such as creating proxy services, you assign them to predefined application roles with pre-defined access privileges. You can also create user groups and assign those groups to the predefined roles in order to give the same access permissions to a group of users. You cannot change the access privileges for the application roles, but you can grant individual access permissions to users and groups along with the default roles.

11.1.1 Users

Users are single entities that can be authenticated in Service Bus, and can be a person or a software entity, such as a web services client. You must give each user a unique identity (name) within a security realm. Typically, the users that you create fall into one of two categories:

Client users who can access proxy services or business services. If you create a large number of client users, consider organizing them into security groups.
Administrative users who use the Oracle Service Bus Console to create or modify proxy services, business services, and other Service Bus resources. Administrative users also use Fusion Middleware Control to monitor and mange runtime components.

Service Bus recommends role-based security for its administrative functions. Although you can grant individual access privileges directly to users or groups, Oracle recommends granting administrative privileges only by assigning them to application roles.

11.1.2 Groups

To facilitate administering a large number of users, you can organize users into named groups. Then, instead of giving access privileges or role identities to each user, one at a time, you give privileges or identities to all users in a group. You can create custom security groups to facilitate giving users access to administrative functions such as creating proxy services.

In the simplest scenario for configuring administrative security, you create multiple groups, each assigned a unique set of permissions through roles, and then create users and add them to the groups. Each user in a group is automatically always a member of the corresponding roles with all of the pre-defined access privileges.

11.1.3 Roles

Service Bus provides several default roles, each with a specific set of access permissions. The role assigned to a user determines the tasks that user can perform. You can assign roles to users or to groups to secure resources and services in the Oracle Service Bus Console and Fusion Middleware Control. This restricts user access to only those actions permitted by the roles you assign. You can also restrict the user interfaces that should be made available to a given role depending on the privileges of the role.

For information about the permissions granted by each role, see Role-Based Access in Oracle Service Bus.

A user or group can be associated with multiple roles. For example, you create two groups named MyCustomersEast and MyCustomersWest. You create a security role named PrivilegedCustomer and create conditions so that the MyCustomersWest group is in the role from 8am to 8pm EST, while the MyCustomersEast group is in the role from 8pm to 8am EST. Then you create an access control policy for a proxy service that gives the PrivilegedCustomer role access to the service. Different users will have access at different times depending on whether they are in the MyCustomersEast and MyCustomersWest group.

11.1.3.1 Oracle Service Bus Application Roles

Service Bus provides eight default application roles, each of which provide a specific set of access permissions that are common to a specific category of user. These roles are listed and described below.

11.1.3.1.1 MiddlewareAdministrator

The MiddlewareAdministrator role is an administrative security role, and has complete access to all resources and services in Service Bus. This includes the ability to create, edit, or delete user names, passwords, and credential alias bindings in service accounts and service key providers. The user names and passwords that this role can create are used only by service accounts for outbound authentication; they are not used to authorize access to Service Bus resources.

11.1.3.1.2 Developer

The Developer role is designed for use in development and testing environments only, and is not intended for production. Like MiddlewareAdministrators, Developers have full access to Service Bus features in the Oracle Service Bus Console and Fusion Middleware Control; but unlike MiddlewareAdministrators, Developers cannot add, edit, or delete users or application roles, or see sessions owned by other users. They can view activations. In a shared development environment, Developers cannot publish from JDeveloper to the server. Instead, they can export projects to the Oracle Service Bus Console to activate the resources.

11.1.3.1.3 Composer

The Composer role has full access to the monitoring and management features in Fusion Middleware Control, with the exception of importing and exporting resources. This role has view-only access to the Oracle Service Bus Console. The responsibilities of this role will increase in future releases.

11.1.3.1.4 Deployer

The Deployer role has full access to the monitoring and management features in Fusion Middleware Control and in the Oracle Service Bus Console, with the exception of updating security policies and resolving resequencing errors. Users with this role are generally responsible for deploying and upgrading applications.

11.1.3.1.5 Tester

The Tester role has read-only access to resources in the Oracle Service Bus Console, and to the monitoring and management features in Fusion Middleware Control. This role has full access to the Test Console from both the Oracle Service Bus Console and Fusion Middleware Control. Users with this role typically perform integrated testing on pre-production systems, running their tests with a combination of command-line clients, Fusion Middleware Control, and custom interfaces.

11.1.3.1.6 MiddlewareOperator

The MiddlewareOperator role has access to certain monitoring tasks and session management, and has read access to all Service Bus resources. In addition, this role has access to create, view, edit, and delete alert rules and alert destinations, and to view and edit operational settings. The role does not have access to view all sessions, import or export resources, change security policies, or launch the test console. Users with this role are responsible for performing day-to-day operations on Service Bus resources and ensuring operational continuity.

11.1.3.1.7 ApplicationOperator

The ApplicationOperator role has read-only access to the Oracle Service Bus Console and Fusion Middleware Control. It has full access to the Resequence Groups tab. Application operators receive notifications on faults and can take corrective action by recovering faults, skipping the message, or aborting a transaction.

11.1.3.1.8 Monitor

The Monitor role is granted to users who monitor resources and services in the Oracle Service Bus Console and Fusion Middleware Control. Users assigned to this role have read access to all Service Bus resources, and can also monitor violations to Service Level Agreements (SLAs) and the alerts from the pipeline.

11.1.3.2 WebLogic Server Security Roles

The Service Bus roles have permission to modify only Service Bus resources; they do not have permission to modify Oracle WebLogic Server or other resources on Oracle WebLogic Server. To give permission to modify Oracle WebLogic Server resources, add a user to one of the Oracle WebLogic Server security roles. In each Service Bus domain, make sure that you add at least one user to the Administrator role.

For more information about security roles, see Users, Groups, and Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.

11.1.3.3 Compatibility with Previous Releases

In release 11g, Service Bus provided four, pre-defined security roles that give administrative privileges. These roles are provided in the current release for backward compatibility.

IntegrationAdmin (similar to Administrator in 12c)
IntegrationDeployer (similar to Deployer in 12c)
IntegrationMonitor (similar to Monitor in 12c)
IntegrationOperator (similar to Operator in 12c)

Service Bus also provides default security groups for backwards compatibility. These groups are each in one of the legacy security roles that have been granted administrative privileges. Table 11-1 describes the legacy groups and their roles.

Table 11-1 Oracle Service Bus 11g Groups

Group	Role
IntegrationAdministrators	IntegrationAdmin
IntegrationDeployers	IntegrationDeployer
IntegrationOperators	IntegrationOperator
IntegrationMonitors	IntegrationMonitor

11.1.4 Access Control Policies

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 12:00 PM on weekdays.

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.

A message-level access control policy applies a security check when a client attempts to invoke a proxy service with message-level security. You can create a message-level access control policy in the following cases:

For proxy services that are active Web Service Security intermediaries
For proxy services that have message level custom authentication

Only users who are listed in the message-level policy are allowed to invoke the operation.

11.1.5 Security Configuration Data and Sessions

Users, groups, and roles are persisted in security providers, which are not governed by Service Bus sessions. Therefore, you can create or modify this data using the WebLogic Service Administration Console or Fusion Middleware Control when you are in or out of a session. Any additions or modifications to this data take effect immediately and are available to all sessions. If you discard a session in which you added or modified the data, the security data is not discarded.

Access control policies are persisted in authorization providers. And there is a reference to them in the Service Bus repository. Access control policies are managed within a design session and not outside the session. Because the changes are made within a session, you can commit or discard the changes as with other resources.

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

11.2 Security Configuration During Exports

You cannot export users, groups, or roles when you export a configuration because these objects are located in security provider stores.

You must create these objects again when you import the exported configuration or use WebLogic Server tools (if available) to export and import them.

11.3 Configuring Oracle Service Bus Administrative Security

You create and modify users and groups, and then assign roles to those users or groups, using Fusion Middleware Control.

You can assign roles directly to individual users or you can assign users to custom groups to grant the same permissions to multiple users. Any modifications to user and group data take effect immediately and are available to all sessions.

You can also create users and groups, and add users to groups, using the WebLogic Server Administration Console; but application roles are assigned using Fusion Middleware Control. This document describes using Fusion Middleware Control. For more information about WebLogic Server Administration Console security, see "Manage users and groups" in Oracle WebLogic Server Administration Console Online Help.

11.3.1 How to Grant Permissions to Individual Users

To grant permissions to individual users:

Log in to Fusion Middleware Control with a user account that is in the Administrator application role.
Create users, and add the users to the Monitors group. See Creating Oracle Service Bus Users and Granting Access Permissions By Assigning Users to Groups.
Assign the new users to one or more of the application roles. See Granting Permissions to Individual Users.
Optionally, grant individual permissions to users (not recommended). See Granting Permissions to Individual Users.

11.3.2 How to Grant Permissions to Users in User Groups

To grant permissions to users in user groups:

Log in to Fusion Middleware Control with a user account that is in the Administrator application role.
Create groups to which you can assign Service Bus users, and make them members of the Monitors parent group. See Creating Oracle Service Bus Groups.
Create users and add the users to the appropriate groups. See Creating Oracle Service Bus Users and Granting Access Permissions By Assigning Users to Groups.
Assign the new groups to one or more of the application roles. See Granting Permissions to Groups.
Optionally, grant individual permissions to groups (not recommended). See Granting Permissions to Groups.

11.3.3 Creating Oracle Service Bus Groups

You create Service Bus groups using Fusion Middleware Control. All Service Bus groups must be added to the Monitors parent group.

Caution:

Group names are case insensitive, but must be unique. Do not use any of the following characters in user names: < > \ , = / ( ) + ? [ ]

Do not begin a user name with a pound sign (#) or double quotes ("). Creating a user with any of the preceding invalid characters can corrupt the WebLogic domain.

To create a Service Bus group:

Log in to Fusion Middleware Control with a user account that has administrator privileges.
In the Target Navigator, expand WebLogic Domain, and right-click the name of your domain.
Point to Security and select Users and Groups. Click the Groups tab.
Above the Groups table click Create.
In the Name field of the Create New Group dialog, enter the name of the group.
Optionally, in the Description field, enter a short description to help identify the group.
In the Provider drop-down list, select the authentication provider for the group.
Click Create.

The group name appears in the Group table.
In the Groups table, click the name of the group you just added, and then click the Membership tab.
In the Parent Groups Available list, select Monitors and then click the right arrow to add it to the Chosen list.
Click Save.
To assign application roles to the group, continue to Granting Permissions to Groups.

11.3.4 Granting Permissions to Groups

Once you create a group, you can define the Service Bus permissions to grant the group's users by assigning the group to application roles using Fusion Middleware Control. You can either grant bulk permissions to a group by assigning it to a role, or you can grant individual permissions to a group.

11.3.4.1 Assigning a Group to an Application Role

To assign a group to an application role:

Log in to Fusion Middleware Control as a user with administrator privileges.
In the Target Navigator, expand SOA and click service-bus.
In the Service Bus menu, select Security > Application Roles.
In the Application Stripe field of the Application Roles page, select Service_Bus_Console.
Click the Search icon (the blue arrow) to view the Service Bus application roles.
In the roles table, select the role you want to assign the group to, and click Edit.

For information about the permissions granted by each role, see Application Security Roles.
Above the Members table on the Edit Application Role page, click Add.
On the Add Principal dialog, do the following:
1. In the Type field, select Group.
2. Optionally, enter all or part of the group's principal or display name. You can specify a search string that the name starts with or that it includes.
3. Click Search.
4. In the search results list, click the name of the group to assign the role to and click OK.
5. On the Edit Application Role page, click OK.

11.3.4.2 Granting Individual Permissions to a Group

While you can grant permissions to a group individually, this is not the recommended method. Whenever possible, you should grant permissions by assigning the group to a role, as described in Assigning a Group to an Application Role.

To grant individual permissions to a group:

Log in to Fusion Middleware Control as a user with administrator privileges.
In the Target Navigator, expand SOA and click service-bus.
In the Service Bus menu, select Security > Application Policies.
In the Application Stripe field of the Application Policies page, select Service_Bus_Console.

The Create button is activated.
Click Create above the table.
In the Grantee section of the Create Application Grant page, click Add.
On the Add Principal dialog, do the following:
1. In the Type field, select Group.
2. Optionally, enter all or part of the group's principal or display name. You can specify a search string that the name starts with or that it includes.
3. Click Search.
4. In the search results list, click the name of the group to assign to the role and click OK.
In the Permissions section of the Create Application Grant window, click Add.
Do the following on the Add Permission dialog:
1. To search by Java class, select Permissions and then select oracle.soa.osb.console.common.permissions.OSBPermission in the Permission Class field.
2. To search by resource, select Resource Types and then select OSBPermission in the Resource Type field.
3. Optionally enter all or part of the resource name.
4. Click Search.
5. In the search results list, click the name of the permission you want to grant and click Continue.
  
  For information about Service Bus permissions, see Application Security Roles.
6. In the Permission Actions field, select only those actions you want to grant. If you searched by Java class, enter permission actions in a comma-delimited list; for example, enter create,delete,edit.
  
  Available permissions vary depending on your selection on the previous page.
7. Click Select.
  
  The new permissions appears in the Permissions table.
When you are done granting permissions, click OK on the Create Application Grant window.

11.3.5 Creating Oracle Service Bus Users

You create Service Bus groups using Fusion Middleware Control. All Service Bus users must be added to the Monitors parent group or to a group that is a member of the Monitors parent group.

Caution:

Do not use any of the following characters in user names: ; , + = \ (double back-slashes can be used; for example smith\\). Do not begin a user name with a pound sign (#) or double quotes ("). Creating a user with any of the preceding invalid characters can corrupt the WebLogic domain.

To create Service Bus users:

Log in to Fusion Middleware Control as a user with administrator privileges.
In the Target Navigator, expand WebLogic Domain, and right-click the name of your domain.
Point to Security and select Users and Groups. Click the Users tab.
Above the Users table click Create.
In the Name field of the Create New User dialog enter the login ID of the user.
Optionally, in the Description field, enter a short description to help identify the user.
In the Provider drop-down list, select the authentication provider for the user.
In the Password field, enter a password for the user. The password must be 8 characters or more.
Re-enter the password for the user in the Confirm Password field.
Click Create to save your changes.

The user name appears in the User table.
Do one of the following:
- If you plan to grant access permissions to users by assigning them to groups, continue to Granting Access Permissions By Assigning Users to Groups.
- If you plan to grant access permissions to the users individually, continue to Granting Permissions to Individual Users.

11.3.6 Granting Access Permissions By Assigning Users to Groups

If you use groups to assign the same permissions to many users, you add the users to the appropriate groups to grant permissions. These users do not need to be members of the Monitors group because the group should already be a member.

To add Service Bus users to groups:

Log in to Fusion Middleware Control as a user with administrator privileges.
In the Target Navigator, expand WebLogic Domain, and right-click the name of your domain.
Point to Security and select Users and Groups. Click the Users tab.
In the Users table, click the name of the user you just added, and then click the Groups tab.
Select the groups to which you want to add the user and then click the right arrow to add them to the Chosen list.
Click Save when you are done adding groups.

11.3.7 Granting Permissions to Individual Users

Once you create a user in the WebLogic Server Administration Console, you can grant them access permissions by assigning them to an application role in Fusion Middleware Control. You can also assign permissions individually, but this is not recommended.

11.3.7.1 Assigning a User to an Application Role

To assign a user to an application role:

Log in to Fusion Middleware Control as a user with Administrator privileges.
Assign the user to the Monitors group as described in Granting Access Permissions By Assigning Users to Groups.
In the Target Navigator, expand SOA and click service-bus.
In the Service Bus menu, select Security > Application Roles.
In the Application Stripe field of the Application Roles page, select Service_Bus_Console.
Click the Search icon (the blue arrow) to view the Service Bus application roles.
In the roles table, select the role to which you want to add the user and click Edit.

For information about the permissions granted by each role, see Application Security Roles.
Above the Members table on the Edit Application Role page, click Add.
On the Add Principal dialog, do the following:
1. In the Type field, select User.
2. Optionally, enter all or part of the user's principal and display names. You can specify a search string that the name starts with or that it includes.
3. Click Search.
4. In the search results list, click the name of the user to assign to the role and click OK.
5. On the Edit Application Role page, click OK.

11.3.7.2 Granting Individual Permissions to a User

While you can grant permissions to a user individually, this is not the recommended method. Whenever possible, you should grant permissions by assigning the user to a role, as described in Assigning a User to an Application Role. If you assign roles or permissions directly to users, you must also add the users to the Monitors group.

To grant individual permissions to a user:

Log in to Fusion Middleware Control as a user with administrator privileges.
In the Target Navigator, expand SOA and click service-bus.
In the Service Bus menu, select Security > Application Policies.
In the Application Stripe field of the Application Policies page, select Service_Bus_Console.

The Create button is activated.
Click Create above the table.
In the Grantee section of the Create Application Grant page, click Add.
On the Add Principal dialog, do the following:
1. In the Type field, select User.
2. Optionally, enter all or part of the user's principal or display name. You can specify a search string that the name starts with or that it includes.
3. Click Search.
4. In the search results list, click the name of the user to grant permissions to and click OK.
In the Permissions section of the Create Application Grant window, click Add.
Do the following on the Add Permission dialog:
1. To search by Java class, select Permissions and then select oracle.soa.osb.console.common.permissions.OSBPermission in the Permission Class field.
2. To search by resource, select Resource Types and then select OSBPermission in the Resource Type field.
3. Optionally enter all or part of the resource name.
4. Click Search.
5. In the search results list, click the name of the permission you want to grant and click Continue.
  
  For information about Service Bus permissions, see Application Security Roles.
6. In the Permission Actions field, select only those actions you want to grant. If you searched by Java class, enter permission actions in a comma-delimited list; for example, enter create,delete,edit.
  
  Available permissions vary depending on your selection on the previous page.
7. Click Select.
  
  The new permissions appears in the Permissions table.
When you are done granting permissions, click OK on the Create Application Grant window.

11.4 Securing Oracle Service Bus in a Production Environment

To prepare a Service Bus installation for production, you must pay special attention to your security needs. These guidelines are recommended strategies for securing Service Bus in a production environment.

Read and follow the guidelines in Securing a Production Environment for Oracle WebLogic Server.
Create user accounts for the Service Bus administrators and assign them to one or more of the groups you create or to application roles individually.
In your file system, configure access control to the directory that contains Service Bus configuration data. This is the config directory under the domain root. For example:
```
C:\oracle\user_projects\domains\servicebus_domain\config\osb
```
In your file system, configure access control to the directories used by the FTP, SFTP, file, and email transports.
If necessary, configure access control to the JMS resources used by your Service Bus installation.

11.4.1 Undeploying the Service Bus (SB) Resource

Service Bus provides a resource servlet (MW_HOME/OSB_ORACLE_HOME/lib/apps/sbresourceWar/sbresource.war) that is used to expose the resources registered in Service Bus. The resources registered with Service Bus include the following:

WSDL (a WSDL file registered as a resource in Service Bus)
WADL (a WADL file registered as a resource in Service Bus)
Schema
MFL
WS-Policy
WSDL (an effective WSDL with resolved policies and port information for a proxy service; this effective WSDL is available if the proxy service was created using a WSDL file).

However, this servlet provides anonymous HTTP access to metadata, and as such it may be considered a security risk in some high-security environments.

If you do not want the Service Bus resources to be available anonymously via HTTP, you can set security roles on sbresources.war to control access to it, or completely undeploy the resource.

Note:

If you undeploy the SB resource you will no longer be able to use the UDDI subsystem.

11.4.2 Protection of Temporary Files With Streaming body Content

As described in "The Message Context Model" in Developing Services with Oracle Service Bus for processing message content, you can specify that a Service Bus pipeline streams the content rather than loading it into memory. When you enable content streaming, you specify whether to buffer the streamed content to memory or a disk file as an intermediate step during the processing of the message.

If you use these temporary disk files, you should protect them. To lock-down your Service Bus domain, set the com.bea.wli.sb.context.tmpdir Java system property to specify where these temporary files will be written. Make sure this directory exists and has the right set of access permissions. For more information see the file access permission and file system recommendations in Securing a Production Environment for Oracle WebLogic Server.

11.4.3 Protecting Against Denial of Service Attacks on the Oracle Service Bus Console

In a production environment, the Oracle Service Bus Console should not be accessible to users other than administrators. A denial of service attack can take the form of a high volume of requests from a single source or new connections being made to the server once resource constraints have reached a certain point. Following are suggestions for protecting against denial of service attacks on the Oracle Service Bus Console.

In a production environment, make sure the Admin Server, which is the server the Oracle Service Bus Console runs on, is never made public. Only Managed Servers should be available to callers.
Instead of using the default Work Manager for the Oracle Service Bus Console, configure and use a different Work Manager that sets a default limit on the number of users that can access the Oracle Service Bus Console web application (max-threads-constraint).

For information about Work Managers, see "Using Work Managers to Optimize Scheduled Work" in Administering Server Environments for Oracle WebLogic Server.