Architecture of Security Roles 

There are two types of security role in the AS Java:

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

 

See also:

·        Mapping Users and Groups: You assign J2EE security roles to users in this way.

·        Managing Security Roles: You create server roles in this way.

·        Managing Resources: You assign server roles in this way.