| Oracle® Real-Time Decisions Installation and Administration Guide Version 3.0.0.1 Part Number E13856-02 |
|
|
View PDF |
| Oracle® Real-Time Decisions Installation and Administration Guide Version 3.0.0.1 Part Number E13856-02 |
|
|
View PDF |
Oracle RTD has three different levels of security: cluster-wide security, Inline Service (application-level) security, and an additional level of security for perspectives (views) in Decision Center. Also, each data source has an additional level of security, based on the database user name and password.
The setup of each Oracle RTD security level can be summarized as follows:
Cluster-wide security is configured using the SecurityManager MBean. You can use JConsole to set permission codes for Oracle RTD users.
Inline Service security is configured on individual Inline Services.
Perspective-level security is configured in Decision Studio.
The sections that follow describe the setup and usage of each of the security levels in detail.
It is important to configure all three levels of security. Otherwise, you may run into problems. For example, if a user has cluster-wide permission to deploy in Decision Studio, but does not have the correct permissions to do so at the Inline Service and perspective level, the user will not be able to view and edit the Inline Service.
This chapter contains the following topics:
There are three types of permission used in Oracle RTD:
Cluster permissions
Inline Service permissions
Decision Center Perspective permissions
This section consists of the following topics:
Cluster permissions are global permissions that apply to all Oracle RTD instances of the Oracle RTD cluster.
Oracle RTD cluster permissions are granted to an individual JEE Servlet Role through the JMX MBean whose JConsole path is OracleRTD > SDManagement > Security Manager.
| Target Cluster Permission | Description | Implied Permissions, Automatically Granted when Granting the Target Permission |
|---|---|---|
|
Administrator |
Authorizes all Oracle RTD activities, including the ability to work with Inline Services to which no Inline Service permissions have been assigned. |
Open Service Open Service For Reading Deploy Service From Studio Download Service |
|
Open Service |
Authorizes a person to use Decision Center to open an Inline Service for editing, if the Inline Service permission Open Service has also been granted to the person. |
Open Service For Reading |
|
Open Service For Reading |
Authorizes a person to use Decision Center to open an Inline Service for viewing, if the Inline Service permission Open Service For Reading has also been granted to the person. |
N/A |
|
Deploy Service From Studio |
Authorizes a person to deploy a new Inline Service from Decision Studio, or to deploy a new version of an existing Inline Service, if the new Inline Service and the existing version (if any) have both been granted the Inline Service permission Deploy Service From Studio. |
Open Service Open Service For Reading |
|
Download Service |
Authorizes a person to use Decision Studio to download an Inline Service from a server if the Inline Service has been granted the Inline Service permission Download Service. |
Open Service For Reading |
Inline Service permissions are associated with a specific Inline Service. These are granted to an individual Servlet Role through Decision Studio's Application/Permissions tab.
Table 7-2 Inline Service Permissions
| Target Permission | Description | Implied Permissions, Automatically Granted when Granting the Target Permission |
|---|---|---|
|
Open Service |
When accompanied by the corresponding cluster permission, authorizes a person to use Decision Center to open an Inline Service for editing. |
Open Service For Reading |
|
Open Service For Reading |
When accompanied by the corresponding cluster permission, authorizes a person to use Decision Center to open an Inline Service for viewing. |
N/A |
|
Deploy Service From Studio |
When accompanied by the corresponding cluster permission, authorizes a person to deploy the Inline Service from Decision Studio. If redeploying an existing Inline Service, the existing Inline Service must also have this permission. |
Open Service Open Service For Reading |
|
Download Service |
When accompanied by the corresponding cluster permission, authorizes a person to use Decision Studio to download the Inline Service from a server. |
Open Service For Reading |
Decision Center Perspective permissions are assigned through Decision Studio, to enable a Decision Center user to open the Inline Service using the specified perspective.
Table 7-3 lists the default Decision Center perspectives.
Table 7-3 Decision Center Perspectives
| Perspective | Description |
|---|---|
|
Explore |
Presents a user interface suitable for viewing attributes and performance reports for an Inline Service, but not for editing. |
|
Design |
Presents a user interface that includes all of the Explore perspective, and also the ability to edit some aspects of the Inline Service. |
|
At a Glance |
Presents an abbreviated user interface suitable for viewing a subset of the attributes and performance reports that are available through the Explore perspective. |
This section describes the JEE Servlet Roles declared in Oracle RTD's deployment descriptors, out of the box, and the Oracle RTD permissions that Oracle RTD automatically assigns to them.
These roles are not created by Oracle RTD, but merely referenced by Oracle RTD's deployment descriptors. To actually create them, the application server's administration console would typically be used to first create user groups, and then to define roles in terms of the user groups, as described in separate sections in this chapter.
This section consists of the following topics:
This section describes the default assignments of cluster permissions to standard Oracle RTD roles.
You can use Oracle RTD's Security Manager MBean to change these assignments, but this is not recommended.
Note:
There is an MBean operation that reverts to this default assignment of cluster permissions, namely, OracleRTD > SDManagement > Security Manager: revertToStandardPermissions().Table 7-4 Standard Oracle RTD Roles
| Role | Default Cluster Permissions | Description (with references to example Inline Service ILS_X) |
|---|---|---|
|
RTDUsers |
None |
This role corresponds to all authenticated users. Requests sent to any Decision Center pages or web services must be in this role to be granted access by the JEE container. Because no permissions are assigned to this role, Oracle RTD would subsequently reject the request when it checks for required permissions, unless the user is also in some other role that has the required permissions. |
|
RTDAdministrators |
Administrator |
This role is allowed to do anything. |
|
RTDDecisionCenterEditors |
Open Service |
This role may use Decision Center to open Inline Service ILS_X for editing, if ILS_X's Application/Permissions tab in Decision Studio grants the Open Service permission to this role. |
|
RTDDecisionCenterUsers |
Open Service For Reading |
This role may use Decision Center to open Inline Service ILS_X for read-only viewing, if ILS_X's Application/Permissions tab in Decision Studio grants the Open Service For Reading permission to this role. |
|
RTDStudioDeployers |
Deploy Service From Studio Open Service |
This role may use Decision Studio to deploy Inline Service ILS_X to a server if ILS_X's Application/Permissions tab in Decision Studio grants the Deploy Service From Studio permission, and an existing instance of ILS_X has not been deployed that does not have this permission. This role may use Decision Center to open Inline Service ILS_X for editing, if ILS_X's Application/Permissions tab in Decision Studio grants the Open Service permission to this role. |
|
RTDStudioDownloaders |
Download Service Open Service For Reading |
This role may use Decision Studio to download Inline Service ILS_X from a server if ILS_X's Application/Permissions tab in Decision Studio granted the Download Service permission to this role before ILS_X was deployed. This role may use Decision Center to open Inline Service ILS_X for read-only viewing if ILS_X's Application/Permissions tab in Decision Studio grants the Open Service For Reading permission to this role. |
|
RTDBatchAdministrators |
None |
This role may execute any methods of the BatchManager web service. No cluster permissions are associated with this role. |
|
RTDChoiceEditors |
None |
This role may execute any methods of the ExternalChoice web service, and may access Decision Center's URLs serving requests to edit an external rule or external choice. No cluster permissions are associated with this role. |
By default, a new Inline Service has a number of Inline Service permissions assigned to the standard Oracle RTD roles.
Table 7-5 shows the default Inline Service permissions assigned to the standard RTD roles.
Table 7-5 Default Inline Service Permissions Assigned to Standard Oracle RTD Roles
| Standard Role | Inline Service Permissions |
|---|---|
|
RTDDecisionCenterEditors |
Open Service Open Service for Reading |
|
RTDDecisionCenterEditors |
Open Service Open Service for Reading |
|
RTDDecisionCenterUsers |
Open Service |
|
RTDStudioDeployers |
Deploy Service from Studio Open Service Open Service for Reading |
|
RTDStudioDownloaders |
Download Service Open Service for Reading |
When a new Inline Service is created, its Decision Center perspectives will by default be accessible to the standard Oracle RTD roles, as shown in Table 7-6.
Table 7-6 Decision Center Perspective Permissions
| Perspective | Granted to Role |
|---|---|
|
Explore |
RTDDecisionCenterUsers RTDDecisionCenterEditors RTDStudioDeployers RTDStudioDownloaders |
|
Design |
RTDDecisionCenterEditors RTDStudioDeployers |
|
At a Glance |
RTDDecisionCenterUsers RTDDecisionCenterEditors RTDStudioDeployers RTDStudioDownloaders |
If an enterprise needs to assign permissions to more or different groups of users than defined by Oracle RTD's standard roles, the enterprise can create new security roles corresponding to the specialized user groups, declare the new roles in Oracle RTD deployment descriptors, and redeploy Oracle RTD before granting the Cluster or Inline Service permissions to the new role as described in previous sections.
The details of creating the roles and of declaring them in Oracle RTD's deployment descriptors are vendor-specific, and are described in the application server specific chapters.
As an overview of the process, assume that the enterprise has already defined its first Inline Service, ILS1, and that ILS1 is managed by users in standard Oracle RTD roles. Now, assume that the enterprise has the following extra requirements:
To introduce a new Inline Service, ILS2, to be managed by users in the groups ILS2DevelopersGroup and ILS2UsersGroup
Developers for ILS2 will be allowed to read the contents of ILS1, but not to modify it
Developers of ILS1 will have no access to ILS2, not even for reading
The following is an overview of the steps for the extra requirements:
Use the vendor's administration console to create user groups, ILS2DevelopersGroup and ILS2UsersGroup.
Use the vendor's administration console to put the appropriate users into the two groups.
Use the vendor's administration console to create two JEE Servlet security roles, ILS2Developers and ILS2Users, so that, in terms of the new groups:
Any user in ILS2DevelopersGroup is in the ILS2Developers role
Any user in ILS2UsersGroup is in the ILS2Users role
Declare references to the new security roles by updating Oracle RTD's deployment descriptors in two web.xml files:
RTD.ear > ui.war > web-inf/web.xml
RTD.ear > soap.war > web-inf/web.xml
The notation here for the web.xml paths signifies that both web.xml files are in directories named web-inf, and that web-inf is inside web archives named ui.war and soap.war. Similarly, the web archives are inside an enterprise archive named RTD.ear.
Depending on the installation, which varies for different application servers, the ear and war files may be archive files, or they may have been expanded into the file system.
Redeploy Oracle RTD.
Use JConsole to assign cluster permissions to the new roles, as follows:
Deploy Service from Studio to the role ILS2Developers.
This permission is necessary to allow Inline Service deployment, but insufficient without corresponding Inline Service permissions.
Open Service to the role ILS2Users.
This permission is necessary to allow users to open the Inline Service in Decision Center, but insufficient without corresponding Inline Service permissions
Use Decision Studio to open ILS1 and ILS2, to assign these Inline Service permissions and Decision Center Perspective permissions, as shown in Table 7-7.
Table 7-7 Inline Service and Decision Center Perspective Permissions
| Inline Service | Role | Permissions | Perspectives |
|---|---|---|---|
|
ILS1 |
ILS2Developers |
Open Service for Reading |
Explore, At a Glance |
|
ILS2 |
ILS2Developers |
Deploy Service from Studio Open Service Open Service for Reading |
Explore, Design, At a Glance |
|
ILS2 |
ILS2Users |
Open Service Open Service for Reading |
Explore, Design, At a Glance |
Use Decision Studio to redeploy the two Inline Services, ILS1 and ILS2.
Section 7.2, "Standard Oracle RTD Roles" and its component subsections describe how default permissions are already assigned to the standard Oracle RTD roles. This section describes how to assign other permissions, such as are required for custom roles, where there are no default permissions.
This section consists of the following topics:
Cluster permissions are granted through JMX, using the MBean whose path is OracleRTD > SDManagement > Security Manager. For more details, see Section 15.5, "Oracle Real-Time Decisions Security Management."
The listPermissionCodes operation provides a list of permission codes that can be entered when assigning permissions.
For example:
0 - Administrator
1 - Open Service
2 - Open Service for Reading
3 - Deploy Service from Studio
4 - Download Service
The assignPermission operation accepts two arguments, the name of a role, and the code for the permission to be granted to that role.
For example, Role: ILS2Developers and Code: 3.
The listDirectPermissions operation shows all the cluster permissions that have been granted to a role, including permissions granted directly by the assignPermission operation, and any implied permissions.
For example, the permissions granted to the role, ILS2Developers, as a consequence of granting permission code 3 through the assignPermission operation, may appear as:
Deploy Service from Studio
Open Service
Open Service for Reading
Inline Service permissions are granted through Decision Studio, in the Permissions tab of the Application object. For more details, see the section "Setting Inline Service Permissions" in Oracle Real-Time Decisions Platform Developer's Guide.
For example, in the CrossSell Inline Service, the RTDStudioDeployers role has been granted the Deploy Service from Studio permission. The Open Service and Open Service for Reading permissions are also marked as granted because these are implied by Deploy Service from Studio. In Decision Studio, when granting a permission, the name of the role can be selected from a dropdown list of roles to which cluster permissions have already been assigned. If the intended role has not been yet assigned any cluster permissions, you can manually enter the name in Decision Studio, but the permission will have no value until the corresponding cluster permission has been granted.
To enable a specific perspective for an Inline Service in Decision Studio, select the perspective in the Decision Center Perspectives folder, then right-click it and select its Properties. You grant access to the perspective for a given role by adding the role to the list of roles that are allowed to use the perspective. For more details, see the section "About Decision Center Perspectives" in Oracle Real-Time Decisions Platform Developer's Guide.
As an aid to understanding which Oracle RTD roles have been assigned to a specific user, Oracle RTD provides a resource that is installed as part of Decision Center. If this feature has been enabled, then accessing http://host:port/ui/hello.jsp from an HTTP browser will cause Oracle RTD's login page to be displayed. If the user is not already logged in, then a simple page is presented that displays the roles of the user, as in the following example:
Hello, phil
You are in these RTD Roles: [RTDAdministrators, RTDUsers]
The roles listed here are a subset of all the roles to which any cluster permissions have assigned in Oracle RTD's Security Manager MBean. The total list of possible Oracle RTD roles is the set that is rendered by the Security Manager MBean operation, listEveryoneHavingPermissions.
Note:
To avoid any concern that displaying a user's roles might be a privacy issue,
hello.jsp will not display any roles unless this feature is explicitly enabled by setting the following system property for the JVM, in a manner specific to the application server:
rtd.showRolesInHello.jsp = true
This section shows the tasks required of existing Oracle RTD customers upgrading from previous releases to 3.0, and contains the following topics:
Section 7.6.1, "Migrating Oracle RTD Users and Groups to Enterprise Identity Store"
Section 7.6.2, "Defining Standard Security Roles in JEE Server"
Section 7.6.3, "Defining Custom Security Roles in JEE Server"
Section 7.6.5, "Assigning Inline Service Permissions to Roles"
Section 7.6.6, "Assigning Decision Center Perspective Permissions to Roles"
The users and groups that had been defined in Oracle RTD's internal identity store should generally be moved to the JEE server's identity store. If the JEE server is integrated into an enterprise-wide identity store, this store will typically already include the users that had previously been entered separately into Oracle RTD's internal identity store.
This process is different for each type of application server, using the vendor's administration console. Examples are shown in the appropriate application server specific chapters.
If the existing installation assigns permissions to users or groups that are more fine-grained than the Oracle RTD's standard roles, then additional enterprise roles must be defined so that permissions can be assigned to them.
For example, if there were user groups named ILS2-AdminGroup and ILS2-UserGroup, two new roles must be defined, and cluster permissions assigned, as follows:
ILS2Developers: true for users in ILS2-AdminGroup
ILS2Users: true for users in ILS2-UserGroup
For the custom roles defined in the previous section, declare references to each of them in Oracle RTD's deployment descriptors, then redeploy Oracle RTD:
RTD.ear > ui.war > web-inf/web.xml
RTD.ear > soap.war > web-inf/web.xml
Use Decision Studio to change any existing Inline Service permission assignments to refer to the JEE Servlet roles managed by the application server, instead of to the user groups previously managed internally by Oracle RTD.
Use Decision Studio to change any existing Decision Center Perspective permission assignments to refer to the JEE Servlet roles managed by the application server, instead of to the user groups previously managed internally by Oracle RTD.
|
 Copyright © 2003, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|