Security Zones

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 content.

Security zones offer an extra, though optional, layer of code-level security to iViews accessed by means of the 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 content.

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

Using the Config Tool, add the parameter -Dcom.sap.nw.sz=true to the Java Settings. To deactivate it, set the Dcom.sap.nw.sz parameter to false .

For more information, see Configuring JVM Parameters .

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 ID, security area, and safety level, with each property separated by a slash (/). This method is susceptible to errors, such as mixing the order of the properties or failing to include one of them, which can cause a messy structure in the Security Zones folder in the Portal Catalog. In addition, the vendor ID and security area must be written for each component, even though they are generally the same for all components in the portal application, also increasing the risk of coding errors.

The newer computed method avoids the above-mentioned disadvantages and also provides support for additional capabilities, such as isolating in a separate folder those components whose security zones are not properly defined.

Security Zones
  sap.com
    NetWeaver.Portal
      high_safety
        com.sap.portal.prt.cache
          components
            DBTest
                           

When portal applications are deployed, the following rules apply for 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 Vendor and SafetyLevel properties (computed method).

• Any component that does not have a proper Vendor, SecurityArea or SafetyLevel 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 of applications deployed without the proper security zone properties.

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

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):

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

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

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 .