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.

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.

Profile Generator

Tool for generating roles. The authorization administration generates a role in the profile generator based on transactions, reports, or Internet links that contains the activities for the work area of an employee.

Creating a Background User

Use

If you want to perform IDoc inbound processing in the background, you require a background user in every child system that you can use instead of your own user name to schedule the background jobs in transaction SM37.

Procedure

...

1. In the child system, choose Tools ® Administration ® User Maintenance ® User (transaction SU01).

2. Create a background user in accordance with the naming convention for system users (such as CUA_PRD_BACK).

3. Assign the user type System to the user, and deactivate the password (see Logon Data Tab Page).

4. Assign the role Z_SAP_BC_USR_CUA_CLIENT_BATCH to the user.

5. Save your entries.

Single Sign-On with Logon Tickets

Purpose

Logon tickets represent the user credentials. The portal server issues a logon ticket to a user after successful initial authentication. The logon ticket itself is stored as a cookie on the client and is sent with each request of that client. It can then be used by external applications such as SAP systems to authenticate the portal user to those external applications without any further user logons being required.

Logon tickets contain information about the authenticated user. They do not contain any passwords. Specifically, logon tickets contain the following items:

· Portal user ID and one mapped user ID for external applications

· Authentication scheme

· Validity period

· Information identifying the issuing system

· Digital signature

When using logon tickets, one system must be the ticket-issuing system. This can either be the portal or another system. We recommend using the portal as the ticket-issuing system, since the portal should be a user’s single point of access to all applications.

Technically, Single Sign-On (SSO) with logon tickets works as follows:

If the portal is the ticket-issuing system:

...

1. The first time the portal server starts, it generates a cryptographic key pair. The private part of this key is used for ticket generation (for the digital signature).

2. Once the user has been successfully authenticated in the portal, the underlying SAP NetWeaver Application Server (AS) of the portal issues a logon ticket to the user. This logon ticket is stored as a nonpersistent cookie in the browser on the client.

3. Each time the user tries to access an external system from the portal, the portal sends the logon ticket with the request to the external system.

4. The external system checks that the logon ticket is valid by verifying the digital signature of the portal server. It uses the public key contained in the digital certificate of the portal server to verify this.

5. If the logon ticket is valid, the external system extracts the user ID for that system from the logon ticket.

6. The user is logged on to the external system without having to enter his or her user ID and password.

If another system is the ticket-issuing system:

...

1. The Web browser sends the user's logon ticket with the access request.

2. The underlying AS of the portal verifies the information contained in the ticket.

3. If the ticket is valid and has been issued by a trusted server, then the user is granted SSO access to the portal.

The portal AS issues a logon ticket for the Internet domain or a subdomain of the portal only.

Process Flow

To allow SSO using logon tickets between the portal and its component systems you perform the following steps:

...

...

1. Configure the portal server to allow SSO with logon tickets. See Configuring Portal Server for SSO with Logon Tickets.

2. Configure the component systems to accept and verify logon tickets. See Configuring Component Systems for SSO with Logon Tickets.

Single Sign-On with User ID and Password

Purpose

The Single Sign-On (SSO) mechanism with user name and password provides an alternative for applications that cannot accept and verify logon tickets. With this SSO mechanism the portal server uses user mapping information provided by users or administrators to give the portal user access to external systems. The portal components connect to the external system with the user’s credentials.

Since the system sends the user's logon ID and password across the network, use a secure protocol such as Secure Sockets Layer (SSL) for sending data.

Process Flow

There are different procedures depending on the requirements.

Single Sign-On to SAP Systems

You can access SAP Systems that do not support logon tickets with SSO with user ID and password. These are SAP Systems with release 3.1I. For more information, see Configuring SSO with User ID and Password to SAP Systems.

Single Sign-On to non-SAP Systems with a Java iView Developed Specifically for the Customer

The system must exist in the system landscape. For more information, see Creating Systems.

The administrator or user must map user data to user data in the system. For more information, see User Mapping.

The iView through which the user tries to access the system must be programmed to get the mapped user data from the data repository and write the user credentials (user ID and password) in a header field of the request. The system can then log on the user with these credentials. This can be done using the Java APIs provided with SAP NetWeaver Portal.

Locking or Unlocking Users

Use

Locked users are deactivated and cannot access applications. There are two ways of locking users:

· Automatically

The system can lock a user automatically if the user tries to log on too many times with the wrong password. This is a password lock. Optionally the system can unlock the user automatically after a configurable amount of time elapses. These are configured with the following settings:

¡ Maximum Number of Failed Logon Attempts

¡ Auto Unlock Time

More Information: Configuring the Security Policy for User ID and Passwords.

· Explicitly

An administrator can lock a user using the procedure described below. The administrator must subsequently unlock the account for the user to regain access to the system.

The following procedure describes how an administrator explicitly locks or unlocks a user.

You cannot unlock a password lock with this procedure if the data source is an SAP NetWeaver Application Server (AS) ABAP. Instead you must assign a new password.

More information: Constraints for UME with ABAP Data Source

Procedure

...

1. In the search results list, select the user you want to lock or unlock.

Use the advanced search to find locked users.

○ Set Password Locked to find users, whose accounts have been locked automatically (due to failed logon attempts).

If you use a directory server as the data source, searching for locked passwords finds no users. You cannot search a directory server for users with locked passwords.

○ Set User Account Locked to find users, whose accounts have been locked explicitly by the administrator.

2. Choose Lock or Unlock as required.

You are prompted to write a reason for locking/unlocking the user. This text is sent to the user if you have enabled notification e-mails. It is also stored in the user’s account history.

3. Enter a text and choose Lock or Unlock.

Approving or Rejecting Users

Use

If you have configured user management to use companies, users can register themselves at logon. If they specify a company in their registration request, their request must be approved or rejected by a user administrator. For more information, see Companies and Self-Registration with Approval. This section explains how administrators can approve or reject a user’s registration request.

Prerequisites

● You have configured self-registration.

More Information: Configuring Self-Registration

● You have configured companies.

More Information: Configuring Companies

Procedure

To approve users that have registered themselves:

...

1. Select a company.

Only overall user administrators can choose all companies. Company administrators can only approve users in their own company.

a. Choose Change Company Selection.

b. In the list, select the company for which you want to find unapproved users or choose - ALL - if you want to find unapproved users for all companies.

c. Choose Save Company Selection.

2. Search for unapproved users.

a. Select User as the type of object you want to search for and choose Advanced Search.

b. On the General Information tab, select Unapproved Users.

c. Choose Search.

A list of unapproved users appears.

3. In the list, select the user or users that you want to approve and choose Approve.

To reject users that have registered themselves, choose Deny.

Managing Users, Groups, and Roles

Use

This function enables you to create, modify, and delete users, groups, and roles with the user management engine (UME). This enables you to define these objects so you can then group them according to your access management strategy.

Prerequisites

To manage users, groups, or roles, you must be assigned a role that includes the relevant actions or combination of actions. For example, to assign roles to users, your role assignments must include UME actions that enable you to change both principals, roles and users, such as UME.Manage_Roles and UME.Manage_Users. The figure below summarizes the UME actions available by default in the SAP NetWeaver Application Server (AS).

UME Actions According to Principal and Role

Along the top of the figure is a list of role archetypes. For example, if you are an overall administrator, under Administrators All is a list of actions appropriate to that role. The rows represent the different permission areas or principals for which the actions are relevant. For example, the top row of blocks lists actions relevant to working with users, from full access to read-access to only your own profile. The last two rows refer to specific functions, such as permission to access the import and export functions, or profile-specific actions. Some actions are subsets of other actions. For example, UME.Manage_My_Profile includes UME.Manage_My_Password. For a detailed description of these UME actions, see Standard UME Actions.

Standard UME roles include such actions. The UME role Administrator includes UME.Manage_All, which enables you to display and change everything. By default, administrator roles are only assigned to administrators.

Features

Integration with ABAP User Management

If your system is configured to use user management of an AS ABAP, PFCG roles from the ABAP system are displayed as groups in the user administration console. You cannot change or delete these groups using Identity management. The only possible action is to assign UME and security roles to them. You can create new groups, which are then stored in the database of the AS Java and are not created as PFCG roles in the ABAP system. For more information, see AS ABAP User Management as Data Source.

Principal Locking

Identity management locks principals you are currently editing. Other users, who attempt to edit the user, group, or role you are editing, receive a warning that the principal is being edited by another user. The lock prevents multiple users from editing the same principal and accidentally overwriting each others’ work.

This lock only applies to identity management (either stand-alone or integrated into the SAP NetWeaver Administrator or SAP NetWeaver Portal). If you use another application or access the principal with back-end tools, such as management tools for a directory service, the lock does not apply.

The lock is session based.

· If you open another browser window within the same session, for example, in Microsoft Internet Explorer by typing CTRL + N, the lock does not apply. Both windows can simultaneously edit the same principal.

· If you open another browser window in a new session, for example, by choosing the browser application from the Microsoft Windows Start menu, even if you log on to the identity management application as the same user, you cannot simultaneously edit the same principal.

Activities

With identity management, you can perform the following activities:

Activity	How to Perform the Activity
Search for a user, group, or role (simple search)	... 1. In the search area, choose the type of object you are looking for: user, group, or role. 2. Enter a string to search for. The search function searches for this string in the user ID (users only) and name. Use the asterisk (*) as a wildcard. If you do not enter any text, the search function returns a list of all users, groups, or roles, depending on the object you chose. 3. Choose Go. A list of search results appears in the Search view. ● When searching for portal roles, you can only search for the URL path below the portal content directory (PCD). You cannot search for the full path. ● You can narrow the search by selecting the data source you want to search, if there is more than one data source. A federated portal network adds some complexity. For roles only, you can search remote data sources, meaning remote portal systems in your network. If you search All Data Sources this includes the remote portals. For all other principals (users, groups, and actions) the search only includes the data sources relevant to your local portal.
Search for a user (advanced search)	... 1. In the search area, choose User as the type of object you are looking for. 2. Choose Advanced Search. 3. Enter your search criteria in the required fields in the various tabs. 4. Choose Search. A list of search results appears in the Search view.
View detailed information on a user, group, or role	In the search results list, select the user, group, or role. The detailed information appears in the Details view.
Create new user, group, or role	1. In the search area, choose the type of object you wish to create. 2. Choose Create. 3. Enter data as required in the Details view.
Copy an existing user	... 1. In the search results list, select the user you want to copy. 2. Choose Copy to New. 3. Enter a logon ID and define a password. 4. Choose Save.
Change existing user, group, or role	... 1. In the search results list, select the user, group, or role you want to change. 2. Choose Modify. 3. Change the data as required. 4. Choose Save.
Delete a user, group, or role	We recommend that you do not delete users, rather lock the user and set the expiration date of the account. Only delete a user after a period of time in accordance with your local auditing regulations. ... 1. In the search results list, select a user, group, or role. 2. Choose Delete. If you delete a user, you are prompted to write a reason for deleting the user. This text is sent to the user in a notification e-mail, if you enabled e-mail notification. You cannot delete a portal role. You can only delete the group, user, and user mapping assignments. To delete the role itself you must do that with the portal content tools.
Change the logon alias of a user	To perform this activity, you must enable the use of a logon alias. For more information, see Using Basic Authentication (User ID and Password). ... 1. In the search results list, select a user. 2. Choose Modify. 3. Choose the Additional Information tab. 4. Change the data as required. 5. Choose Save.
Lock or unlock a user	See Locking or Unlocking Users
Approve or reject a user	See Approving or Rejecting Users.
Generate a new password for a user	See Password Management.
Assign a user to a group or a role	See Assigning Objects to Roles or Groups.
Move a user to another company	See Moving a User to Another Company.

UME Roles and Portal Roles

In the portal, you can manage both user management engine (UME) roles and portal roles. Both types of roles determine what users can do, but each with a different focus. The following table lists the main differences between these two types of roles.

Comparison of UME and Portal Roles

UME Roles	Portal Roles
Are a container for UME actions (actions are sets of Java permissions).	Are a container for portal content (iViews, worksets, folders, and so on).
Define a set of authorizations. By assigning a UME role, you define what authorizations a user has to run applications on the J2EE engine. The authorizations are defined by the UME actions in the role.	Defines how content is grouped together and how it is displayed in the portal. By assigning a portal role, you define which content a user sees in the portal. Like UME roles, you can assign UME actions to portal roles.
Are stored in the user management tables of the J2EE database.	Are stored in the Portal Content Directory (PCD) tables of the J2EE database.
Are created with identity management.	Are created in the Role Editor of the Portal Content Studio.
Protect access to applications on the J2EE engine.	Constitute a small part of the authorization concept of the portal. When you assign a portal role to a user or group, they get end user permission on the role. You can define role assigner permission on a portal role. Users or groups that are granted role assigner permission on a portal role can assign the portal role to users or groups.

Tools

The tools need to manage UME and portal roles are identity management and the Portal Content Studio. The following table lists the main differences in use of these tools.

Comparison of Identity Management and Portal Content Studio

Activity	Identity Management	Portal Content Studio
Create and edit roles	UME roles	Portal roles
Assign UME actions	UME roles and portal roles	Portal roles
Assign roles to users and groups	UME roles and portal roles	None. Can assign portal permissions for PCD objects to users and groups.

To perform these activities you need the required permissions.

More Information:

● Managing Users, Groups, and Roles

● Role Assignment

Example

Carmen Fernandez is assigned to the UME role Administrator and no other role. She has full administrator authorizations on the J2EE Engine, but does not see any content in the portal. In contrast, Oleg Semenov is assigned to the portal Super Administrator role. He can see all the administrator functions when he logs on to the portal, and he has the corresponding authorizations on the J2EE Engine.

UME Actions in the Portal

Use

The user management engine (UME) uses UME actions to enforce authorizations. An action is a collection of Java permissions that define which activities a user can perform. UME actions can be assigned to UME roles or portal roles. If a role with a UME action is assigned to a user, the user gains the authorizations provided by the action. The UME verifies that users have the appropriate UME actions assigned to them before granting them access to UME iViews and functions. Other applications can also define or check for actions.

The following table lists the UME actions assigned to portal roles by default.

Portal Roles with Default UME Actions

Portal Role	Assigned UME Actions
Delegated User Administrator	UME.Manage_Users UME.Manage_Role_Assignments
Every User Core Role	UME.Manage_My_Profile
Standard User Role	UME.Manage_My_Profile
Super Administrator	UME.AclSuperUser UME.Manage_All
System Admin	UME.System_Admin
User Administrator	UME.Manage_All

Some UME actions are defined specifically for the portal environment:

· UME.AclSuperUser

· UME.Manage_Role_Assignments

· UME.Remote_Producer_Read_Access

· UME.Remote_Producer_Write_Access

Integration

In the portal, you can assign UME actions to portal roles with the Role Editor. Each UME action is listed as a property in the Property Editor for roles. Set an action to Yes to assign it to the portal role and change the role's authorizations. This information is recorded in the Portal Content Directory (PCD), which is why you cannot use the delete function of identity management to remove actions from a portal role. When try to delete the role with identity management, the UME only removes the user and group assignments. You must edit the role manually either in identity management or the Role Editor.