In This Section:
Oracle Hyperion Enterprise Performance Management System Security Administration Guide
Oracle Hyperion Enterprise Performance Management System User and Role Security Guide
Essbase user management and security is provided through EPM System security, which uses Oracle's Hyperion® Shared Services to provide user management, user provisioning, and external authentication definition. Provisioning refers to the process of assigning roles and access permissions to users for Essbase applications.
When using the default deployment option, Essbase is deployed in EPM System security mode.
If you choose not to deploy Essbase in EPM System security mode, Essbase uses its own native security mode to manage security for Essbase applications, databases, and artifacts. There is no change in behavior for Essbase in native security mode, except when using native security mode with external authentication. See Continuing to Use Essbase in Native Security Mode.
To use EPM System security for Essbase deployments that are in Essbase native security mode, you must migrate any Essbase Server applications and any existing Essbase users and groups to Shared Services. See Migrating Essbase to EPM System Security.
When running Essbase in EPM System security mode, Essbase obtains user and group details (including user and group information and provisioning to Essbase applications) from Shared Services. Essbase no longer stores all users and groups in the Essbase security file (essbase.sec); therefore, an Essbase Administrator does not need to explicitly synchronize security between Essbase and Shared Services.
When a user logs on to Essbase, Essbase queries Shared Services for that user’s information. The privileges with which a user starts a session are preserved throughout the session, regardless of whether the user’s privileges are changed in Shared Services during the session.
A user or group is stored in the Essbase security file only under the following circumstances:
The user or group was not successfully migrated to Shared Services.
The user or group is assigned database calculation or filter access.
The user or group is specified in the query governor exclude list.
The user is the creator of an application or database.
The user has locked a database-related artifact.
The PERSISTUSERATLOGIN configuration setting is set to TRUE.
When a user logs on to Essbase, PERSISTUSERATLOGIN specifies whether to add the user to the essbase.sec file, if the user does not already exist in the file.
To remove users or groups from the Essbase security file without de-provisioning them from Shared Services, use the drop user or drop group MaxL statements with the from security_file grammar. Calculation and filter associations also are removed.
For display operations, Essbase queries Shared Services. See:
When migrating Essbase from Essbase native security to EPM System security, users that do not successfully migrate are retained in the Essbase security file.
If a user’s database permissions changed during migration to Shared Services, information is written to a text file named AccessModifiedUsers_n.txt, where n represents the sequence ID for the instance of Essbase that is registered with Shared Services. (The sequence ID is incremented each time Essbase is externalized.) This file, which is located in the ARBORPATH/bin directory, contains the following information:
The user’s name
Applications and databases to which the user has access
The user's access level for a specific database before migration to Shared Services
The user’s access level after migration to Shared Services, including access acquired through groups and other means
The user’s filter assignments
In Shared Services, if an Essbase application contains multiple databases, the databases must have the same user security access levels (however, users can have different calculation script and database filters assigned for databases within the same application). During migration to Shared Services, if a user has different access levels for two databases in the same application, the user is given the more restrictive access level for both databases.
When migrating Shared Services users with the option to have user passwords automatically generated, those user names and passwords are written to a text file named MigratedUsersPassword.txt, which is located in the ARBORPATH/bin directory. If the Administrator designated a specific password for the migrated users, the password is not listed in the file. This file is created when performing an upgrade or migration.
The following security issues must be addressed after migrating users to Shared Services or upgrading Essbase:
To log on to Essbase and access the Essbase agent, a user no longer must have the Server Access role on the global Essbase Server application. A user with any role (whether directly or indirectly provisioned) on an Essbase application can log on to Essbase and access the Essbase agent.
To prevent users who do not have a role on the global Essbase Server application from accessing the Essbase agent, you must manually modify users’ roles. Be sure to evaluate the roles that a user inherits from a group.
When a user logs on to Essbase, Essbase queries Shared Services for the user’s roles. The more roles that a user has, the longer it takes to complete the login process. To improve login performance, users should not be assigned unneeded roles.
Essbase no longer assigns the Application Manager role, which is unnecessary, to an Essbase Administrator when he creates an Essbase application. If, in your Essbase deployment, the Application Manager role is assigned to Essbase Administrators, you must manually remove the Application Manager role from the Essbase Administrators.
Also, an Essbase Administrator who has an Administrator role on the global Essbase Server application might be assigned application roles that are not needed. Essbase provides a migration utility that can remove the application roles for Essbase Administrators only.
The migration utility (which runs on 32-bit Windows only), identifies the users who are affected by both security issues. Additionally, if specified, the utility can correct the issue of Essbase Administrators having application roles.
To run the migration.bat file:
AdminUserName—Name of the Essbase Administrator who runs the migration utility
AdminUserPassword—The Essbase Administrator’s password
HSSServer—Hostname of the Shared Services Server
HSSPort—Port number of the Shared Services Server
EssbaseProjectName—The project name for the Essbase Server on which you want to run the migration utility
SavedToFile—When set to TRUE, specifies that the results of the migration script should be written to the following text files, which are located in the MigrationTools subdirectory:
EntitiesWithCubeRolesOnly.txt—Lists the users and groups that have application roles but do not have a role on the global Essbase Server application
EssbaseAdminsWithCubeRoles.txt—Lists the Essbase Administrators who have application roles
When set to FALSE (the default), the results are written to the screen.
Sample versions of these files are located in the MigrationTools subdirectory.
FixAdminUser—When set to TRUE, removes application roles from Essbase Administrators. When set to FALSE (the default), writes the names of Essbase Administrators, and the application roles assigned to them, to the screen.
AdminUserName = admin AdminUserPassword = password HSSServer = pant5 HSSPort = 58080 EssbaseProjectName = Analytic Servers:ALNG3:1 SavedToFile true FixAdminUser false
When running the utility for the first time against an Essbase Server, Oracle recommends setting SavedToFile to TRUE and FixAdminUser to FALSE so that you can view and verify the results. Then, you can set FixAdminUser to TRUE and run the utility again to remove application roles from Essbase Administrators.
Examples of Essbase roles are Administrator and Database Manager. All Essbase roles are specific to a Shared Services application (the permissions granted to the user by the role apply only to the specific application for which the role is assigned, and not to all applications).
Examples of Shared Services roles are Project Manager or Provisioning Manager. Most Shared Services roles are global (the role applies to all Shared Services applications). An exception is the Provisioning Manager role, which is specific to an application.
See the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.
In Shared Services Console, roles belonging to Essbase are grouped under the Essbase node; roles belonging to Essbase applications are grouped under the application nodes.
There is no concept of provisioning an Administration Services Administrator user role through Shared Services. When migrated, an Administration Services Administrator is assigned no roles in Shared Services.
Table 120 lists the user roles that are specific to Essbase and the Shared Services role of Provisioning Manager, which is application-specific. The table shows the corresponding tasks that each user can perform.
Table 120. Essbase and Shared Services User Roles and Tasks
|(A Shared Services role) Creates and manages projects within Shared Services.|
The Provisioning Manager role, which is a Shared Services application-specific role, is automatically assigned when you migrate Essbase Administrators (previously known as Supervisors). However, when you create an Essbase Administrator in Shared Services Console, you must manually assign the Provisioning Manager role. Users with the Provisioning Manager role can provision users and groups with roles for applications.
Shared Services artifacts include projects, applications, user roles, users, and groups. When you assign access to a user or group in Shared Services, you provision the user or group with a role for an application. See the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.
Shared Services and Essbase both use the term “application.” Essbase uses “application” to refer to a container for databases. Shared Services uses “application” to refer to an artifact for which you provision users. In this topic, “application” refers to a Shared Services application, unless an Essbase application is specifically stated. In most cases, an Essbase application maps to a Shared Services application, so the distinction is unnecessary.
For Essbase, migration is done at the Essbase Server level. When you migrate an Essbase Server to Shared Services, a Shared Services project is created for the Essbase Server. The project is named Essbase:machineName:EssbaseServer#, where machineName is the Essbase Server computer name and EssbaseServer# is the sequence number. The sequence number for the first Essbase Server that is migrated is 1. When migrating multiple Essbase Servers on the same computer, the sequence number is incremented by 1. Also, if you delete the security file and remigrate an Essbase Server, each successful migration creates a new server project with a new sequence number. You can delete unwanted projects in Shared Services Console.
An application named Essbase:machineName:EssbaseServer#, which is the same name as the Shared Services project. This application, which allows you to specify security at the Essbase Server level, is known as the global Essbase Server application. After migration, you can change the name of the global application and application project in Shared Services by using the alter system MaxL statement with the rename global registration name grammar. See the Oracle Essbase Technical Reference.
A Shared Services application for each Essbase application on the Essbase Server. In Shared Services, if an Essbase application contains multiple databases, the databases must have the same user security access levels. (However, users can have different calculation script and database filters assigned for databases within the same application. See Assigning Database Calculation and Filter Access in Shared Services.)
In the following illustration, the first instance of Essbase:JWARD:1 is the Shared Services project for the first Essbase Server migrated on JWARD. The second instance of Essbase:JWARD:1 is the global Essbase Server application.
Projects Essbase:JWARD:1 ASOsamp DMDemo Demo Essbase Servers:JWARD:1 Sampeast Sample Sample_U Samppart
After you have migrated to Shared Services, when you create an application and database in Essbase, a corresponding Shared Services application is created within the Essbase Server project, and the application is automatically registered with Shared Services.
When you migrate to Shared Services, all native Essbase users and groups that do not already exist in an external authentication directory are converted to native Shared Services users and groups in the native Shared Services user directory and are given equivalent roles. Externally authenticated users are registered with Shared Services but are still stored in their original authentication directory. See User and Group Migration.
After you have migrated to Shared Services, you must create and manage users and groups in Shared Services Console, or through the external user directory. See the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.
When users and groups are stored in an external authentication directory from any supported authentication provider, a user and group can have the same name on the same provider; however, two users or two groups can not have the same name on the same provider.
Shared Services supports aggregated groups, in which a parent group contains one or more subgroups. The subgroups inherit the roles of their parent group. For example, if a parent group is provisioned with the Essbase Administrator role, any subgroups (and users in the groups) inherit the Essbase Administrator role.
Shared Services Console provides a centralized UI where you can perform user management tasks for EPM System products. The Shared Services Console launches Essbase screens, which allow you to assign security access to database filters and calculation scripts. In EPM System security mode, you use Shared Services Console, MaxL, or the API to manage security. (Some restrictions exist when managing security using MaxL or the API. See the Oracle Essbase Technical Reference and the Oracle Essbase API Reference.) In Administration Services Console you can only view security information.
For information on assigning access to users and groups and viewing a report of users, groups, and provisioned roles for each application, see the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.
When you launch Shared Services Console from a browser, you log on as whichever user is appropriate. For example, you must log on as a Shared Services Administrator to provision an Essbase Administrator with the Directory Manager role, so that he or she can create and delete users.
To specify security at the Essbase Server level in EPM System security mode (for example, provisioning a user with the Provisioning Manager role for all Essbase applications on an Essbase Server), provision the user with the appropriate role for the global Essbase Server application; that is, the Shared Services application that represents the Essbase Server. See Essbase Projects, Applications, and Databases in Shared Services.
Figure 143, Shared Services Console Provisioning Panel shows the roles that are available for the Essbase Server named DTRIPATH-PC1 and the Demo application.
When you provision a user with the Essbase Administrator role, you must also manually provision the user with the Provisioning Manager role for the Essbase Server and for each Essbase application on the server. (When you migrate an Essbase Administrator, the Provisioning Manager role is automatically assigned.)
To specify security at the Essbase application level in EPM System security mode (for example, provisioning a user with the Database Manager role for the Sample application), provision the user with the appropriate role for the application.
When you provision a user with the Application Manager role, you must also manually provision the user with the Provisioning Manager role for the appropriate application. (When you migrate an Essbase Application Manager, the Provisioning Manager role is automatically assigned.)
You can set minimum permissions for an application, for example, if you want all users to have at least write access to all databases in an application. The default setting is None, meaning that no minimum permission is set; all users can access the application according to their roles.
After provisioning users for Essbase applications in Shared Services Console, you can assign more granular access permissions to users and groups for a specific Essbase application and database. For example, after assigning a user access to an application and assigning the user’s role for the application, you can assign an Essbase filter to the user, or assign the user access to a specific calculation script.
You must create the filters and calculation scripts in Essbase. See Controlling Access to Database Cells Using Security Filters.
When you select an Essbase application from Shared Services Console, you see a list of the users and groups provisioned to that application. You can select the users and groups to which you want to assign additional permissions. You then select the database to which a user or group needs access, and assign filter and calculation script access to selected users and groups. See the Shared Services Console online documentation.
To specify access permissions in Shared Services, use a tool:
When you assign database calculation and filter access, you automatically log on to Administration Services and Essbase as the Shared Services Console logged-in user. This user must be an Essbase Administrator, Application Manager, or Database Manager. The user must have the Provisioning Manager role for the appropriate applications.
Essbase and Planning have the concept of an application access type for Essbase and Planning users. For example, when an Essbase user is created using any Essbase administration tool, the user is automatically assigned the application access type “Essbase;” when a Planning user is created using the Planning interface, the user is automatically assigned the application access type “Planning.” A user’s application access type specifies whether the user has access to Essbase applications only, to Planning applications only, or to both.
In Shared Services Console, you can select a global Essbase Server application to see the list of users and groups provisioned to that application. See the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.
When you assign database calculation and filter access, you automatically log on to Administration Services and Essbase as the Shared Services Console logged-in user. This user must be a valid Essbase Administrator and must have the Provisioning Manager role for the appropriate applications.
If Essbase and Administration Services are in Essbase native security mode, you can migrate to EPM System security mode. For Essbase, migration is done at the Essbase Server level. After you have converted to EPM System security mode, you cannot convert back to Essbase native security mode.
Essbase Administration Server can run in EPM System security mode with Essbase Server running in Essbase native security mode. However, if any Essbase Server that you administer from Administration Services Console runs in EPM System security mode, Essbase Administration Server must also.
For Essbase Administration Server, if you ran Oracle's Hyperion Enterprise Performance Management System Configurator after installation and specified a Shared Services server and login, at that point, Essbase Administration Server is converted to EPM System security mode. You can view the Shared Services configuration information in the Essbase Administration Server properties window (Configuration tab). You can then choose to migrate Administration Services users to Shared Services.
To migrate Administration Services users or to remigrate any Essbase users and groups that failed migration, use a tool:
Before migrating users, groups, and applications to Shared Services, ensure that the NETDELAY and NETRETRYCOUNT configuration settings are high enough to allow the migration to complete. Set NETDELAY to at least 3 hours, possibly more, depending on the size of the security file. Return the settings to their original values after the migration is complete. Specify these settings in the client essbase.cfg file, which you place in the ARBORPATH/bin folder of the client computer from which you launch the migration. For example, if you use Administration Services Console to launch the migration, the client essbase.cfg file must be in the ARBORPATH/bin folder on the computer on which Essbase Administration Server is installed.
Essbase automatically creates a backup of the security file before and after migration (essbase.bak_preUPM and essbase.bak_postUPM). Oracle suggests that you manually back up these files to a safe location.
After you have migrated to Shared Services, a project is created for each Essbase Server that you migrate. The project contains a Shared Services application for each Essbase application on the migrated server. See Essbase Projects, Applications, and Databases in Shared Services.
When you migrate to Shared Services, all native Essbase users and groups that do not already exist in an external authentication directory are converted to native Shared Services users and groups in the native Shared Services user directory and are given equivalent roles. For example, a native Essbase Administrator (previously known as Supervisor) becomes a Shared Services user with the Essbase Administrator and the Provisioning Manager roles assigned, and a native Essbase user with Calc privileges on a database becomes a Shared Services user with the Calc role assigned on the application that contains the database. During migration, Administrators and Application Managers are automatically given the Provisioning Manager role for the appropriate applications.
When Essbase runs in EPM System security mode, the Essbase create/delete user privilege becomes obsolete. You must be an Essbase administrator to create/delete Essbase users and, additionally, you must be a Shared Services administrator to create/delete users in Shared Services.
In Shared Services, if an Essbase application contains multiple databases, the databases must have the same user security access levels. During migration, if a user has different access levels for two databases in the same application, the user is given the more restrictive access level for both databases. In such cases, a warning is sent to the Administrator who ran the migration and the information is logged in the AccessModifiedUsers_n.txt file, which is located in the ARBORPATH/bin directory.
If a migration fails, the status of the migration depends on the point at which it fails. For example, if the migration fails at step 1, then the total migration fails. If a migration fails at step 2, the result depends on the reason for failure. If a migration fails at step 3, when one or more users fails to migrate, then applications and groups may have been migrated.
When you use Administration Services Externalize Users Wizard to migrate Administration Services users or to remigrate Essbase users that previously failed to be migrated, migration errors are logged in the file that you specify in the wizard, as well as in the Essbase Server log (EPM_ORACLE_HOME/logs/essbase/essbase.log).
Shared Services cannot contain two groups at different levels in the same hierarchy (an ancestor-child relationship) when the groups exist in Essbase (see Example 2). If it does, the entire migration process fails.
The Essbase group cannot contain a user that exists in Shared Services, unless the Shared Services user belongs to the Shared Services group of the same name. If it does, the Essbase group, and all users in the group, do not migrate.
group 1, group 2
group 3 | group 1, group 2
If group 3 has Administrator (previously known as Supervisor) access to the Essbase Server instance and Essbase group 1 and group 2 have user access, the resulting group 1 and group 2 in Shared Services will have Administrator access.
group 1, group 2
group 1 | group 2
group 1, group 2, group 3
group 3 | group 1, group 2
Essbase, when in EPM System security mode, now enables user and group names to be non unique, if you specify the user or group's provider directory or unique identity attribute.
In MaxL, user and group names can be specified as name@provider or as a unique identity attribute.
The provider is the name of a user directory, such as LDAP or Active Directory, where the external user or group is hosted. The unique identity attribute, or "identity," is a unique string assigned to every user and group. The identity enables Essbase to distinguish between users and groups with the same name across providers.
For more information, see the MaxL topics for USER-NAME and GROUP-NAME in the Oracle Essbase Technical Reference.
If a user or group name includes the @ character, you must specify the provider as well, or else Shared Services considers the @ character as a delimiter indicating a provider name. For example, if you want to log in user admin@msad which is on a Native Directory provider, you must specify 'admin@msad@Native Directory'.
If a discrepancy occurs between the security information in Shared Services and the security information in the Essbase security file, the type of discrepancy determines whether Shared Services information or the Essbase security file information takes precedence.
Shared Services takes precedence for user and group information. User and group information can be restored using Shared Services and external user directory backup and recovery procedures. See the Oracle Hyperion Enterprise Performance Management System Backup and Recovery Guide.
When recovering user and group information, any associations to filters, calculation scripts, and application access type are lost if the Shared Services backup does not have that information. If the Essbase security backup file does not have that information, the filters and calc scripts themselves are lost (not just the associations to the users or groups).
Essbase takes precedence for application and database information. If an application is deleted from Shared Services, the application is still available in Essbase. You must reregister the application with Shared Services. If an application is deleted in Essbase, it is automatically deleted from Shared Services.