Permission Levels

Definition

All objects in the Portal Content Directory (PCD) and the GPAL repositories contain a number of permission settings and levels, which determine their availability in the portal administrative environment (design time) and the end user environment (runtime). Role objects have an additional permission setting for defining which portal administrators are authorized role assigners.

Many portal framework interfaces appear in both the portal runtime and design-time environments, but may operate differently; for example, PCD objects displayed in these respective environments must be filtered so that administrators accessing these tools as end users do not receive objects that are assigned to their administrative role. The ability to differentiate also protects runtime content from inadvertent modifications by portal administrators in the portal runtime environment. For example, a portal user with administrator privileges may accidentally personalize a page in the end user environment. At runtime, it is essential to filter in content that is intended only for runtime, and filter out design-time content.

Note that certain portal runtime tools also run in portal design-time environments. For example, previewing objects in the Portal Content Studio is a runtime activity.

Note

If a user is assigned multiple permissions for a given object, the permissions are aggregated and the higher permission setting prevails. For example, if a user is assigned full control administrator permission through his or her role, and also read/write administrator permission through a group-assigned permission (of which he or she is a member) to the same object, the user will have full control administrator permission.

Structure

The available permission settings are divided as follows:

Administrator
End user
Role assigner (for roles and Portal Catalog folders only)

Figure 1: Permission levels: (i) administrator; (ii) end user; and, (iii) role assigner

See following text for relevance to portal objects.

Administrator Permissions

Administrator permissions control objects in the design-time environment of the portal. Administrator permissions contain different levels of permissions, as described in the tables below.

Administrator Permissions for Content

Permission levels for the administrator of portal content are as follows.

Permission Level	Description
For roles, worksets, pages, iViews, folders, systems, and layouts
Owner	Provides all permissions permitted by full control (see below) and also enables the authorized user/group/role to modify the permissions of the object.
Full Control	Provides all permissions permitted by read/write (next row), and also enables the authorized user/group/role to delete the object. The use of the Cut action in the Portal Catalog requires at least administrator full control permission to an object or folder being cut to the portal clipboard.
Read/Write	Provides all permissions permitted by read and write (next row), and also enables the authorized user/group/role to: Add to and remove child objects from a parent object Edit the object properties The use of the Paste action in the Portal Catalog require at least administrator read/write permission to the destination folder in which an object or folder is being pasted.
Write	This permission setting is not selectable from Permission Editor. It is relevant only to folders in the Portal Catalog and not to objects in the folder. The permission level is transparently applied by portal applications at the API level to folders that require it. A Folder with write permissions allow authorized users to create objects in it. This permission can be used to allow the end user to create and share content. To support this, the Everyone group could be granted write permission to a particular folder intended as a container for all users in the group to share any content they create in it.
Read	Enables the authorized user/group/role to: View the object in the Portal Catalog using the browse and search capabilities. Open the object in its respective primary and secondary editors in read-only mode; the object cannot be modified. To create instances (delta links and copies) from the object. To gain access to and choose templates in the object creation wizards. The use of the Copy action in the Portal Catalog requires at least administrator read permission to an object or folder being copied to the portal clipboard. This permission level can be used to prevent portal administrators from editing a particular object, while still allowing them create an instance of the source and use the new instance in any way. For example, if you create a delta link instance of an object with read permission and place it in a folder with read/write permissions, you may fully edit the delta link object. Caution If the object is not intended for end users, make sure that the destination folder does not have end-user permissions .
None	The user is not granted access to the object or folder in any administrator tool displaying the Portal Catalog. This setting is useful if you are providing content to a role that is purely runtime-based. If this is the case, you need to assign end-user permissions (see below). Note The none setting indicates that the relevant user/group/role does not have any administrator permissions for the selected object.

Administrator Permissions for GPAL

The GPAL repositories expose portal applications and services to authorized users, typically the content administrator and super administrator. The only relevant administrator permission levels for applications are none , read , and owner . Application properties cannot be modified from Permission Editor.

Permission Level	Description
None	Prevents the user from seeing the application in the Portal Catalog.
Owner	Enables the portal administrator to view the content in the GPAL repositories, to view the application properties in the Property Editor, to preview applications, and copy and recreate them in the PCD.
Read	Since GPAL contains applications and services, which cannot be edited by administrators, the capabilities provided by the read and owner permissions are the same.

Administrator Permissions for Security Zones

Following are the administration permission levels for security zones. Security zones protect applications; therefore the administrative permissions Full Control, Read/Write, and Write are not applicable. Permissions for security zones are set in the Security Zones folder in the Portal Catalog.

Permission Level	Description
Owner	Provides all permissions permitted by read (see below) and also enables the authorized user/group/role to modify the permissions of the security zone*.
Read	Security zones*: Enables the portal administrator to see the security zone in the Portal Catalog. The permissions of the security zone cannot be edited.
None	Security zones: Prevents the assigned user from being able to see the security zone in the Portal Catalog.

Note

By default, the standard super admin role has owner permission to all objects in the PCD. You cannot delete or modify this permission or other default permissions assigned to the super admin role. This is to prevent a complete lock-out situation in the portal if the role or user who has owner permissions is deleted by accident. The super admin role also has end-user permission (see below).

End User Permission

The end-user permission setting is valid for objects running in portal runtime components.

The end-user permission setting is either enabled or disabled . Objects whose end-user permission is enabled affect the following areas in the portal:

Portal Catalog: Portal utilities that display the Portal Catalog (such as page personalization) in any "end-user" runtime environments only display objects that have end-user permissions. This does not include design-time environments, such as the Portal Content Studio.
Direct URL access to portal components: Authorized portal users may access restricted portal components that need to be accessed by URL without an intermediate iView, such as the portal logon component, if they are granted permission in the appropriate security zone. For more information, see Security Zones .

Note

The availability of roles at runtime in the navigation iViews (top-level navigation and detailed navigation) is determined by the users, groups, and roles assigned to a role principle in the Role Assignment tool. The end-user permission setting on role objects has no effect on the runtime availability of roles in the portal navigation.

For roles, however, this permission setting does enable you to define which users/groups/roles are able to preview the role content using the portal design-time tools.

For example, you may assign administrator permissions to a content developer to work with a role in the Role Editor, but prevent that person from being able to preview any pages or iViews assigned to the role.

Notes about the end-user permission setting:

By default, the super admin role has end-user permission enabled on all objects in the PCD. You cannot delete or modify this permission or other default permissions assigned to the super admin role.
If an iView is based on a system object defined in your system landscape (see Defining the System Landscape ), you must assign end-user permission for the relevant user, group, or role to the system object, as well. End-user permission assigned to a system permits the iView to retrieve data from the respective back-end application through the system object at runtime.
End-user permission can also be assigned to security zones to offer an additional layer of code-level security to iViews that are accessed through standard role-based assignment. For more information, see Security Zones .
A portal user with administrator permission for a given object does not imply he or she automatically has end-user permissions to that object. For example, if a user has full control on an iView, but does not have end-user permission, the iView will not appear in the user's list of available content when personalizing a portal page.
The end-user permission allows end users to use the page and iView personalize interfaces; however, it does not control which iView properties are viewable and personalizable in the runtime environment. This is determined by the personalization settings configured by the content owner in the Property Editor; see "End-User Personalization" in Defining Property Attributes .
In the runtime Page Personalization user interface, only users that have end-user permission will be able to see the object. Even if a user has full control permission on an iView, but no end-user permission, the iView will not be displayed in the page and iView lists. On the other hand, objects for which a user has only end-user permission, without administration permissions, will not appear in the content administration environment.
The end-user permission has no relevance to objects of type: rule collection, portal desktop and portal theme. Portal desktops and themes are assigned to users at runtime through rule collections. For more information, see Understanding Portal Display Rules .
End-user permission is not relevant for GPAL repositories or their contents.

Role Assigner Permission

The role assigner permission setting is available to role objects. It allows you to determine which portal users are permitted to assign other users, groups, or roles to the role principle using the Role Assignment tool (see Assigning Roles ).

Note

Role assigner permission can also be set to folders in the Portal Catalog (only for subfolders under the root Portal Content folder). This setting is, however, only valid for any role objects that inherit their permissions from the folder in which they reside.

Within a role object in the Permission Editor, you may authorize role assigner permissions to the level users, groups, or roles.

In addition, it is possible to set the UME.Manage_All property to Yes in a role object (from the Role Editor) so that any user who is part of that role principle, will automatically be able to use the Role Assignment tool to assign users, groups, and roles to other role principles. When you edit any role object in the Permission Editor, all roles that have UME.Manage_All = Yes will be listed in the role you are editing and the role assigner permission will be enabled; note that this permission setting is read-only, meaning you cannot disable it in the Permission Editor.

Note

After changing the UME.Manage_All property for a role object in the Role Editor, you need to restart the aclutil service in SAP NetWeaver Administrator. For more information, see Starting and Stopping Portal Services . You need to know:

The application name - com.sap.portal.admin.util
The service name - aclutil