Differentiating and using Authorization Concepts

Objectives

After completing this lesson, you will be able to:
  • Explain the terms UME role and JEE security role
  • Assign actions and JEE security roles to a UME role
  • Assign authorizations to users and groups

Authorization Concept of AS Java

.

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.

Appendix: Declarative and Programmatic Authorizations

Authorizations can be defined as either declarative or programmatic:

  • Declarative means that the Java container (Web container, EJB container for example) forces the access control, without the developer having to do the programming work. A security role is defined in the application (by annotation) or in the deployment descriptor of the application. With each call the container checks whether the user is assigned to the required security role.

  • Programmatic means that the developer uses a method to check whether a caller of an EJB or a Web resource is assigned to a certain authorization (security role or UME permission). The authorization check is defined directly in the source code.

The declarative approach is usually used for JEE security roles. UME permissions are always checked programmatically.

Permissions, Actions, and UME Roles

In the UME, there is a role concept with which authorizations, users or groups are assigned. These authorizations relate to authorization checks that are defined in the coding of the SAP Java application. The authorization concept in the UME uses permissions, actions, and roles.

Permissions are defined in the Java coding (programmatic authorizations). Permissions are used to provide an access control. Permissions cannot be assigned directly to a user.

An action is a collection of permissions. The developer of an SAP Java application defines his/her own actions and specifies the authorizations in the XML file actions.xml. Actions are displayed in the Identity Management. You can use the Identity Management to combine these actions into UME Roles.

UME roles group actions of one or more applications. You can assign UME roles to users in theIdentity Management.

Many of SAP's Java applications work with UME roles.

The figure shows the Purchase Order application as an example. This application consists of multiple objects, such as Create order, Approve order, into which a developer has built the corresponding authorization check directly in the coding. With UME roles, permissions (authorization objects) are defined directly in the coding and then bundled into actions by the developer. The administrator can then combine these actions into roles, and assign them to a user or a user group.

Developers can define very detailed authorizations on the basis of this concept, but the complexity is hidden behind a small number of actions. Actions are predefined by the developer, delivered to customers together with the application, and are available as an XML file. This allows a simple, clear and cross-application authorization concept for large Java applications.

JEE security roles

JEE security roles are part of the JEE standard.

A JEE Security role (also Security role) is an abstract logical definition that protects access to an application, a service, or another resource. The security role consists of only a name and a description. The JEE Security role relates only to the application for which it was defined.

JEE Security roles allow an access check for JEE applications. The authorizations are usually defined declarative. A developer creates a security role for each application object requiring protection. The protected application, its protected modules, classes or methods can be used by a user only if the administrator has assigned the users or groups to the JEE Security role.

The figure shows the Purchase Order application as an example. For this application, a developer creates objects such as Create order, Approve order, and so on. If you are using JEE Security roles, a JEE Security role must be created for each object. The JEE Security role is defined either in the deployment descriptor (XML file) or directly in the application coding.

In addition to the security roles specified by the developer, the UME generates further security roles that are valid for the entire application. The advantage here is that these roles can be combined into one application-wide security role for several security roles with the same name. The administrator has only to concern himself/herself with the assignment of these security roles. You see the following behavior in the JEE standard: If a security role of a module is assigned to a user and he/she accesses another module of this application that is protected with a security role of the same name, he/she is granted access. The UME concept of combining the security roles of an application therefore only makes life a little easier for the administrator; it is not a security restriction. These security roles dynamically generated by the UME appear in the Identity Management as actions of the type J2EE (Caution: for backwards compatibility reasons it is called J2EE and not JEE, which would be correct from a specification point of view!).

As a user administrator, you can now create UME roles that contain security roles (as actions) and assign these to users and groups. Using the detour of the UME roles, authorizations can in turn be assigned across all applications.

There are some special actions you can use for segregation of duties. These are Manage_Role_Assignments_SoD and Manage_Roles_SoD. A user with the activity Manage_Role_Assignments_SoD is able to assign roles to any user but himself. A user with the Manage_Roles_SoD activity is able to create roles. The user is able to maintain all roles (assign actions) exept roles which are assigned to himself. Do not combine the following actions: Manage_Users, Manage_Groups, Manage_Roles, Manage_all_Companies, Manage_Role_Assignments_SoD and Manage_Roles_SoD.

Creating and Assigning UME Roles

You can use the Identity Management to maintain UME roles. You perform both the assignment of UME actions to UME roles and the assignment of JEE security roles to UME roles. UME Actions and JEE Security roles are displayed as actions in theIdentity Management.

After logging on with an administrator user, select the appropriate UME Role, display the assigned UME Actions, and change the UME Role, if necessary. Then assign the UME Role to a user and/or a group.

http://host:port/useradmin und anmelden

Im Dropdown Rolle auswählen und Rolle anlegen

Eindeutiger Name und Beschreibung eintragen.

Registerkarte Zugeordnete Aktionen anwählen und die Aktionen vscantest, System_Admin und Read_All suchen und hinzufügen.

Sichern

Oben auf Start klicken und dann zur gerade angelegten Rolle scrollen und diese markieren. Auf Registerkarte Zugeordnete Aktionen klicken und den screenshot ziehen.

The advantage of having both actions and permissions is:

  • Application developers can define finely grained permissions, but can hide the complexity by defining only a few UME actions.
  • As the UME actionsare normally defined in an XML file, they can be changed according to your requirements when you install the service.
  • Administrators can assign UME Actionsto UME Roles in the Identity Management. Permissions are not visible here.

Example

The Identity Management is an application running on the UME. The application defines permissions in the code for activities such as changing a user's profile or modifying roles. In the XML file an UME ActionManage_Roles is defined that groups together all permissions that a user requires to administrate UME Roles. This action includes permissions for viewing, modifying, and deleting UME Roles.

You could create a role called Role Administrator and assign the UME ActionManage_Roles to it. Then you could assign any administrator that requires permissions to administrate roles to the Role Administrator role.

It is particularly important for the administration of authorizations that the Java application UME itself provides with a large number of actions. These UME actions permit the precise definition of the rights which users have to principles (e.g. "display all users" or "maintain all groups").

Optional: Create and Assign UME Roles and UME Groups

Business Example

SAP systems perform authorization checks within the SAP NetWeaver platform with a role-based approach. This means that you assign authorizations to users in this specific system on the basis of group and role handling. The following tasks should introduce some maintenance aspects which are typically performed by administrators o power users specialized on authorizations.

Valid for this Exercise

ParameterValue
SAP ClassroomWTS
SAP System IDSMJ
Host name (FQDN)smhost.wdf.sap.corp
Operating SystemWindows
Central Services InstanceSCS90
Primary Application Server (PAS)J91
Java Administrator / passwordtrain-## / <your password>
Always replace ## with ...<group no.>

Task 1: Handle Authorization for the UME Administration

You want to check which authorizations a newly created user receives.

Steps

  1. In WTS use the Identity Management to check if the user NEW-## has been created.

    1. In the SAP Solution Manager WTS start a Web browser.

      Note

      If you use two different browser (for example Edge and Chrome) you could use your train-## user in one and the NEW-## user in the other browser at the same time without problems. In addition, you are not forced to logon/logoff multiple times, but simply refresh the respective browser.

      • Recommendation:
      • Browser 1: Edge = user: train-##
      • Browser 2: Chrome = user: NEW-##
    2. Browser 2 Chrome: Enter the URL http://smhost.wdf.sap.corp:59100

    3. Use User Management link on the start page or change your URL to:http://smhost.wdf.sap.corp:59100/useradmin

    4. On the Logon Page enter:

      • User*: NEW-##
      • Password*: <your initial password>.

      Hint

      You have created this user in a previous exercise.

    5. Change your initial password:

      Old password:*<your initial password>
      New password:*<your productive password>
      Repeat New password:*<your productive password>
    6. Which message do you receive at the top of the screen? __________________________________

  2. Log on with your AS Java user ID train-## and password. Use the Identity Management to add authorizations to user NEW-##>.

    1. Browser 1 Edge: Switch to the browser with your train-## user or start a new logon with URL http://smhost.wdf.sap.corp:59100/useradmin and authenticate.

      Note

      Optional: press Log off to makes it more complex (not recommended). The exercise is described based on the recommendation using two different browsers (see above).

    2. In the Identity Management application search for the user NEW-## and press Go.

    3. Select user NEW-##.

    4. Press Modify.

    5. Move to tab Assigned Roles.

    6. In the area Available Roles - Search Criteria (on the left part of the splitscreen editor) enter *READ* as search term and press Go.

    7. Select the line NWA_READONLY.

    8. Press Add.

    9. Press Save.

  3. Check the whether the authorizations of user NEW-## have changed in comparison to the initial situation. For this task use again the Identity Management.

    1. Browser 2 Chrome: Switch to Browser 2 which was used by user NEW-##.

    2. Press Refresh (F5) in Browser 2.

    3. Did anything changed? Hopefully! If not, the assignment wasn't correct

    4. If you see the Identity Management application (or even NWA content), continue, search for the user NEW-## and press Go.

    5. Select user NEW-##.

      Hint

      Notice that you only have authorizations to read, but not to do any changes. That is exactly what the administrator (train-##) assigned as a role: NWA_READONLY!

Task 2: Optional: Create and Assign a UME Role to a User

Create a new UME Rolez##_role and assign it to the user NEW-##>.

Steps

  1. Create a role z##_role that allows the users to change within the Identity Management

    1. Browser 1 Edge: Switch to Browser 1 with your train-## user.

    2. You should be still working in the Identity Management application.

    3. In field Search Criteria select Role.

    4. Press Create Role.

    5. In the Details section enter:

      Unique Namez##_role
      Descriptionz##_role
    6. Change the tab Assigned Actions.

    7. In section Available Actions (on the left hand side), enter in field Get: com.sap.sec* and press Go.

    8. In the resulting table below search for row: UME, com.sap.security.core.ume.service, Manage_All.

    9. Select this UME Action and press Add.

      Hint

      This UME Action provides for all users linked to the currently created UME Role (z##_role) the authorization to perform changes in the Identity Management.

    10. Change to tab Assigned Users.

    11. In the section Available Users (on the left hand side), enter in the field Search Criteria: NEW-##> and press Go.

    12. Select the line and press Add.

      Hint

      Now you connect your user NEW-##> to the UME Rolez##_role.

    13. Press Save.

  2. Check if your user NEW-##> is now allowed to perform changes within the Identity Management.

    1. Browser 2 Chrome: Switch to the browser with your NEW-## user.

    2. Press Refresh (F5).

    3. Search for the user NEW-## and press Go.

    4. Select the line.

      Hint

      Notice that you have now authorization to change the user.

Task 3: Optional: Create and Assign a UME Role with Actions to a Group

Create a new UME Rolez##_role_to_group with different actions and assign them to a UME Group.

Steps

  1. Check if the user NEW-## is allowed to call the application OpenSQLMonitors.

    1. Browser 2: Chrome. You should be still in Browser 2 with your user NEW-##. If not switch to Browser 2.

    2. Enter the URL http://smhost.wdf.sap.corp:59100/OpenSQLMonitors.

    3. Enter the logon data:

      • Username: NEW-##
      • Password: <Your production password>

      Hint

      The system displays an error message "Error: You are not authorized to view the requested resource" due to insufficient authorizations. The user NEW-## is not assigned to the required J2EE Security role.

  2. Create a group called z##_GROUP.

    1. Browser 1 Edge: Switch to Browser 1 with your usertrain-##.

    2. You should be still logged-on to the Identity Management application.

    3. In the field Search Criteria select Group.

    4. Press Create Group.

    5. Enter the following:

      Unique Name:*z##_GROUP
      Description:z##_GROUP
    6. Press Save.

      Hint

      Now you created a UME Group, in which you could collect one or more roles (UME Roles and/or J2EE Security role).

      Hint

      Of course we could already add the user to this UME Group, but because of educational reasons we do this later in a separate step.

  3. Create a role called z##_role_to_group and add the UME ActionOpenSQLMonitorLogonRole (which is a J2EE Security role). Add this J2EE Security role to the previously created UME Groupz##_GROUP.

    1. Browser 1 Edge: In the field Search Critera select Role.

    2. Press Create Role:

      Unique Name:*z##_role_to_group
      Description:z##_role_to_group
    3. Change to the tab Assigned Actions

    4. In the section Available Actions enter in the field Get: OpenSQLMonitorLogon* and press Go.

    5. Select the row: J2EE, Opensqlmonitor, OpenSQLMonitorLogonRole and press Add

    6. Change to tab Assigned Groups.

    7. In the section Available Groups enter in the Search Criteria: z##_* and press Go

    8. Select the line z##_GROUP and press Add.

    9. Press Save.

      Hint

      Now you linked the role z##_role_to_group to group z##_GROUP.

  4. Connect your user NEW-## to the group z##_GROUP.

    1. Browser 1 Edge: In the field Search Critera select User.

    2. Enter the user NEW-## and press Go.

    3. Select the row of the user New-##.

    4. In the Details of User TRAIN-## section press Modify.

    5. Change to the tab Assigned Groups.

    6. In the field Search Criteria enter z##* and press Go

    7. Select the line z##_GROUP and press Add.

    8. Press Save.

      Hint

      Now also the group - and therefore also the user (as member) - is connected to the previosly created UME Rolez##_role_to_group.

  5. Check if the user NEW-## is now finally allowed to call the application OpenSQLMonitors.

    1. Browser 2 Chrome: Switch to Browser 2 with your NEW-## user.

    2. You should still see the last issued error message delivered by the URL http://smhost.wdf.sap.corp:59100/OpenSQLMonitors..

    3. Press Refresh (F5)

      Result

      The error should disappear and you can see and access the Open SQL Monitorsstart page.

Result

You can administer UME Roles, assign UME Actions and handle UME Groups in the Identity Management.

Task 4: Optional: Add Authorization to your NEW-## user using the ABAP System

Add to userNEW-## authorizations for AS Java using the ABAP System SMA.

Steps

  1. Call the SAP SLD Application on the SMJ Java System and check if you have the administrative authorizations.

    1. Browser 2: Chrome: Switch to Browser 2 with your NEW-## user.

    2. Change to URL to: http://smhost.wdf.sap.corp:59100/sld.

    3. Notice the error message on top of the SAP Netweaver System Landscape Directory: "You do not have the permission...".

  2. In SMA ABAP System check who created user NEW-##, find out if your Java group z## will be shown as ABAP Role and finally add this user the ABAP Role SAP_SLD_ADMINISTRATOR.

    1. On the SAP Solution Manager WTS start SAP Logon

    2. Navigate to: Workspace → Local → 80 Application Lifecycle Management.

    3. On the right in the Connections area double-click on the first entry called 80 SMA SAP-GUI non-SNC [PAS]

    4. Enter the following:

      • User: train-##
      • Password: <Your production password>

      Note

      Because SMJ stores its users in SMA, you have the same Production password here in the ABAP System.

    5. In the OK-Code field enter transaction SU01.

    6. As user enter: NEW-##

    7. Press Change Pencil on top or Shift+F6.

    8. You should be forwarded to the Address tab. Check the field Changed by. Who is the last user changed this user?

      Note

      It might be user SAPJSF_SMJ as this user is entered in the UME RFC Destination called UMEBackendConnection,

    9. Change to the tab Roles.

    10. Enter z##* and press F4.

    11. Press Start Search. Why does your created UME Groupz##(created in the UME Console) not appear?

      Note

      Because groups created in UME Console are only created in the Java Database Schema.

      But if you create a Role in the ABAP System and the data source configuration dataSourceConfiguration_abap.xml is set, the ABAP Role will be shown in the Java Identity Management as UME Group of type R3_ROLE_DS.

    12. Change the Single Role value from z##* to SAP*SLD*

    13. Press Start Search again.

    14. Select the role SAP_SLD_ADMINISTRATOR.

    15. Press copy (the heel icon on top).

    16. Press the Save icon on top or select user → Save.

  3. Call the SAP SLD Application on the SMJ Java System and check if you have the authorization for administration. Log off and Log in again!

    1. Browser 2: Chrome: Switch to Browser 2 with your user NEW-##.

    2. You should be still located in the SLD: http://smhost.wdf.sap.corp:59100/sld

    3. Press Log Off on top of the screen.

      Note

      Sometimes refresh is not enough.

    4. Enter the URL http://smhost.wdf.sap.corp:59100/sld again

    5. Enter:

      • User: NEW-##.
      • Password: <your production password>.
      • Now you have administrative privileges in the SLD Application (no error message).
  4. Browser 1: Edge: Switch to Browser 1 with your train-## user and use the Identity Management application to find the ABAP Role SAP_SLD_ADMINISTRATOR and check which Java Role has been connected.

    1. Browser 1 Edge: You should be still in the Identity Management application.

    2. In the Search Criteria choose Group.

    3. Next to all Data Sources, in the search string field enter: SAP*SLD*.

    4. Press Go.

      Result

      You should see all SLD Roles from the ABAP system indicated by the field Data Source: R3_Role_DS.

    5. Select the Group SAP_SLD_ADMINISTRATOR.

    6. At the bottom in section Details of Group SAP_SLD_ADMINISTRATOR select the tab Assigned Roles.

    7. Select the selection field next to Search Recursively.

    8. Press Go.

    9. You should see the AS Java Role called SAP_SLD_ADMINISTRATOR indicated by the field Data Source: UME Database.

Authorisation Concept

Related Information

Online documentation for SAP NetWeaver 7.5: http://help.sap.com/nw75 in tab Use select SAP NetWeaver Library: Function-Oriented ViewSecurityIdentity Management then User Management of SAP NetWeaver for AS Java → Reference Documentation for User Management

Log in to track your progress & complete quizzes