Start of Content Area

Object documentation Security Zones  Locate the document in its SAP Library structure


Security zones enable a system administrator to control which portal components and portal services a portal user can launch. A security zone specifies the vendor ID, the security area, and safety level for each portal component and portal service (Web services accessed through the SOAP protocol).

Access to portal components and services by authorized users is controlled by assigning portal user permissions to the hierarchical structure of vendor ID, the security area, and progressive safety levels in the portal’s security zones.


Content developers assign portal components and services to a security zone during the development phase. The security zone is defined in a portal application’s descriptor XML file. Typically, the content or system administrator is responsible for providing the appropriate security zone assignment to the content developer.

Once a portal application has been deployed in a portal, an administrator with access to the central Permission Editor must assign authorized users, groups, or roles to the security zone to which the portal component or service belongs. Security zones are displayed in the Portal Catalog in a hierarchical structure.

A portal component or service can belong to only one security zone; however portal components and services may share the same safety level. This allows the administrator to assign permissions to a safety level, instead of assigning them directly to each portal component or service, thus taking advantage of the permission inheritance mechanism, which passes the permissions from the safety level to any portal component or service located in it (see Permission Inheritance Model).

Controlling Portal Component Access through Direct URLs

Generally, portal components are accessed in the portal through an iView. However, special cases – such as the portal logon component – require direct URL access to portal applications without an iView. A user is allowed direct access by URL at runtime under the following conditions:

        The portal component or service declares its security zone.

        The user (or group or role) has been assigned end user permissions in the Permission Editor to the security zone defined by the portal component.

Controlling Portal Component Access through iViews

When an iView is launched by a user at runtime, the Portal Runtime (PRT) initially determines if the user is assigned end user permission to the role object containing the iView. If authorized, the user can view the iView’s content.

Security zones offer an extra, but optional, layer of code-level security to iViews accessed through standard role-based assignment. When this functionality is activated, the PRT also checks if the user has been assigned end user permission to the iView’s portal component in its designated security zone. Note that this check is performed after the end user permission to the iView has been approved. The user must pass both checks to view the iView’s content.

This second level of security for iViews is activated or deactivated by setting a Java VM (virtual machine) parameter using the J2EE Config Tool (for both server and instance or server only). By default, this functionality is disabled.


       This parameter also prevents unauthorized users from accessing iViews through a direct URL used outside of the portal environment.

       The current version of SAP NetWeaver Portal supports the EP 5.0 AuthRequirement property, to support backward compatibility for native EP 5.0 portal applications only.

      To activate the second level of security, do the following:


                            a.      In the J2EE Config Tool, navigate in the cluster structure (cluster-data) and select your instance node (containing a Java dispatcher and a specified number of server processes).

                            b.      Open the General tab.

                            c.      In the Java Settings pane, add the following parameter (if it does not exist) to the Java parameters box:

      To deactivate it, set the parameter to false.


1. Security Zone Configuration

The portal currently supports two methods for specifying security zones in the portal application descriptor file (portalapp.xml):

      Computed (the preferred method)

      Fully specified

The older fully specified method uses a single property for each component and service to define the vendor, security, and safety level, with each property separated by a slash (/). This method is susceptible to errors—by mixing the order of the properties or failure to include one of them—eventually causing a messy structure in the Security Zones folder in the Portal Catalog. In addition, the vendor and security area must be written for each component, even though they are generally the same for all components in the PAR, thus increasing the chances for coding errors.

The newer computed method prevents the aforementioned problems and provides support for additional portal capabilities, such as putting aside in special folders, components whose security zone is not properly defined.




This is the preferred method that enforces a standard classification methodology for security zones.

In this method, the security zone of a component is defined by creating the following properties in the portalapp.xml file in the application PAR file:

      VendorID and SecurityArea: These properties are defined in the <application-config> section, and apply to all the components and services in the PAR.

      SafetyLevel: This property is defined for each component and service.

For more information on defining the security zone in a portalapp.xml, see Permission Model.

When the portal application is deployed in the portal, the full security zone is then automatically generated by the PRT using the three properties and the names of the components and services:



For example:

In the Permission Editor, the above computed security zone is visualized as follows in the Portal Catalog:

      Security Zones  


                  NetWeaver.Portal (security_area) 

                        high_safety (safety_level)   



                                          DBTest (component_name)

Fully specified

In this method, the security zone is defined in the portal application descriptor by single property: SecurityZone

The syntax of this property can be any slash-separated (/) string to define the security zone hierarchy; however, either of the following formats is recommended:



For example: 


This method will be deprecated in a future release. It is currently supported to provide backward compatibility.


When portal applications are deployed in the portal, the following rules apply with creating the respective security zones in the portal application repository:

      If the portal application specifies a SecurityZone property (fully specified method), its value will take precedence if the portal application also specifies the VendorID and SafetyLevelproperties (computed method).

      Any component that does not have a proper vendor, security area or safety level property are listed under an UndefinedVendor, UndefinedSecurityArea or UndefinedSafetyLevel folder in the appropriate location in the Security Zones folder in the Portal Catalog. This enables administrators to easily locate components whose PAR has been deployed without the proper security zone properties.

To modify the assigned security zone of a portal application, modify the portal application descriptor file and then redeploy it in the portal.

2. Initial Safety Levels

The portal defines the following standard safety levels for initial portal content to which out-of-the-box groups and roles are assigned permissions (note that the description of each safety level is based on the end user permission setting only, regardless of the administrator permission setting):

Safety Level


No Safety

Anonymous users are permitted to access portal components defined in the security zone.

Low Safety

A user must be at least an authenticated portal user to access portal components defined in the security zone.

Medium Safety

A user must be assigned to a particular portal role that is authorized to access portal components defined in the security zone.

High Safety

A user must be assigned to a portal role with higher administrative rights that is authorized to access portal components defined in the security zone.

For information on which initial groups and roles are assigned to the standard security zones shipped with the portal, see Default Permissions.

Customers are highly recommended to use this convention and the standard safety levels when deploying custom-made applications in the portal.

3. Assigning Permissions to Security Zones

iViews automatically inherit their permissions from the role to which they are used; however portal components and services inherit their permissions from the security zone or safety level to which they are assigned.

Most generic portal applications intended for standard users in an organization should apply to either the no safety or low safety levels, and no additional role-specific permissions need to be assigned to their security zones. The reason for this is that the Everyone and Authenticated Users groups are by default assigned end user permission to the no safety and low safety levels, respectively, and thereby permit all anonymous and authorized user activity already.

The medium safety and high safety levels are typically reserved for sensitive applications, which require permission assignments that are targeted to specific users, groups, or roles.

You assign permissions to security zones in the same way you assign permissions to content and folders in the Portal Catalog. See Setting Permissions in the Permission Editor.

Caution Important Notes


      Security zone functionality is only operational when the PRT is set to production mode. See File Based Configuration Properties.

      To prevent a complete lockout situation that prevents access to the portal by all users, including super users, you must make sure that all portal groups representing anonymous users (for example, the Everyone group) have end user permission enabled for the safety level that permits anonymous access to portal components and services accessed by a URL (for example, the no safety level).

Typically, you should grant end user permission to the Everyone group in the following standard security zones that are shipped with the portal:




End of Content Area