Portal Permissions
Portal permissions define user access rights to objects in the Using the Portal Catalog , which includes the Portal Content Directory (PCD) and the GPAL Repositories. Permissions in the portal are based on access control list (ACL) methodology.
Essentially, every portal object can be assigned directly to an individual user or collectively to groups of users through user groups and roles.
To extend initial access rights to portal content and functionality for users in the organization, the super administrator needs to delegate portal permissions as needed. For information on the initial permissions configured in the portal, see Default Permissions .
To maximize initial security, the portal ships with a minimal set of permissions assigned to its standard content and functionality. Aside from a number of exceptions, the standard super administrator role has authorization over the entire portal and its standard content.
As a result of the initial permissions, end users and administrators not assigned the super administrator role cannot initially see content in the Portal Catalog.
You use the Permission Editor to assign object permissions (see Using the Permission Editor ).
Permissions for users, groups, and roles are assigned to folders and objects displayed in the Portal Catalog. Every object in the Portal Catalog, whether in the PCD or in GPAL, inherits permissions from its parent, unless the object itself has permissions explicitly assigned to it. This is the core behavior of the permission inheritance model. For more information, see Permission Inheritance Model .
Folders and objects in the Portal Catalog each have the following permission levels:
-
Administrator: Administrator permissions determine which content in the Portal Catalog is available to a portal user in the design-time environment, and to what extent the content can be manipulated and used.
-
End user: End user permissions determine which content is available to a portal user in the run-time environment.
-
Role assigner (valid for role objects only): Determines which users, groups, or role principles are able to perform role assignments for a particular role (that is, to assign users and groups to roles, and vice versa).
For detailed information, see Permission Levels .
Permissions for Delegating Administration
In typical corporate environments, users are assigned administrative tasks according to their areas of expertise or responsibility. Permissions also define which objects are available to end users in a run-time portal environment.
Each user is granted permission to specific levels or PCD objects and portal components, which had effects on:
-
Portal Catalog: Any portal tool that displays the Portal Catalog panel filters the structure according to user permissions so that users only see what they are permitted to access. Varying levels of permissions determine which tasks a portal user is permitted to perform on the objects to which he or she has access. The Portal Catalog is displayed in both the administration and end user environments.
-
Object Creation Wizards: These wizards enable portal administrators to create content objects based on objects flagged as templates. The various permission levels determine which portal components and layouts users are able to use in the wizards.
-
Object Editors: In the various editors in the administration environment, the different permission levels determine which tasks a portal user is allowed to perform on the objects to which he or she has access, such as editing an object, copying it, or setting its permissions.
-
Runtime versus Design Time: Portal administrators use the portal to develop and administer the design-time environment. However, at the same time they use the portal as a runtime environment to perform their day-to-day tasks within the organization. Permissions can restrict which navigation roles and content (iViews, layouts, and pages) are available to portal end users in the runtime environment, thus preventing users from erroneously receiving design-time content in a runtime context.
After installing the portal, you may decide to separate the default administrator roles into more focused worksets and roles that better suit your environment. Applying the appropriate permissions to new worksets and roles will enable you to distribute administrative tasks to smaller user groups. For more information, see Delegating Administration Tasks and Understanding Preconfigured Portal Roles .
Permissions in the PCD
The Portal Catalog filters the objects it displays according to the permissions of users. The user sees only the folders and objects assigned to him or her. The permission level for each objects displayed in the Portal Catalog defines the manner in which the objects can be used by a user both at runtime and design-time.
A system administrator can set permissions in the Permission Editor to the following object types available in the Portal Catalog:
|
Object Type |
Description |
|---|---|
|
PCD objects |
Includes the following portal objects:
These objects are initially located in the root Business Objects and Portal Content folders within the Portal Catalog. Permissions set to objects in these folders provide a means for securing runtime and design-time access to them. |
|
Security zones |
Includes portal components, services, and the security zones to which they are assigned. For more information, see Security Zones . Security zones are located in the root Security Zones folder within the Portal Catalog. Permissions assigned to security zones provide a means for securing runtime and design-time access to portal components and services deployed in the portal. |
For information on setting permissions for Knowledge Management (KM) repositories and objects, see the KM documentation set.
Permissions in the GPAL Repositories
The permissions model for GPAL repositories, which contain applications, is essentially the same as for objects in the PCD, although there are differences due to the nature of the contents. Role assignment and write permission, for example, are not relevant for applications.
The following examples illustrate how permissions affect work in the portal:
-
A portal administrator launches the Portal Content Studio and can edit any of the folders displayed in the Portal Catalog. Other users may see the same object, but may not have editing rights; they can however copy the object and edit the copied instance.
-
Unreleased object templates can be assigned to a limited number of test users, so that content creators do not have access to templates that are still being tested.
-
Content developers, who build roles, should only see content objects that they are permitted to edit. For example, iViews displaying sensitive employee information, such as salaries, should not be visible. This can be done by removing end user permissions from the system object upon which the iView is based.