Applying Security Constraints to a Security Role

Use

You can map users or groups to a security role. Security roles management enables you to apply security constraints over these security roles and, in this way, to manage the permissions of the users and groups that are mapped. You can apply different security constraints:

· Over the different resources on the server.

· Over the domains on an application that requires zones with more specific security permissions.

The users and groups that are mapped to a security role gain the same security rights as those applied over the security role itself.

In the case of the default security role administrator that contains the default user Administrator – the Administrator has permissions to manage all the resources on the J2EE Engine, since its role has permissions to perform all administrative functions.

Procedure

...

In the Security Provider Service, choose the Runtime ® Policy Configurations ® Security Roles tab. Then choose the Switch to edit mode button in the upper left-hand part of the screen.

Action	Procedure
Create a new security role	... 1. Select a component to which the security role will be applied from Components. 2. On the Security Roles tab page, choose Add. 3. In the Add Security Role dialog, specify the name of the new role and its description. The description is displayed each time a user selects the role, and allows the others users to understand the purpose of the role you create. 4. Choose OK.
Create a role reference	... 1. Select the role from which you want to create a reference to another role. 2. Choose the Role Reference button. 3. Select a role to map to from the right-hand side Security Roles list. 4. Choose Save. Your new role reference is mapped to the selected security role. We recommend that instead of creating a new security role, you use a role reference to an existing security role that has already been configured, which corresponds to the mappings you need. If you have an application and a resource in the application to which you want to apply security restrictions, you can create a role reference to the administrators security role. Now create a new security role named application_role. Specify a reference from the application_role to the administrators role. When you save the role, the users mapped to the administrators role will have access to the resource that is mapped to the application_role. The benefit for you is that if a user or a group is removed from the administrators group, you will not have to make any changes to the application_role, since you only reference the corresponding administrators role. This enables you to keep the security configuration stable.
Apply run-as-identity for a user	Select the role to mark as run-as-identity and choose Change.
Remove a security role	... Select the role from the Security Roles list and choose Remove.

Mapping Users and Groups

Use

Create the security roles using names that explain which users will be included. Then map the existing users to that group. For more information about creating new users and groups, see J2EE Engine User Management.

Once the roles are filled with users and groups, use the other services provided by the Security Provider Service to apply the constraints to the roles.

Procedure

...

1. Choose Security Provider service Policy Configurations --> Security Roles --> User Mappings tab and select the component to manage.

2. Choose the Switch to edit mode button from the upper left-hand part of the screen.

If You Want To	Then
Map a user to a role	... 1. In Security Roles, select the role to map the user to. 2. Select the user you want to map to the role from the User Tree, and choose Add.
Remove the mapping of a user to a role	... 1. Select the role to which the user is mapped to in Security Roles. 2. Select the user to un-map from Users and choose Remove.
Mapping a group to a role	... 1. Select the role to manage from Security Roles. 2. Select the group you want to map to the role from the User Tree and choose Add.
Removing the mapping of a group to a role	... 1. Select the role, where the group is mapped to from Security Roles. 2. Select the group to un-map from Groups and choose Remove.

Architecture of Security Roles

There are two types of security role in the SAP J2EE Engine:

· Application J2EE security roles that are based on the J2EE standard and which you can use to protect resources such as URLs or EJB methods.

· Server J2EE security roles with which you can protect any resources defined by the relevant service, such as Keystore Views.

Characteristics of the application J2EE security roles:

· The role is an abstract logical grouping of users that is defined by the developer.

· The role is defined in the deployment descriptor (XML files) of a particular application.

· The role consists of only a name and a description.

· The role relates only to the application for which it was defined.

Characteristics of the server J2EE roles:

· These roles can be created automatically by a service or manually by the administrator.

Purpose

The application J2EE security roles are suitable for purely static, activity-related access control. This concept is based on the assignment of authorizations by activity (such as the activity financial accountant), but not by instances (such as by cost centers). This means that all users to which the role Financial Accountant is assigned can post for all cost centers.

With the J2EE security roles, the developer can of an application can additionally decide whether he or she uses these rules purely declaratively or with programmatic role references:

· Declarative security means that the container forces access control without the developer having to program it.

· Programmatic security means that the developer uses a method to check whether a caller of an EJB or a Web resource has a specific role. The developer can control the display of individual control elements using these “role references”. In this way, for example, users to which the role queried in the reference is assigned can receive a more extensive display on the same Web page than users to which this role is not assigned. There can be a mapping between the role checked in the program (such as “USER”) and the actual security role that can be assigned to users by the administrator (such as “HR_CLERK”), that is, a different role may be assigned to the one that is actually checked in the program. If the developers of the various components of an application have used roles with different names, but with the same semantics, these can therefore be consolidated in this way.

J2EE security roles should be used purely declaratively. UME roles and the corresponding UME APIs should be used for programmatic access control.

Work Flow when Using J2EE Security Role References

The developers can use role references (programmatic security) that correspond to individual authorizations in the program of their applications. In a second step, the developers or development coordinators assign at least one security role to each role reference. These J2EE security roles are delivered. The administrator at the customer site installs the application with the respective security roles. The user administrator then assigns the security roles to users or user groups.

Work Flow with Declarative Use of J2EE Security Roles

The developers program their applications and specify the J2EE security role associated in each case in the XML file. These J2EE security roles are delivered and used as described under J2EE security role references.