This chapter includes the following sections:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
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.
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.
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.
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.
To grant permissions to individual users:
To grant permissions to users in user 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:
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.
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:
In the Type field, select Group.
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.
Click Search.
In the search results list, click the name of the group to assign the role to and click OK.
On the Edit Application Role page, click OK.
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:
In the Type field, select Group.
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.
Click Search.
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:
To search by Java class, select Permissions and then select oracle.soa.osb.console.common.permissions.OSBPermission
in the Permission Class field.
To search by resource, select Resource Types and then select OSBPermission in the Resource Type field.
Optionally enter all or part of the resource name.
Click Search.
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.
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.
Click Select.
The new permissions appears in the Permissions table.
When you are done granting permissions, click OK on the Create Application Grant window.
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:
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:
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.
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:
In the Type field, select User.
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.
Click Search.
In the search results list, click the name of the user to assign to the role and click OK.
On the Edit Application Role page, click OK.
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:
In the Type field, select User.
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.
Click Search.
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:
To search by Java class, select Permissions and then select oracle.soa.osb.console.common.permissions.OSBPermission
in the Permission Class field.
To search by resource, select Resource Types and then select OSBPermission in the Resource Type field.
Optionally enter all or part of the resource name.
Click Search.
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.
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.
Click Select.
The new permissions appears in the Permissions table.
When you are done granting permissions, click OK on the Create Application Grant window.
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.
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.
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.
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.