.
Authorization Concept
Authorization checks are built into a Java application. Here you can differentiate by different objectives:
only available in English

Protecting access to an application: This is done using the check to see whether the appropriate JEE Security Roleis assigned to the requesting user. If the user does not have the required role, an error message is displayed, and access is denied.
Protecting access to individual activities: When requesting a special activity, for example Delete, the system checks whether the required JEE security role or UME action is assigned .
Protecting the use of objects (folders or documents for example): This is done by using the Access Control List (ACL).
With all the types of authorization check specified, the developer needs to define the authorizations query in the application. The developer decides which type of authorization check is to be used. This means in practice that the application determines which of the following, JEE security roles, UME permissions or UME ACLs, is used.
JEE security roles are part of the JEE standard. UME permissions are an SAP-specific concept. Basically, you can define the same authorization checks with JEE security roles and UME permissions. Certain programming techniques for SAP applications that enhance the JEE standard require the use of UME permissions however. Therefore, an administrator should be familiar with both concepts.
Authorization Checks
The AS Java supports the following authorization checks:
- Activity-related access control with security roles for applications (JEE standard, therefore we will use the term JEE security roles): The developer defines these roles in the deployment descriptors for his or her application. The administrator maps the users to the corresponding roles.
- Instance-related access control with roles (we will use the term UME roles): Using these roles, you specify which activities a user can execute on AS Java. You can also specify which instances a user can access.
- Instance-related access control with access control lists: They are suitable for protecting many objects (that is, instances). In this case, you define an access control matrix that contains a subject (role), a predicate (type of access), and the object (instance to be protected). Only users that are mapped to at least one of these roles can access this resource.
For UME Access control listsACLs, you can only manage these ACLs in the application context and will not be discussed in detail here.