- 23 september 2013
- Posted by: Ebicus
- Categories: Business Intelligence, Security
This article provides information on how to apply an organization’s security definition and to ensure this definition will be maintained over a period of time. By using this approach errors will be avoided and less time will be spend on implementing the security definition. The target audience of this article mostly are implementation consultants, security officers and system administrators.
Business intelligence encloses the use of integrated organizational data sources for making strategic business decisions. One of the ‘hot topics’ in the process of implementing BI is the subject of security: Who is allowed to access what part of the organizational data?
One of the tools in controlling the organizational security is the organization’s security definition. A security definition encompasses a description of allowed organizational roles specified for individuals. This article will not discuss the details or contents of a security definition, but will provide a technical approach in order to apply and maintain the definition within Oracle BI.
Out of the box, Oracle Business Intelligence (BI) comes with four pre-defined application roles, as shown in the Oracle Enterprise Manager Fusion Middleware Control in figure 1.
Figure 1: Oracle Enterprise Manager Fusion Middleware Control: Application Roles.
Three of those roles can be used to provide permissions to users, groups or roles. These roles are:
- Users granted this role are allowed to manage responsibilities, edit repositories, etc.
- Users granted this role are allowed to create reports
- Users granted this role are allowed to access reports
The BIAuthor role inherits permissions from the BIConsumer role. The BIAdministrator role inherits permissions from theBIAuthor role. These dependencies are depicted in figure 2.
Figure 2: Out of the box Oracle BI security: Groups, roles, permissions.
Organizational security definition export
This article builds on the standard Oracle BI roles. Organizational roles can be created based on one of these standard roles. Users, provided by e.g. an Active Directory provider, can be granted standard roles or ‘custom’ organizational roles.
Furthermore this article assumes that the organization’s security definition has been defined and contains roles and users, and can be exported to two files:
- This file contains ‘custom’ organizational roles, and information on which standard role this custom role is based on.
- This file contains users, based on the organization’s active directory, and information on which role the users should be granted
The organizational security definition, exported to the roles and users files, will be the input for the technical solution provided in this article.
Applying and maintaining the security definition
Applying and maintaining the security definition by using the Oracle Enterprise Manager Fusion Middleware Control can be time-consuming and even more important: an error can result in major technical / organizational consequences. This article presents an automatable approach for applying and maintaining the security definition.
- Two files: roles and users, as described before. Figure 3 and 4 present an example.
Figure 3: Example of the users file.
Figure 4: Example of the users file.
Connect to target environment
- Use a batch-file for starting WLST and calling a Python script.
WLST stands for Weblogic Scripting Tool and is able to use a Python script for creating, configuring and managing Weblogic Server domains. The WLST security commands have been described in the Oracle Fusion Middleware Weblogic Scripting Tool Command Reference, see references.
The first step is to connect to the server on which the security definition should be applied or maintained:
connect(WLS_USER, WLS_PW, WLS_URL);
This connect string should be placed in the Python script. As shown, variables can be used to pass the credentials and target environment.
Part 1: Remove custom roles
Part 1 removes all of the custom organizational roles. First all of the available roles should be requested, this is possible by using:
Filter the standard Oracle BI roles from the output and create a list of roles that should be removed. Then remove each of these roles:
Part 2: Remove non-standard users from standard roles
This part will ‘clean’ the standard Oracle BI roles. For example, out of the box, the only ‘element’ added to the BIAdministrator role is ‘BIAdministrators’, all other ‘elements’ added to this role should be removed. This part ensures that users who are not granted the BIAdministrators role in the organizational security definition, will be removed from this role. For this step, the ‘revokeAppRole’ command can be used:
Part 3: Create custom organizational roles
At this point, the Oracle BI environment will be ‘clean’. No other roles than the out of the box roles exist, and the standard roles include no other ‘elements’ (users / groups / roles) than the out of the box situation.
New organizational roles can be created by importing information from the roles file and using the command ‘createAppRole’:
Then the new role can be granted another role by using the ‘grantAppRole’ command:
Part 4: Grant users to roles
All the custom organizational roles, as well as the standard Oracle BI roles, exist. By importing information from the users file, the users can be granted the role as defined by the organization’s security definition, using the ‘grantAppRole’ command:
It is advised to implement an error detection mechanism in case one of the above actions does not succeed. Errors should be communicated clearly to prevent incomplete organizational security definitions being deployed on the Oracle BI environment.
This automated approach will make sure the organization’s security definition has been adjusted correctly. It is not just the prevention of errors that has been gained, imagine also the amount of time that has been ‘won’. Granting 300 users to 10 different roles, and checking if all of the roles have been correctly ‘filled’, by using Oracle Enterprise Manager Fusion Middleware Control, takes a couple of hours. Using this automated approach takes a couple of seconds.
It is advised that the result of the automated approach has been logged. Each of the actions, as well as the errors, should be written to a log file, to be able to check the implementation afterwards. An example is shown in figure 5.
Figure 5: Example of a log produced by the automated security implementation approach.
Introduction to security in Oracle Business Intelligence: http://docs.oracle.com/cd/E14571_01/bi.1111/e10543/intromartin.htm
Oracle Fusion Middleware Weblogic Scripting Tool Command Reference: http://docs.oracle.com/cd/E14571_01/web.1111/e13813/custom_infra_security.htm#WLSTC1394