Skip Headers
Oracle® Beehive Administrator's Guide
Release 1 (1.4)

Part Number E13797-02
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

13 Managing Oracle Beehive Access Control

Oracle Beehive uses a robust and highly-configurable model for controlling access to the various features of Oracle Beehive, and to the shared content stored by users, including files, folders, workspaces, calendars, and so forth.

During installation, a default setup is created providing a variety of pre-configured privileges, roles, and sensitivities. (Each of these special terms is defined in detail in the first section of this module.)

This module describes the various functions you can use, as an administrator, to customize how Oracle Beehive grants and limits access for your users. It contains the following topics:

About Access Control

In Release 1 of Oracle Beehive, you can use the beectl command line tool to manage and customize most aspects of users' access to services and stored objects. Throughout this module, you may find it convenient to refer to Module 2, "Oracle Beehive Command Line Utility" in Oracle Beehive Administrator's Reference Guide for syntax. All of the commands related to access control are categorized as "access control," and listed in the beginning of that module in Table 2-1. Alternatively, you can list the access control beectl commands, using the beectl list_commands command:

beectl> list_commands --category "access control"

In Oracle Beehive, there are two methods for controlling access to objects:

Explicit Access Control

Explicit access control is accomplished by creating "Access Control Entities (ACEs)", which are logical pairings of "Accessors" and "Access Privileges". An ACE may either grant or restrict any of five Access Types:

  • READ: coded as +R or -R, this access type grants or revokes permission to open or read the object

  • WRITE: coded as +W or -W, this access type grants or revokes permission to add, alter, or make changes to the object. Note that version control preserves previous versions, so WRITE access does not itself provide DELETE access

  • DISCOVER: coded as +O or -O, this access type grants or revokes permission to see the object in lists, look it up in directories, find it in searches, and so forth. When DISCOVER privileges are revoked, a user cannot detect the existence of that object using any Oracle Beehive client process

  • EXECUTE: coded as +E or -E, this access type grants or revokes permission to invoke or assign the object or cause it to perform its function

  • DELETE: coded as +D or -D, this access type grants or revokes permission to delete the object


Not all access types have meaning for all entity types. For example, "delete" access is meaningless in the context of access to a service; "execute" access is meaningless in the context of access to a text file. Oracle Beehive ignores access type settings that are meaningless in a given context.

In an ACE, access types are referenced as +-RWOED (for example, "RW-D", or "–D+RW").

Any Oracle Beehive object may have any number of ACEs, collected into an Access Control List (ACL). ACLs are simply tables of ACEs, all of which apply to a single controllable entity.


You may find that you need to grant a similar collection of ACEs repeatedly to various different objects. To facilitate this, Oracle Beehive provides Sensitivities. A sensitivity is simply an ACL, given a label, and made available for users to apply to any object. A sensitivity on its own is not yet active; users apply sensitivities to entities, and thereby create an ACL containing the ACEs encapsulated by the sensitivity.

Sensitivities are always created at the workspace level of scope. A workspace manager can view or search for sensitivities within the workspace, using a client application.

For example, a ÒConfidentialÓ sensitivity could be applied to a set of artifacts. This sensitivity would prevent access from ALL_USERS, but grant access only to the creator of the object. Later, an instruction like Òshare all Confidential documents with BobÓ can be used by a workspace manager, to alter the sensitivity (and thus all objects in the workspace having that sensitivity) to grant Bob READ access to them.

Implicit Access Control

Implicit access control is accomplished by granting or revoking various levels of access (privileges) to users. You may do this by applying privileges directly to user accounts, or to any container which contains user accounts (groups, organizations, or the enterprise).


Oracle Beehive includes about 47 pre-defined privileges. Privileges are used to define access when there is no relevant entity. Examples include EMAIL_USER, AUDITOR, and WORKSPACE_MGR. The EMAIL_USER privilege grants access to use the E-mail functionality in Oracle Beehive. The AUDITOR privilege grants access to Oracle Beehive auditing functionality. You can list all privileges using the beectl list_privileges command. (Note: you cannot create custom privileges.)


The easiest and most flexible way to manage implicit access control is through the use of Roles.

A role is similar to a sensitivity; it encapsulates a collection of granted and revoked privileges, under a single label. However, you assign roles to users, thereby granting those users implicit access. Oracle Beehive is packaged with default roles, which you may modify, and you can also create new roles to meet the requirements of your organization.

Managing Privileges

A privilege is an assignable entity that grants access to some part of Oracle Beehive. For example, the EMAIL_USER privilege grants access to Oracle Beehive e-mail functions. Table 13-1, "Default Oracle Beehive Privileges" lists the default privileges pre-defined in every Oracle Beehive deployment.

Table 13-1 Default Oracle Beehive Privileges

Privilege Access Granted


Business administrator access to archiving functionality


Access to read auditing logs


Allows assignee to configure audit policy


Global superuser privilege allows assignee to perform any possible function


Business administrator access to time management functionality


User-level access to the calendar functionality


Business administrator access to web conferencing


User-level access to the web conferencing functionalityFootref 1


Business administrator access to file management


User-level access to the file management functionality within workspacesFootref 1






Business administrator access to mobile device management functionality


Business administrator access to e-mail settings


User-level access to the e-mail functionality




Administrator access to discussions functionality


User-level access to the discussions functionalityFootref 1


Business administrator access to instant messaging functionality


User-level access to the instant messaging functionalityFootref 1






System administrator access to add to, or modify, access control lists on objects


Administrator access to notifications functionality


User-level access to the notifications functionality


Administrator access to


Administrator access to policies


Administrator access to setting default preferences


User-level access to WebDAV and FTP protocolsFoot 1 


Administrator access to quota settings within the specified scope




Administrator access to resource management


Allows access to assign roles, within a specified scope




Administrator access to subscriptions functionality


User-level access to the subscription functionality




Administrator access to tasks functionality


User-level access to the tasks functionalityFootref 1


Administrator access to managing time zones


Administrator access to managing users




User-level access to the voice messaging functionalityFootref 1


Allows access to Oracle Beehive Administration Console (Oracle Beekeeper).

This privilege is only available in Oracle Beehive version 1.3 or later


Administrator access to assigning and managing workflow tasks


Administrator access to workflow functionality


Allows assignee to add workspaces within the specified scope


Administrator access within the specified workspace scope

Footnote 1 In Oracle Beehive Release 1, this privilege is inactive, meaning, the granted access is always available regardless of assignment of this privilege. The ability to disable this level of access by revoking this privilege is planned for a future release of Oracle Beehive.

Managing Roles

A role is a collection of privileges, which can be assigned to users. Roles are convenient because they allow you to provide several different layers of privileges to a heterogeneous population of users. A user may have any number of roles, granting the appropriate collection of privileges at a variety of scopes.


"Scope" refers to a logical level of organization within the Oracle Beehive deployment; the enterprise, or a specific organization, or a specific workspace.

An assigned role has two parts:

This section includes the following topics:

About Role Definitions

As part of the initial install seeding, a collection of role definitions are created and assigned (through assigned roles) to the ALL_USERS dynamic group (which is also seeded at install time). This means that all users within your enterprise are eligible to be assigned any of the default roles. Additional default role definitions are available, but unassigned.

When you create custom role definitions, you can assign them to specific groups, and at scopes lower than the enterprise level, if you wish.

You can list the existing role definitions using the beectl list_role_definitions command:

beectl> list_role_definitions

This produces output similar to the following:

| role_definition      | name                 | description          | access_types         | privileges           | always_enabled       |
| acrd=AUDIT-ADMIN,enpr=mycompany | AUDIT-ADMIN          |                      |                      | [AUDIT_ADMIN]        | true                 |
| acrd=AUDITOR,enpr=mycompany | AUDITOR              |                      |                      | [AUDITOR]            | true                 |
| acrd=DEFAULT_RESOURCE_ROLE_DEFINITION,enpr=mycompany | DEFAULT_RESOURCE_ROLE_DEFINITION | ResourceMgrRoleDef   |                      | [CALENDAR_USER, TASK_USER] | true                 |
| acrd=DELEGATOR,enpr=mycompany | DELEGATOR            |                      |                      | [DELEGATE]           | true                 |
| acrd=enterprise-administrator,enpr=mycompany | enterprise-administrator |                      |                      | [ARCHIVE_MGR, EXCEED_QUOTA, MARKER_MGR, ORGANIZATION_MGR, PREFERENCE_MGR, QUOTA_MGR, ROLE_MGR, USER_MGR, VERSION_MGR, WORKSPACE_MGR] | true                 |
| acrd=enterprise-system,enpr=mycompany | enterprise-system    | enterprise-system    |                      | [BYPASS]             | true                 |
| acrd=user-calendar,enpr=mycompany | user-calendar        |                      |                      | [CALENDAR_USER]      | true                 |
| acrd=user-content,enpr=mycompany | user-content         |                      |                      | [CONTENT_USER]       | true                 |
| acrd=user-core,enpr=mycompany | user-core            |                      |                      | [LOGIN, PROTOCOL_USER, WORKSPACE_ADD] | true                 |
| acrd=user-discussions,enpr=mycompany | user-discussions     |                      |                      | [FORUM_USER]         | true                 |
| acrd=user-email,enpr=mycompany | user-email           |                      |                      | [EMAIL_USER]         | true                 |
| acrd=user-notification,enpr=mycompany | user-notification    |                      |                      | [NOTIFICATION_USER]  | true                 |
| acrd=user-subscription,enpr=mycompany | user-subscription    |                      |                      | [SUBSCRIPTION_USER]  | true                 |
| acrd=user-task,enpr=mycompany | user-task            |                      |                      | [TASK_USER]          | true                 |
| acrd=workspace-coordinator,enpr=mycompany | workspace-coordinator |                      | +RWDEO               | [CALENDAR_MGR, CONF_MGR, CONTENT_MGR, EMAIL_MGR, FORUM_MGR, IM_MGR, MARKER_MGR, MODIFY_ACL, NOTIFICATION_MGR, POLICY_MGR, PREFERENCE_MGR, READALL, ROLE_MGR, SECURITY, SUBSCRIPTION_MGR, USER_MGR, VERSION_MGR, WORKFLOW_MGR, WORKSPACE_MGR] | true                 |
| acrd=workspace-document-coordinator,enpr=mycompany | workspace-document-coordinator |                      | +RWDEO               | [CONTENT_MGR, FORUM_MGR, MARKER_MGR, MODIFY_ACL, VERSION_MGR, WORKFLOW_MGR] | true                 |
| acrd=workspace-member,enpr=mycompany | workspace-member     |                      | +RWDEO               |                      | true                 |
| acrd=workspace-participant-coordinator,enpr=mycompany | workspace-participant-coordinator |                      | +RO                  | [MODIFY_ACL, ROLE_MGR, USER_MGR] | true                 |
| acrd=workspace-viewer,enpr=mycompany | workspace-viewer     |                      | +RO                  |                      | true                 |

As an example, the role definition user-email has the privilege EMAIL-USER granted to it. Similarly, the workspace-viewer role definition has access types +RO (it allows READ and DISCOVER access) granted to it.

You can use the beectl list_role_definitions command to search for role definitions based on name, using the % wildcard. For example, to find all role definitions related to workspaces, issue the following command:

beectl> list_role_definitions --name workspa%

This command should return results including: workspace-participant-coordinator, workspace-viewer, workspace-member, workspace-document-coordinator, and workspace-coordinator.

Creating Role Definitions

A role definition is simply a collection of privileges and access types. While Oracle Beehive comes pre-seeded with a variety of default role definitions, you may find it convenient to create your own role definitions.

To create a custom role definition, use the beectl add_role_definition command, setting the scope as desired (the whole enterprise, a specific organization, or a specific workspace).


For some privileges, scope does not make sense or is not required. For example, the LOGIN privilege allows or disallows user authentication with Oracle Beehive. Users do not log in at a level of scope, so a definition of scope makes no sense in combination with the LOGIN privilege.

For privileges that do take a scope, if you do not specify a scope, scope is set to the enterprise level by default.

For example:

beectl> add_role_definition --scope orgn=human_resources,enpr=mycompany --name hr-administrator --description "A manager of users and roles" --privilege ROLE_MGR --privilege USER_MGR --access_types ORWDE --always_enabled true

In this example, two privileges are granted: ROLE_MGR and USER_MGR. Additionally, all access types are granted. This role might be appropriate for a high-level administrator needing access to all objects in the organization, and the ability to grant roles to all users within that organization. Alternatively, if the scope were set at the level of a workspace, it might be useful for a director or manager needing access to manage users and assign roles only within that workspace. Note that in order to assign roles, a user must have the ROLE_MGR privilege, and in order to assign them to users, the USER_MGR privilege is needed.

As another example:

beectl> add_role_definition --scope enpr=mycompany --name workspace-viewer --description "Can see everything in the workspace" --access_types OR --always_enabled true

In this example, the role definition grants blanket Discover and Read access within the context in which it is assigned. This might be useful as a guest role, assignable at the level of a workspace, which would allow a guest user to find and read, but not modify, objects within the scope specified. This role definition is also set to "always enabled". This affects how the role definition works when it is used in an assigned role. See "Creating Assigned Roles" for details.

This role definition example actually recreates one of the default role definitions provided in Oracle Beehive: the workspace-viewer role.


To see a list of all privileges, use the beectl list_privileges command.

In Oracle Beehive, the convention is that all role definitions are in all-lowercase, while privileges are in all-caps. If you follow this convention when creating role definitions, you may find it easier to distinguish them from privileges when constructing your commands.

Exposing a Role Definition to Users

Once you have created a role definition, you have the option of creating an ACE which will expose the role definition to users. If you do not take this step, the role definition will only be manageable from the command-line. Users within Oracle Beehive will not be able to see, or make use of, the custom role.

To expose a role definition, add an ACE using the beectl add_local_ace command. For example, to expose the role definition to all members of a privileged group called "ADMINS":

beectl> add_local_ace --entity acrd=workspace-viewer,enpr=mycompany --accessor grup=ADMINS,enpr=mycompany --access_types RE

This command grants Read and Execute access types, enabling the members of the ADMINS group to execute (assign) the role definition specified in <Role>. Note that the entity is defined by listing the role definition by name, the organization by name, and the enterprise by name, separated by commas (no spaces). The accessor is specified by name, using the same fully-qualified syntax.

All access control role definitions have the four-letter code acrd, organizations are orgn, and enterprises are enpr.

Creating Assigned Roles

You may tie a role definition to an object called an Assigned Role. Assigned roles grant role definitions directly to users or groups. An assigned role always specifies assignees, and may also specify scope.

An Assigned role ties a role definition to a set of accessors in a given scope.

If the role definition that is associated with the assigned role is marked "Always Enabled", then the assigned role is always enabled for all of its accessors; it may not be disabled. If the role definition is not marked "Always Enabled", then by default it is disabled for all of its accessors unless and until it is enabled (by a user).

Note that if an assigned role is disabled (that is, its role definition is not marked "Always Enabled", and it has not been enabled in the current user context), privileges and access types that are specified in the role definition have no effect. However, if the role definition denies any access types, those denied access types still take effect.

For example, to assign the workspace-viewer role to a user, with the scope of a workspace (so the role definition applies for that user to that specific workspace only), use the beectl add_assigned_role command:

beectl> add_assigned_role --scope enpr=mycompany --name my_assigned_role --assigned_scope wksp=myworkspace,orgn=human_resources,enpr=mycompany --role_definition acrd=workspace-viewer,enpr=mycompany --accessor <USERID>

Provide the identifier of the user for <USERID>.

Note that some users have privileges allowing them to assign roles (such as the ROLE_MGR privilege). Whenever a user assigns a role definition to another user, they are effectively creating an assigned role. If the user can see (discover) and assign (execute) permissions for a role definition, they can assign it to other users for which they have management privileges (such as USER_MGR).

Modifying Roles

You can modify any role definition by using the beectl modify_role_definition command:

beectl> modify_role_definition --role_definition <role_definition_id> [--name<name>] [--description <description>] [[--privilege <privilege_name>]...][--access_types <access_types_string>] [--always_enabled <boolean_value>]

Only use options for parts of the role definition you wish to change. For example, if you only wish to change the name, identify the role definition using the --role_definition and its identifier, and then use the --name option to specify a new name.

You can change the assignee(s) of any assigned role, adding or removing accessors, using the beectl modify_assigned_role command:

beectl> modify_assigned_role --assigned_role <assigned_role_id> [--name <name>] [--description <description>] [--assigned_scope <assigned_scope_id>] [--role_definition <role_definition_id>] [[--add_accessor <accessor_id>]...] [[--remove_accessor <accessor_id>]...]

Use the --add_accessor and --remove_accessor options to list accessors from whom you want to grant or revoke the assigned role.

Deleting Roles

You can delete roles using the beectl delete_assigned_role or command:

beectl> delete_assigned_role --assigned_role <assigned_role_id>

When you delete an assigned role, you are effectively removing it from all assignees. This changes the privileges for all affected users, so caution is advised.

You can also delete a role definition, using the beectl delete_role_definition command:

beectl> delete_role_definition --role_definition <role_definition_id>


If you attempt to delete a role definition that is currently assigned, Oracle Beehive will return an error. You must unassign the role definition from all actors in the system before you can delete it.

Creating and Managing Access Control Entities and Sensitivities

This section describes how to create and manage ACEs and sensitivities.

Any Oracle Beehive object may have any number of ACEs, collected into an Access Control List (ACL). ACLs are simply tables of ACEs, all of which apply to a single controllable entity. You never need to "create" an ACL: creating an ACE on any object automatically creates an ACL for it. If an object has one or more ACEs, it has an ACL, and if all ACEs are removed from an object, it no longer has an ACL. Oracle Beehive manages this task for you. All you need to do is create, modify, and delete ACEs according to your needs.

Sensitivities are just like ACLs, except that they are not attached to an object. Instead, a sensitivity is an ACL-template, which may be used again and again to assign the same ACL to many different objects.

This section contains the following topics:

Creating and Managing ACEs

You can create an ACE for most types of entities in Oracle Beehive.

Each ACE contains three values: the entity, which specifies where the ACE will be applied (a workspace, folder, calendar, etc.); the accessor, which specifies for whom this ACE applies (a user, members of a specified group, etc.); and a string defining access types ( +-RWOED ).

This section contains the following topics:

Viewing ACEs

To view the ACL of an object (listing all ACEs currently applied to it), use the beectl list_local_acl command:

beectl> list_local_acl --entity <entity_id>

Specify the entity using its identifier. Each ACE is listed, including its accessor and access type list.

Creating New ACEs

To create a new ACE (adding it to the ACL of an existing entity), use the beectl add_local_ace command:

beectl add_local_ace --entity <entity_id> --accessor <accessor_id> [--access_types <access_types_string>]

An ACL may only have a single ACE for each accessor. If an ACE for an accessor already exists, you must modify it to alter the access types, by modifying the ACE.

Modifying ACEs

To modify an existing ACE, use the beectl modify_local_ace command:

beectl> modify_local_ace --entity <entity_id> --accessor <accessor_id> [--access_types <access_types_string>]

Specify both the entity and the accessor, using their identifiers, to identify the ACE you wish to edit. The access type string you provide will replace the current access type string of the specified ACE.

Deleting ACEs

To delete an ACE, use the beectl delete_local_ace command:

beectl> delete_local_ace --entity <entity_id> --accessor <accessor_id>

Specify both the entity and the accessor, using their identifiers, to identify the ACE you wish to delete.

Creating and Managing Sensitivities

A sensitivity is a template ACL, containing ACEs. Users can assign sensitivities repeatedly to different objects, saving the effort of having to create the same ACEs again and again. A sensitivity also exposes the ability to set access control at the object level (explicit access control) to privileged users who do not have access to the command line.


Sensitivities are always created and managed at the workspace level of scope.

This section contains the following topics:

Viewing Sensitivities

To see a list of all sensitivities available in a workspace, first, get the workspace's unique identifier by using the beectl list_workspaces command:

beectl> list_workspaces --scope enpr=Example --type p

This produces output similar to the following:

| Workspace Name | Workspace Type | Identifier |
| SystemWorkspace | PERSONAL | wksp=SystemWorkspace,enpr=mycompany|
| beeadmin's Personal Workspace | PERSONAL | wksp=beeadmin's Personal Workspace,enpr=mycompany |
| example.user's Personal Workspace | PERSONAL | wksp=example.user's Personal Workspace,enpr=mycompany |

To list the sensitivities in a workspace, use the beectl list_sensitivities command:

beectl> list_sensitivities --workspace "wksp=example.user's Personal Workspace,enpr=mycompany"

This produces output similar to the following:

| sensitivity | name | description | sensitivity_only | delegatable |
| acsn=Confidential,wksp=example.user's Personal Workspace,enpr=mycompany | Confidential | confidential sensitivity | false | true |
| acsn=Normal,wksp=example.user's Personal Workspace,enpr=mycompany | Normal | normal sensitivity | false | true |
| acsn=Private,wksp=example.user's Personal Workspace,enpr=mycompany | Private | private sensitivity | true | false |
| acsn=Public,wksp=example.user's Personal Workspace,enpr=mycompany | Public | public sensitivity | false | true |

You can use the --name command to search for only sensitivities matching the provided string. Use the % symbol as a wildcard.

To review the ACL (all ACEs) of a specific sensitivity, use the beectl list_sensitivity_acl command:

beectl> list_sensitivity_acl --sensitivity " acsn=Public,wksp=example.user's Personal Workspace,enpr=mycompany"

This produces output similar to the following:

| accessor             | access_types         |
| grup=ALL_USERS,enpr=mycompany | +RO                   |
Listed SensitivityACL for Sensitivity 'acsn=Confidential,wksp=example.user's Personal Workspace,enpr=mycompany'

As you can see, the default personal workspace contains a default sensitivity called "Public". This sensitivity grants Read and Discover access to the members of the ALL_USERS group, which contains all users in the enterprise. Therefore, this sensitivity allows any other Oracle Beehive user to discover and read (but not modify or delete) items in the workspace marked with this sensitivity.

Creating New Sensitivities

To create a new sensitivity, use the beectl add_sensitivity command:

beectl> add_sensitivity --workspace <workspace_id> --name <name> [--description <description>] [--sensitivity_only <boolean_value>] [--delegatable <boolean_value>]

Specify the workspace scope using the --workspace option, and give the sensitivity a unique name using --name. Optionally, you can give the sensitivity a description, using the --description option; the description will be readable by users when they are choosing and assigning sensitivities.

To create a new sensitivity ACE, use the beectl add_sensitivity_ace command:

beectl> add_sensitivity_ace --sensitivity <entity_id> --accessor <accessor_id> [--access_types <access_types_string>]

Specify the sensitivity using its identifier. As with normal ACEs, sensitivity ACEs combine an accessor with an access type string. You may only have one ACE in a given ACL with the same accessor. You can use the beectl modify_sensitivity_ace command if you want to change the access type string for an existing accessor on a sensitivity ACE.

For more details on ACEs, see "Creating and Managing ACEs".

Modifying Sensitivities

To modify an existing sensitivity, use the beectl modify_sensitivity command:

beectl> modify_sensitivity --sensitivity <sensitivity_id> [--name <name>] [--description <description>] [--sensitivity_only <boolean_value>] [--delegatable <boolean_value>]

Specify the sensitivity using its identifier. Note that you add, modify, and remove ACEs from a sensitivity using the beectl add_sensitivity_ace, beectl modify_sensitivity_ace, and beectl delete_sensitivity_ace commands.

To modify an existing sensitivity ACE, use the beectl modify_sensitivity_ace command:

beectl> modify_sensitivity_ace --sensitivity <entity_id> --accessor <accessor_id> [--access_types <access_types_string>]

This command effectively replaces an existing sensitivity ACE with the new one you specify, based on the --accessor. Hence, you must specify both the sensitivity identifier and the accessor, and then optionally provide a new access type string.

Deleting Sensitivities

To delete a sensitivity ACE, use the beectl delete_sensitivity_ace command:

beectl> delete_sensitivity_ace --sensitivity <sensitivity_id> --accessor <accessor_id>

Specify the sensitivity using its identifier, and specify the accessor. The ACE corresponding to the accessor you identify will be removed.

To delete a sensitivity, use the beectl delete_sensitivity command:

beectl> delete_sensitivity --sensitivity <sensitivity_id>

Specify the identifier of the sensitivity you wish to delete.


If a sensitivity is currently assigned to any objects in its workspace, Oracle Beehive will return an error message when you attempt to delete it. You must unassign the sensitivity from all objects before it can be deleted.