Managing Security for Users and Applications Skip Navigation
Essbase® Analytic Services Database Administrator's Guide | Update Contents | Previous | Next | Print | ? |
Information Map

Managing Security for Users and Applications


Analytic Services provides a comprehensive system for managing access to applications, databases, and other objects. The Analytic Services security system provides protection in addition to the security available through your local area network.

This chapter contains the following sections:

Understanding Security and Permissions

The Analytic Services security system addresses a wide variety of database security needs with a multi layered 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:

Table 28 describes all security permissions and the tasks that can be performed with those permissions.


Table 28: Description of Analytic Services Permissions  

Permission
Affected Scope
Description

No Access or None

Entire system, application, or database

No inherent access to any users, groups, or data values, unless access is granted globally or by means of a filter. No Access is the default when creating an ordinary user. Users with No Access permissions can change their own passwords.

Read

Database

Ability to read data values.

Write

Database

Ability to read and update data values.

MetaRead

Database

Ability to read metadata (dimension and member names) and update data for the corresponding member specification.

Execute (or Calculate)

Entire system, application, database, or single calculation

Ability to calculate, read, and update data values for the assigned scope, using the assigned calculation.

Supervisors, application designers for the application, and database designers for the database can run calculations without being granted execute access.

Database Designer

Database

Ability to modify outlines, create and assign filters, alter database settings, and remove locks/terminate sessions and requests on the database.

A user with Database Designer permission in one database does not necessarily have that permission in another.

Application Designer

Application

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 object within the application. You cannot create or delete an application unless you also have been granted the system-level Create/Delete Applications permission.

A user with Application Designer permission in one application does not necessarily have that permission in another.

Filter Access

Database

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. For a comprehensive discussion of filters, see Controlling Access to Database Cells.

Create/delete applications

Entire system

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.

Create/Delete Users, Groups

Entire system

Ability to create, delete, edit, or rename all users and groups having equal or lesser permissions than their own.

Supervisor

Entire system

Full access to the entire system and all users and groups.



Creating Users and Groups

When you create a user or a group in Analytic Services, 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. This section contains the following sections:

If you are using Administration Services, you also need to create users on the Administration Server. For more information, see About Administration Services Users.

Creating 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 is required to change the password at the next login attempt, or that the user name is disabled, preventing the user from logging on.

User names can contain only characters defined within the code page referenced by the ESSLANG variable and they cannot contain the backslash (\) character. User names must begin with a letter or a number.

To create a new user, use either of the following methods:


Tool
Topic
Location

Administration Services

Creating Users on Analytic Servers

Essbase Administration Services Online Help

MaxL

create user

Technical Reference



For example, to create a user named admin and grant that user Supervisor permissions, use the following MaxL statements:

create user admin identified by 'password';
grant supervisor to admin; 
 

Creating Groups

A group is a collection of users who share the same minimum access permissions. Placing users in groups can save you the time of assigning identical permissions to users again and again.

Note: A member of a group may have permissions beyond those assigned to the group, if permissions are also assigned individually to that user.

The process for creating, editing, or copying groups is the same as that for users, except that there are no group passwords. You define group names and permissions just as you do for users.

Note: A group name may not contain a backslash (\).

When you create a new user, you can assign the user to a group. Similarly, when you create a new group, you can assign users to the group. You must define a password for each user; there are no passwords for groups.

To create groups, use either of the following methods:


Tool
Topic
Location

Administration Services

Creating Groups on Analytic Servers

Essbase Administration Services Online Help

MaxL

create group

Technical Reference



Granting Permissions to Users and Groups

You can define security permissions for individual users and groups. Groups are collections of users that share the same minimum permissions. Users inherit all permissions of the group and can additionally have access to permissions that exceed those of the group.

Permissions can be granted to users and groups in the following ways:

Assigning User and Group Types

One way to assign permissions to users and groups is to define user and group types when you create or edit (modify the permissions of) the users and groups.

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.

In Administration Services, users can be created with the following types:

For instructions about creating users and groups, see Creating Users and Creating Groups.

Granting Application and Database Access to Users and Groups

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.

You can grant or modify user and group application and database permissions from an edit-user standpoint or from an application or database security perspective. The results are the same.

Note: If a user has insufficient permission to access the data in a database, the value does not show up in queries, or shows up as #NOACCESS.

There is no need to grant permissions to users or groups that are already Supervisors-they have full permissions to all resources on the Analytic Server. For a given database, users or groups can also be granted any of the following permissions:


Table 29: Permissions Available at the Database Scope  

Database permission
Description

None

Indicates no access to any object or data value in a database.

Filter Access

Indicates that data and metadata access is restricted to those filters assigned to the user. (For a comprehensive discussion of filters, see Controlling Access to Database Cells.)

The Filter check box grants a filter object 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 object from the list box.

Read Only

Indicates read permission, that is, the ability to retrieve all data values. Report scripts can also be run.

Read / Write

Indicates that all data values can be retrieved and updated (but not calculated). The user can run, but cannot modify, Analytic Services objects.

MetaRead

Indicates that metadata (dimension and member names) can be retrieved and updated for the corresponding member specification.

Calculate

Indicates that all data values can be retrieved, updated, and calculated with the default calculation or any calculation for which the user has been granted permission to execute.

Database Designer

Indicates that all data values can be retrieved, updated, and calculated. In addition, all database-related files can be modified.



To grant or modify application or database permissions for a user or group, use either of the following methods:


Tool
Topic
Location

Administration Services

Managing User/Group Permissions for Applications and Databases

Essbase Administration Services Online Help

MaxL

To grant permissions: grant

To change the user type or group: alter user

Technical Reference



Granting Designer Permissions to Users and Groups

Users and groups can be granted Application Designer or Database Designer 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 who only need ordinary user permissions for other purposes.

You need to grant database access to other users if any of the following conditions apply:

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.

Managing Users and Groups

To help manage security between users and groups, the following user-management tasks are available at varying degrees to users with different permissions:

Viewing Users and Groups

To view users and groups, use either of the following methods:


Tool
Topic
Location

Administration Services

Enterprise View > Security node > Users node or Groups node

Essbase Administration Services Online Help

MaxL

display user or display group

Technical Reference



Editing Users

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.

To change a password or other user properties, use either of the following methods:


Tool
Topic
Location

Administration Services

Editing User Properties

Essbase Administration Services Online Help

MaxL

alter user

Technical Reference



Editing Groups

To edit a group means to modify the security profile established when the group was created.

To view or change group membership, use either of the following methods:


Tool
Topic
Location

Administration Services

Editing Group Properties

Essbase Administration Services Online Help

MaxL

display user in group or alter group

Technical Reference



Copying an Existing Security Profile

An easy way to create a new 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 also create new groups by copying the security profile of an existing group. The new group is assigned the same group type, user membership, and application access as the original group.

You can copy users and groups on the same Analytic Server or from one Analytic Server to another, according to your permissions. You can also migrate users and groups across servers along with an application. For more information, see "Copying Users" in Essbase Administration Services Online Help.

To copy a user or group means to duplicate the security profile of an existing user or group, and to give it a new name. It is helpful to copy users and groups because it saves you the time of reassigning permissions in cases where you want them to be identical.

Note: Copying removes any security permissions the creator does not have from the copy. For example, a user with Create/Delete Users permission cannot create a new supervisor by copying the profile of an existing supervisor.

To create a new user or group by copying the security profile of an existing user or group, use either of the following methods:


Tool
Topic
Location

Administration Services

Copying Users and Copying Groups

Essbase Administration Services Online Help

MaxL

create user or create group

Technical Reference



Deleting Users and Groups

To delete users and groups, use either of the following methods:


Tool
Topic
Location

Administration Services

Deleting Users and Deleting Groups

Essbase Administration Services Online Help

MaxL

drop user or drop group

Technical Reference



Renaming Users and Groups

To rename users and groups, use either of the following methods:

Note: A group name may not contain a backslash (\).


Tool
Topic
Location

Administration Services

Renaming Users and Renaming Groups

Essbase Administration Services Online Help

MaxL

alter user and alter group

Technical Reference



Using the Hyperion Security Platform for External Authentication

External authentication means that the user login information needed by Analytic Services is maintained in a central authentication directory, such as Lightweight Directory Access Protocol (LDAP) Directory, Microsoft Active Directory, or Windows NT LAN Manager.

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 objects other than users; for example, it may contain information about corporate locations or other entities.

To use the security platform for Analytic Services, your organization must already have an authentication directory that contains centralized user information. Additionally, you must employ an XML-based security configuration file to specify correct information pertaining to your corporate authentication directory.

The following types of authentication repositories are supported by the security platform:

To learn more about implementing the Hyperion security platform,

  1. Check the Essbase Analytic Services Installation Guide to make sure your required platform and authentication directory are supported.

  2. See the help topic "Configuration for External Authentication," which is in the "Security Platform Reference" section of the Technical Reference. Follow the configuration guidelines in that document.

  3. To manage external authentication of users using Administration Services, see also "Managing External Authentication" in the Essbase Administration Services Online Help.

Note: Prior to this release, Analytic Services provided support for external authentication using built-in modules supplied as parameters to the AUTHENTICATIONMODULE essbase.cfg setting. Those modules did not include the ability to share the same external authentication scheme with other Hyperion software applications or to enable single sign-on to Analytic Services from other Hyperion applications. Support for the earlier modules is unaffected by the new security platform. Implementation of the security platform is optional, but Hyperion strongly encourages using the security-platform authentication over the built-in modules authentication.

Managing Global Security for Applications and Databases

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.

This section contains the following sections:

Defining Application Settings

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.

Only users with Supervisor permission (or Application Designer permission for the application) can change application settings.

To define settings for an application, see Setting General Application Connection Options or Setting Application and Database Minimum Permissions.

Setting General Application Connection Options

The following application settings are available:

The following settings are available for various levels of application security. For information about how and when disabling these settings takes effect, see Table 30.

Table 30 describes when the implementation of protective application settings takes effect, how long the effects last, and which users are affected.


Table 30: Scope and Persistence of Application-Protection Settings  

Disabled Application Setting
When the Disabled Setting Takes Effect
Which Users are Affected by the Disabled Setting
Persistence of the Disabled Setting

Allow Users to Start Application

Immediately

All users, including supervisors.

Users currently logged on and users who log on later.

The application cannot be started until an administrator re-enables the start-up setting.

Start Application When Analytic Server Starts

Immediately

All users.

The application will not start with Analytic Server unless an administrator enables it.

Allow Commands

Immediately

All users, including supervisors.

Users currently logged on and users who log on later.

Commands are disabled until any of the following actions occur:

  1. The administrator who disabled commands logs off.

  2. The application is stopped and restarted.

  3. An administrator re-enables commands.

Allow Connects

Immediately, except that disabling connections does not affect users who already have databases loaded.

Users with permissions lower than Application Designer.

Users currently logged on and users who log on later.

Users already connected to the database are not affected.

Connections are disabled until any of the following actions occurs:

  1. The application is stopped and restarted.

  2. An administrator re-enables connections.

Allow Updates

Immediately

All users, including supervisors.

Users currently logged on and users who log on later.

Updates are disabled until any of the following occurs actions:

  1. The administrator who disabled updates logs off.

  2. The application is stopped and restarted.

  3. An administrator re-enables updates.

Enable Security

Immediately

All users, including supervisors.

Users currently logged on and users who log on later.

Security is disabled until a user re-enables security.



To change application settings, use either of the following methods:


Tool
Topic
Location

Administration Services

Setting Application Properties

Essbase Administration Services Online Help

MaxL

alter application

Technical Reference



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

Caution: Never power down or reboot your client computer when you have cleared any of the 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 Analytic Server to improperly disconnect from the Analytic Services client, and the application is no longer accessible, you must shut down and restart the application. For instructions about starting and stopping Analytic Services, see Starting and Stopping Analytic Server.

Setting Application and Database Minimum Permissions

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 Supervisor, Application Designer, or Database Designer permissions are not affected by minimum-permission settings applied to applications or databases they own. Supervisors have full access to all resources, and Application Designers and Database Designers have full access for their applications or databases.

Users and groups with lower than the minimum permissions inherit at least the minimum permissions for any 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 31 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.


Table 31: Minimum Permission Settings Available for Applications and Databases  

Permission
Description

None

Specifies that no minimum permission has been defined for the application or database. None is the default global permission for newly created applications and databases.

Read

Specifies Read-Only access to any object 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.

Write

Specifies Update access to any data value in the databases of the application, or in one database. Users can view Analytic Services files, retrieve and update data values, and run report scripts. Write access does not permit calculations or outline modifications.

MetaRead

Gives Read access to the specified members, but hides data for their ancestors, and hides data and metadata for their siblings.

Calculate

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.

Designer (for Application or Database)

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.



Note: Although any user with a minimum of Read access to a database can start the database, only a Supervisor, a user with Application Designer permission for the application, or a user with Database Designer permission for the database can stop the database.

To set minimum permissions for an application, see "Setting Minimum Permissions for Applications" in the Essbase Administration Services Online Help, or see alter application in the MaxL DDL section of the Technical Reference.

To set minimum permissions for a database, see "Setting Minimum Permissions for Databases" in the Essbase Administration Services Online Help, or see alter database in the MaxL DDL section of the Technical Reference.

Managing User Activity on the Analytic Server

This topic explains how to manage the activities of users connected to the Analytic Server. The security concepts explained in this section are session and request management, lock management, connection management, and password and user name management. For information about managing security for partitioned databases, see Designing Partitioned Applications.

Disconnecting Users and Terminating Requests

The security system lets you disconnect a user from the Analytic Server when you want to perform maintenance tasks.

To view sessions, disconnect sessions, or terminate requests, you must have Supervisor permission or Application Designer 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 Analytic Server at the system, application, or database scope. A user can have more than one session open at any given 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 a particular database.

A request is a query sent to Analytic 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.

Note: 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 Essbase Administration Services Online Help.

To disconnect a session or request using MaxL, see the following table:


Table 32: Session and Request Termination Options  

Selections in Administration Services
MaxL equivalents

log off

selected user

only

alter system logout session
<session-id>;

log off

all users

on selected server

alter system logout session all;

log off

all users

on selected application

alter system logout session on
application <app-name>;

log off

all users

on selected database

alter system logout session on
database <dbs-name>;

log off

all instances of user

on selected server

alter system logout session by user
<user-name>;

log off

all instances of user

on selected application

alter system logout session by
user <user-name> on application
<app-name>;

log off

all instances of user

on selected database

alter system logout session on
database <dbs-name>;

kill

selected request

only

alter system kill request
<session-id>;

kill

all requests

on selected server

alter system kill request all;

kill

all requests

on selected application

alter system kill request on
application <app-name>;

kill

all requests

on selected database

alter system kill request on
database <dbs-name>;

kill

all requests from user

on selected server

alter system kill request by
user <user-name>;

kill

all requests from user

on selected application

alter system kill request by
user <user-name> on application <app-name>;

kill

all requests from user

on selected database

alter system kill request by user
<user-name> on database <dbs-name>;



Managing User Locks

Spreadsheet Add-in users can interactively send data from a spreadsheet to the server. To maintain data integrity while providing multiple-user concurrent access, Analytic Services 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.

Only Supervisors can view users holding locks and remove their locks.

To view or remove locks, use either of the following methods:


Tool
Topic
Location

Administration Services

Viewing Data Locks and Unlocking Data

Essbase Administration Services Online Help

MaxL

drop lock

Technical Reference



Managing Passwords and User Names

You can place limitations on the number of login attempts users are allowed, on the number of days users may not use Analytic Services 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 Supervisor permission) can access these settings. The limitations apply to all users on the server, and are effective immediately upon clicking OK.

Note: If you later change the number of unsuccessful login attempts allowed, Analytic Services resets the count for all users. For example, if the setting was 15 and you changed it to 20, all users are allowed 20 new attempts. If you changed the setting to 2, a user who had already exceeded that number when the setting was 15 is not locked out. The count returns to 0 for each change in settings.

To place limitations on users, use any of the following methods:


Tool
Topic
Location

Administration Services

Managing Password Longevity

Disconnecting Users Automatically

Essbase Administration Services Online Help

MaxL

alter system

Technical Reference

MaxL

alter user

Technical Reference



Propagating Password Changes

You can change a user's password and then propagate the new password to other Analytic 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 Analytic 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. For more information, see "Changing Passwords for Analytic Server Users" in Essbase Administration Services Online Help.

To change a user's Analytic Server password and propagate the new password to other Analytic Servers, see "Propagating Passwords Across Servers" in Essbase Administration Services Online Help.

Viewing and Activating Disabled User Names

You can prevent a user from logging in to an Analytic Server by disabling the user name at the Analytic Server level. A username is disabled automatically when the user exceeds limitations specified, or a username can be disabled manually for individual users. For more information about limitations that cause user names to become disabled automatically, see Managing Passwords and User Names.

Administration Services provides a Disabled Usernames window that enables you to view and activate all usernames that have been disabled for an Analytic Server. Only a user with at least Create/Delete User permission can view or reactivate disabled user names.

To disable a user name manually, use either of the following methods:


Tool
Topic
Location

Administration Services

Disabling Usernames

Essbase Administration Services Online Help

MaxL

alter user

Technical Reference



To view or activate currently disabled user names, use either of the following methods:


Tool
Topic
Location

Administration Services

Viewing or Activating Disabled Usernames

Essbase Administration Services Online Help

MaxL

alter user

Technical Reference



Understanding the essbase.sec Security File and Backup

All information about users, groups, passwords, permissions, filters, applications, databases, and their corresponding directories is stored in the essbase.sec file in the ARBORPATH\bin directory. Each time you successfully start the Analytic Server, a backup copy of the security file is created as essbase.bak. You can also update the security backup file more often by using one of the following methods:

To update the security backup file, use either of the following methods:


Tool
Topic
Location

Administration Services

Updating the Security Backup File

Essbase Administration Services Online Help

MaxL

alter system sync security backup

Technical Reference



If you attempt to start Analytic Server and cannot get a password prompt or your password is rejected, no .bak file is created. You can restore from the last successful startup by copying essbase.bak to essbase.sec. Both files are in the essbase\bin directory where you installed Analytic Services.

Caution: If Analytic Services stops running unexpectedly for any reason, such as a freeze or crash, or as the result of terminating a process, do not restart Analytic Server until you copy the backup file (essbase.bak) to the security file (essbase.sec). If you do not perform the copy first, when Analytic Server starts, Analytic Services notes that essbase.sec is corrupt, creates an empty security file, and copies it to essbase.bak, thus destroying the backup of your security information.



Hyperion Solutions Corporation link