In This Section:
Oracle Enterprise Performance Management System User Security Administration Guide
Oracle Enterprise Performance Management System User Security Administration Guide
Essbase provides a system for managing access to applications, databases, and other artifacts within Essbase. Using the Essbase native security system provides protection and the security available through your local area network.
Essbase native security addresses a wide variety of database security needs with a multilayered approach to enable you to develop the best plan for your environment. Various levels of permission can be granted to users and groups or defined at the system, application, or database level. You can apply security in the following ways:
To grant permissions to individual users and groups of users. When higher, these permissions take precedence over minimum permissions defined for applications and databases. Ordinary users have no inherent permissions. Permissions can be granted to users and groups by editing the users and groups or by using the grant MaxL statement. See Granting Permissions to Users and Groups in Essbase Native Security Mode.
You can create users who log on using the parameters of an external authentication repository instead of the Essbase password. If you want users to use an outside authentication repository, such as LDAP, you must implement EPM System security and create the Essbase users with a reference to that security mode. See Using EPM System Security for External Authentication in Essbase Native Security Mode.
To set common permissions for all users of an application or database, you can set minimum permissions that all users can have at each application or database scope. Users and groups with lower permissions than the minimum gain access; users and groups with higher granted permissions are not affected. You can also temporarily disable different kinds of access using application settings. See Managing Global Security for Applications and Databases in Native Security Mode.
Create and manage login restrictions for the entire Essbase Server. View and terminate current sessions and requests running on the entire Essbase Server or only on particular applications and databases. See Managing User Activity on Essbase Server in Essbase Native Security Mode.
Define database permissions that users and groups can have for particular members, down to the individual data value (cell). See Controlling Access to Database Cells Using Security Filters.
Table 121 describes security permissions and the tasks that can be performed with those permissions.
Table 121. Essbase Permissions
No inherent access to any users, groups, or data values, unless access is granted globally or by a filter. No Access is the default when creating an ordinary user. Users with No Access permissions can change their passwords.
Ability to create, delete, and modify databases within the assigned application. Ability to modify the application settings, including minimum permissions, remove locks on the application, terminate sessions and requests on the application, and modify any artifact within the application. You cannot create or delete an application unless you also have been granted the system-level Create/Delete Applications permission.
Ability to access specific data and metadata according to the restrictions of a filter assigned to the user or group. The filter definition specifies, for subsets of a database, whether read, write, no access, or metaread is allowed for each subset. A user or group can be granted only one filter per database. Filters can be used in conjunction with other permissions. See Controlling Access to Database Cells Using Security Filters.
Ability to create and delete applications and databases within those applications, and control permissions, locks, and resources for applications created. Includes designer permissions for the applications and databases created by this user.
For Essbase Servers, you can continue to use Essbase native authentication if you want to continue managing users and groups as you did in previous releases. In Essbase native security mode, you continue to manage users through Administration Services Console. You can continue to create native and external users as you did before.
If you plan to use external authentication in Essbase native security mode, you must configure external authentication through Shared Services. See Using EPM System Security for External Authentication in Essbase Native Security Mode.
If any Essbase Server that you administer from Administration Services Console runs in EPM System security mode, Essbase Administration Server must also run in EPM System security mode. You cannot use a combination of EPM System security mode and Essbase native security mode to manage users on an Essbase Server. You must choose one mode for managing all Essbase users on an Essbase Server.
When you create a user or a group in Essbase, you define a security profile. The security profile is where you define the extent of the permissions that users and groups have in dealing with each other and in accessing applications and databases.
If you are using Administration Services, you also must create users on the Essbase Administration Server. See About Administration Services Users.
To create a user means to define the user name, password, and permission. You can also specify group membership for the user, and you can specify that the user must change the password at the next login attempt, or that the user name is disabled, preventing the user from logging on.
To create a user, use a tool:
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.
To specify application access types for users, use a tool:
A member of a group may have permissions beyond those assigned to the group, if permissions are also assigned individually to that user.
When you create a user, you can assign the user to a group. Similarly, when you create a group, you can assign users to the group. You must define a password for each user; there are no passwords for groups.
You can define security permissions for individual users and groups. Groups comprise users who share minimum permissions. Users inherit the permissions of the group and additionally can have access to permissions exceeding those of the group.
In Administration Services, users and groups can be created in different ways to specify their system-level permissions. These methods are represented in Administration Services Console as user types. In MaxL, user types do not exist; instead, you grant the permissions after the user is created.
A user or group with Administrator permission has full access to the entire system and all users and groups. The user who installs Essbase on the server is designated the System Administrator for that server. Essbase requires that at least one user on each server has Administrator permission. Therefore, you cannot delete or downgrade the permission of the last administrator on the server.
Users with Create/Delete Applications permission cannot create or delete users, but they can manage application-level permission for those applications that they have created. See Managing Global Security for Applications and Databases in Native Security Mode.
If you need to grant resource-specific permissions to users and groups that are not implied in any user types, you can grant the specific application or database permissions to users when creating or editing them in Administration Services. Using MaxL, you grant the permissions after the user is created by using the grant statement.
There is no need to grant permissions to users or groups that are already Administrators—they have full permissions to all resources on the Essbase Server. For a given database, users or groups can also be granted any of the following permissions:
Table 122. Database Permissions
Indicates that data and metadata access is restricted to those filters assigned to the user. (See Controlling Access to Database Cells Using Security Filters.)
The Filter check box grants a filter artifact to a user or group. A user or group can be granted only one filter per database. Selecting this option or any other option except None enables the selection of a filter artifact from the list box.
Users and groups can be granted Application Manager or Database Manager permission for particular applications or databases. These permissions are useful for assigning administrative permissions to users who need to be in charge of particular applications or databases but need only ordinary user permissions for other purposes.
For references to methods you can use to grant Designer permissions to a user or group, see Granting Application and Database Access to Users and Groups in Essbase Native Security Mode.
To edit a user means to modify the security profile established when the user was created. For information about changing user passwords, see Propagating Password Changes in Essbase Native Security Mode.
An easy way to create a user with the same permissions as another user is to copy the security profile of an existing user. The new user is assigned the same user type, group membership, and application/database access as the original user.
You can copy users and groups on the same Essbase Server or from one Essbase Server to another, according to your permissions. You can also migrate users and groups across servers along with an application. See “Copying Users” in the Oracle Essbase Administration Services Online Help.
To copy a user or group, you duplicate the security profile of an existing user or group and give it a new name, which saves you the time of reassigning permissions when you want them to be identical.
Copying removes any security permissions that the creator does not have from the copy. For example, a user with Create/Delete Users permission cannot create an administrator by copying the profile of an existing administrator.
An authentication directory is a centralized store of user information such as login names and passwords, and other corporate information. The repository functions like a telephone directory. The authentication directory probably contains much more than user names and passwords; for example, it may include e-mail addresses, employee IDs, job titles, access rights, and telephone numbers. It may also contain artifacts other than users; for example, it may contain information about corporate locations or other entities.
Register Essbase with Shared Services.
See the Oracle Enterprise Performance Management System Installation and Configuration Guide.
Configure user directories for Essbase.
See the Oracle Enterprise Performance Management System User Security Administration Guide.
In addition to granting permissions to users and groups, you can change security settings for entire applications and databases and their related files and resources. Application and database security settings enable you to manage connections and create a lowest-common-security profile for the applications and databases.
You can define permissions and other security settings that apply to applications by changing the application settings. The settings you define for the application affect all users, unless they have higher permissions granted to them at the user level.
Settings that define the minimum permissions to the application (see Setting Application and Database Minimum Permissions in Essbase Native Security Mode)
When disabled, prevents all users from starting the application directly or as a result of operations that would start the application; for example, attempting to change application settings or create databases. By default, the application is not prevented from starting.
When unchecked, prevents users from making requests to databases in the application, including non-data-specific requests such as viewing database information or changing database settings. Administrators are affected by this setting as a safety mechanism to prevent accidental changes to databases during maintenance operations. By default, commands are enabled.
When unchecked, prevents users with a permission lower than Application Manager for that application from making connections to databases within the application which require the databases to be started. By default, connections to databases are allowed.
When unchecked, prevents modification to on-disk database structures; for example, any operation that might have an effect on the data. This restriction does not include outline operations. To block metadata updates, set the database to read-only mode or uncheck Allow Commands and/or Allow Connects. By default, updates are enabled.
Table 123 describes when the implementation of protective application settings takes effect, how long the effects last, and which users are affected.
Table 123. Scope and Persistence of Application-Protection Settings
To change application settings, use a tool:
If performing maintenance operations that require disabling commands or updates, make those maintenance operations within the same session as the one in which the setting was disabled.
If you disable commands or updates in a MaxL script, be aware that the end of the script constitutes the end of the session. Calling a nested MaxL or ESSCMD script from the current MaxL script also constitutes the end of the session.
If you disable commands or updates in an ESSCMD script, the end of the script constitutes the end of the session, but calling a nested ESSCMD script from the current ESSCMD script does not constitute the end of the session.
Never power down or reboot your client computer when you have cleared any Allow settings. Always log off from the server correctly. Improper shutdown can cause the application to become inaccessible, which requires a full application shutdown and restart.
If a power failure or system problem causes Essbase Server to improperly disconnect from the Essbase client, and the application is no longer accessible, you must shut down and restart the application. See Starting and Stopping Applications.
Minimum database access permissions can be specified at the application or database level. If specified for an application, minimum database access permissions apply to all databases within the application. When a minimum permission is set to a level higher than None (or No Access) for an application or database, all users inherit that permission to access the database or databases.
For example, if an application has read permission assigned as the minimum database access level, all users can read any database within that application, even if their individual permissions do not include read access. Similarly, if a database has a minimum permission setting of None, only users with sufficient granted permissions (granted directly or implied by filters or group membership) can gain access to the database.
Users with Administrator, Application Manager, or Database Manager permissions are not affected by minimum permission settings applied to applications or databases they own. Administrators have full access to all resources, and Application Managers and Database Managers have full access for their applications or databases.
Changes to the minimum permission settings for applications affect only those databases that have lower minimums. In other words, settings defined at a lower level take precedence over more global settings.
The permissions listed in Table 124 are available as minimum settings for applications and databases. Databases of an application inherit the permissions of the applications whenever the application permissions are set higher than those of the database.
Specifies read-only access to any artifact or data value in the application or database. Users can view files, retrieve data values, and run report scripts. Read access does not permit data-value updates, calculations, or outline modifications.
Specifies Update access to any data value in the databases of the application, or in one database. Users can view Essbase files, retrieve and update data values, and run report scripts. Write access does not permit calculations or outline modifications.
Specifies Calculate and update access to any data value in the databases of the application, or in one database. Users can view files, retrieve, update, and perform calculations based on data values, and run report and calculations scripts. Calculate access does not permit outline modifications.
Specifies Calculate and update access to any data value in the databases of the application, or in one database. In addition, Designer permission enables users to view and modify the outline and files, retrieve, update, and perform calculations based on data values, and run report and calculation scripts.
Although any user with a minimum of read access to a database can start the database, only an Administrator, a user with Application Manager permission for the application, or a user with Database Manager permission for the database can stop the database.
To set minimum permissions for an application, use a tool:
For information about managing security for partitioned databases, see Designing Partitioned Applications.
To view sessions, disconnect sessions, or terminate requests, you must have Administrator permission or Application Manager permission for the specified application. You can view or terminate only sessions or requests for users with permissions equal to or lesser than your own.
A session is the time between login and logout for a user connected to Essbase Server at the system, application, or database scope. A user can have multiple sessions open at any time; for example, a user may be logged on to different databases. If you have the appropriate permissions, you can log off sessions based on any criteria you choose; for example, an administrator can log off a user from all databases or from one database.
A request is a query sent to Essbase Server by a user or by another process; for example, a default calculation of a database, or a restructuring of the database outline. Each session can process only one request at a time.
You cannot terminate a restructure process. If you attempt to terminate it, a "command not accepted" error is returned, and the restructure process is not terminated.
To disconnect a session or request using Administration Services, see “Disconnecting User Sessions and Requests” in the Oracle Essbase Administration Services Online Help.
To disconnect a session or request using MaxL, use alter system kill request or alter system logout session. See the Oracle Essbase Technical Reference.
Smart View users can interactively send data from a spreadsheet to the server. To maintain data integrity while providing multiple-user concurrent access, Essbase enables users to lock data for the purpose of updating it. Users who want to update data must first lock the records to prevent other users from trying to change the same data.
Occasionally, you may need to force an unlock operation. For example, if you attempt to calculate a database that has active locks, the calculation must wait when it encounters a lock. By clearing the locks, you allow the calculation to resume.
You can place limitations on the number of login attempts users are allowed, on the number of days a user account may remain inactive before becoming disabled from the server, and on the number of days users are allowed to have the same passwords. Only system administrators (users with Administrator permission) can access these settings. The limitations apply to all users on the server and are effective upon clicking OK.
If you later change the number of unsuccessful login attempts allowed, Essbase resets the count for all users. For example, if the setting was 15 and you changed it to 20, users are allowed 20 new attempts. If you changed the setting to 2, a user who had exceeded that number when the setting was 15 is not locked out. The count returns to 0 for each change in settings.
You can change a user’s password and propagate the new password to other Essbase Servers. You need Create/Delete Users and Groups permissions for both the source and the target servers. The user whose password you are changing must exist on the target servers, and the target servers must be running.
If you use Administration Services to change a user’s Essbase Server password, and if the user is also an Administration Services user, the user’s Administration Services user properties are updated automatically. The user’s Administration Services password is not affected. See “Changing Passwords for Essbase Server Users” in the Oracle Essbase Administration Services Online Help.
You can prevent a user from logging in to an Essbase Server by disabling the user name at the Essbase Server level. A user name is disabled automatically when the user exceeds limitations specified, or a user name can be disabled manually for individual users. See Managing Passwords and User Names in Essbase Native Security Mode.
In Administration Services Console, you can view and activate all user names that have been disabled for an Essbase Server. Only users with at least Create/Delete User permission can view or reactivate disabled user names.
To disable a user name manually, use a tool: