Essbase security file

You can provision a user with the following roles for an Essbase Server:. You can provision a user with the following roles for an application:. 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. Table 61 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. The Provisioning Manager role, which is a Shared Services application-specific role, is automatically assigned when you migrate Essbase Administrators previously known as Supervisors.

Users with the Provisioning Manager role can provision users and groups with roles for applications. Ability to create and delete applications and databases within applications. Includes Application Manager and Database Manager permissions for the applications and databases created by this user. Ability to access any application or database that has a minimum access permission other than none. Ability to create, delete, and modify databases and application settings within the particular application.

Includes Database Manager permissions for databases within the application. The Provisioning Manager role is automatically assigned when you migrate Essbase Application Managers. Ability to manage databases for example, to change the database properties or cache settings , database artifacts, locks, and sessions within the assigned application. Ability to calculate, update, and read data values based on the assigned scope, using any assigned calculations and filter. Ability to update and read data values based on the assigned scope, using any assigned filter.

Ability to access specific data and metadata according to the restrictions of a filter. 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. 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.

If you migrate multiple Essbase Servers on the same computer, each Essbase Server migrated gets a different sequence number EssbaseServer. 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. Essbase automatically creates the following applications within the project and automatically registers the applications with Shared Services:. 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 rename the Shared Services project; however, the global Essbase Server application name is not renamed. 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.

Figure Once 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.

When users and groups are stored in an external authentication directory from any supported authentication provider, you must be sure that identical names for users and groups are not used, even if the identically-named users or groups reside in different directories from the same authentication provider for example, different directories from the same LDAP-based authentication provider or in directories from different authentication providers for example, an LDAP-based directory and an MSAD directory.

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. In Essbase, when you copy an application or database and the target Essbase Server is in Shared Services security mode, user and group security is not copied with the application.

Use the copy provisioning functionality in Shared Services Console to copy security for an application. Shared Services Console provides a centralized UI where you can perform user management tasks for Oracle Hyperion products. The Shared Services Console launches Essbase screens, which allow you to assign security access to database filters and calculation scripts. 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 Security Administration Guide.

To manage Essbase users in Shared Services Console, you must log in to the console as a user who is provisioned with the following Shared Services roles:.

Provisioning Manager role for the appropriate Essbase Server or applications. In Shared Services security mode, you must use the same user to log in to Administration Services Console as you use to connect the Essbase Server. When you launch Shared Services Console from a browser, you log in as whichever user is appropriate.

For example, you must log in 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 Shared Services 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.

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 Shared Services 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.

When you select an Essbase application from Shared Services Console, a screen is displayed, listing the users and groups provisioned to that application. On this screen, you select the users and groups to which you want to assign additional permissions. After clicking Next, select the database you want to work with, and then use the drop-down lists to assign filter and calculation script access to selected users and groups. For descriptive information about these two screens, click the Help button on one of these screens to display a context-sensitive help topic.

To specify access permissions in Shared Services, use a tool:. When you assign database calculation and filter access, you automatically log in to Administration Services and Essbase as the Shared Services Console logged-in user.

The user must have the Provisioning Manager role for the appropriate application s. You cannot assign database calculation or filter access to an Essbase Administrator or Application Manager. To refresh Essbase with database calculation and filter access security information for newly provisioned users, click Refresh. Although you can assign access to database filters and calculation scripts through Shared Services Console, you must create the filters and calculation scripts in Essbase.

For information on creating database filters, see Controlling Access to Database Cells. When you select a global Essbase Server application from Shared Services Console, a screen is displayed, listing the users and groups provisioned to that application.

On this screen, you select the users and groups for which you want to assign application access type. After clicking Next, use the drop-down list to assign application access type to the selected users and groups. To specify application access types for users in Shared Services, use a tool:. This user must be a valid Essbase Administrator and must have the Provisioning Manager role for the appropriate applications.

To refresh Essbase with application access type information for newly provisioned users, click Refresh. This topic provides information on synchronizing Essbase security with Shared Services security.

When the security information is out of sync, the user, group, and application information displayed in Essbase may be different from that in Shared Services. User synchronization refers to the process of ensuring that Essbase reflects the latest security information for a specific user and any related groups. Refresh refers to the process of ensuring that Essbase reflects the latest security information for all users, groups, and applications on an Essbase Server.

When an Administrator requests a refresh of the security information. User e-mail ID and description are not synchronized at user login or when selecting a database.

Shared Services synchronizes user information only when an Administrator, Application Manager, or Database Manager requests a refresh of security information. If NONE is specified, when you provision a user with an Essbase Server role, you must request a refresh of security information to enable the user to log in.

To request a refresh of security information, use a tool:. The information in this topic does not apply to changes made to access permissions for database filters and calculation scripts, which are synchronized immediately. Refresh security for a user: Users can synchronize their own security. An Essbase Administrator can synchronize security for all users. You can specify periodic, automatic refreshes of Essbase security information from Shared Services.

For example, you can specify that Essbase refresh security information from Shared Services every 60 minutes. After installation, Essbase and Administration Services are in native security mode. To use Shared Services, you must migrate to Shared Services security mode. Once you have converted to Shared Services security mode, you cannot convert back to native security mode.

Essbase Administration Server can run in Shared Services security mode with Essbase Server running in native 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:. Return the settings to their original values once the migration is complete. Specify these settings in the client essbase.

For example, if you use Administration Services Console to launch the migration, the client essbase. Essbase automatically creates a backup of the security file before and after migration essbase. Oracle suggests that you manually back up these files to a safe location. The Administration Services Essbase Server Properties window displays information on whether the server is in Shared Services security mode.

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. 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. Any externally authenticated users are registered with Shared Services but remain stored in their original authentication directory. If a user directory is not running, the entire migration fails. Users created using custom authentication are not migrated unless a matching user is already in Shared Services. An Essbase user name cannot exist as a group name in Shared Services.

If it does, the Essbase user does not migrate. 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. You can also use the MaxL statement display user to list instances of multiple database access level changes.

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.

You can use the MaxL statements display user and display group to list users and groups that failed migration and to remigrate all or a selection of these failed users and groups. If a group fails migration, all users in the group fail migration; you must repair and migrate the group in order for the users to migrate successfully.

An Essbase group name cannot exist as a user name in Shared Services. If it does, the Essbase group, and all users in the group, do not migrate. If a group exists in both Essbase and Shared Services, the following conditions apply:. 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 Shared Services group cannot contain a user that does not exist in the Essbase group of the same name. 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. Example 1: The groups in this example migrate successfully from Essbase to Shared Services. Shared Services has two identical groups and also has a group 3, which contains group 1 and group The groups migrate successfully because group 1 and group 2 are at the same level as each other in Shared Services and because Essbase does not have a group 3.

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. Example 2: The migration in this example fails because Shared Services contains group 1 and group 2 at different levels. Shared Services has group 1 and group 2, but group 1 contains group Example 3: The migration in this example fails because Essbase contains group 1, group 2, and group 3 and Shared Services contains group 3 at a different level from group 1 and group 2.

Shared Services has group 1 and group 2, but has a group 3, which contains group 1 and group ForEssbase Servers, you can continue to use native authentication if you want to continue managing users and groups as you did in previous releases.

In native security mode, you continue to manage users via Administration Services Console. You can continue to create native and external users as you did before. If you plan to use external authentication in native security mode, you must configure external authenticating through Shared Services. Essbase Server and Essbase Administration Server can both run in native security mode.

You do not need to install and configure Shared Services if both of the following are true:. Essbase and Administration Services are the only Oracle products you are installing. You want Essbase Server and Essbase Administration Server to continue running in native security mode and you do not plan to use external authentication in native security mode.

The same rules apply to Essbase Provider Servers. You cannot use a combination of Shared Services security mode and native security mode to manage users on an Essbase Server. You must choose one mode for managing all Essbase users on an Essbase Server. Native security mode will not be available in future releases of Essbase. Essbase provides a system for managing access to applications, databases, and other artifacts within Essbase. Using the Essbase security system provides protection in addition to the security available through your local area network.

The Essbase security system 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 scope. 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 statement in MaxL DDL data definition language. 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 the Shared Services security platform and create the Essbase users with a reference to the security platform.

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. 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.

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. Table 62 describes security permissions and the tasks that can be performed with those permissions.

No Access or None. 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 read metadata dimension and member names and update data for the corresponding member specification. Execute or Calculate. Ability to calculate, read, and update data values for the assigned scope, using the assigned calculation.

Administrators, application managers for the application, and database managers for the database can run calculations without being granted execute access. Database Manager. A user with Database Manager permission in one database does not necessarily have that permission in another. Application Manager. 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. A user with Application Manager permission in one application does not necessarily have that permission in another.

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. 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. Ability to create, delete, edit, or rename all users and groups having equal or lesser permissions than their own.

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 manually update the security backup file or change the frequency of backup file comparisons, use a tool:. The alter system reconcile grammar logs messages in essbase. An application or database is in the security file but not on the disk.

In this scenario, using the alter system reconcile force grammar removes the application or database from the security file. Changing or deleting Essbase security entities, such as filters, users, groups, applications, databases, substitution variables, disk volumes, passwords, and other Essbase artifacts, can cause fragmentation in the security file essbase.

Too much fragmentation in files can slow down security-related performance. Essbase compacts the security file automatically each time the Agent is stopped. You can check the fragmentation status of the security file and you can compact the security file without stopping the Agent. The fragmentation status of the security file is displayed as a percent. To compact the security file without stopping the Agent, use a tool:.

Enter the Agent command at the command prompt in the Essbase Server window. Compacting the security file while the Agent is running slows down Agent activity until the operation is completed, which could take a few minutes. An Essbase Administrator can export the contents of the essbase. When exporting essbase. The export security file command, which can be run from Administration Services Console or as a MaxL statement, is run against the Essbase Server session for which you are currently logged in.

The Essbase Server session can be run as a service. To export essbase. Managing the Essbase Security File essbase. In my experience, corruption to the Essbase security file is not identified within a minute period, so as a matter of habit, I set the follow in the Essbase configuration file essbase. The interval is in seconds.

This ensures that at any given time, I have 10 backups spanning across a hour period. I will determine the Essbase security file is corrupted easily within a few hours of symptoms occurring and can roll it back several hours if necessary. Cris Dunn is the manager of Perficient's EPM SupportNet practice which provides direct support for applications and infrastructure surrounding many organizations' EPM software implementations.