User Mapping
Use
User mapping is used for Single Sign-On (SSO) to back-end systems. User mapping maps a portal user ID to the user ID of the back-end system. You can manage the user mapping yourself, or you can enable the users to manage their own user mapping for the systems you define. User mapping supports the following authentication methods:
· SSO using user ID and password
This method always requires user mapping. The portal ID is mapped to the user ID and password of the back-end system.
· SSO using logon tickets to ABAP-based systems
This method only requires user mapping if users have different user IDs in the SAP NetWeaver Portal and ABAP-based systems. Passwords are not mapped. To access more than one ABAP back-end system, you can define a reference system. As long as all the ABAP back-end systems use the same user ID, the user can access all the systems by mapping their portal user ID to the user ID on the reference system.
A user's portal user ID and the ABAP user ID are stored in the user's logon ticket. When the user tries to access a back-end system, the system extracts the user ID from the logon ticket.
User mapping
requires you to communicate user and password information between the portal
and back-end system at least once (during the configuration of user mapping).
When possible, avoid user mapping by using the same user ID in the portal and
back-end ABAP systems and enable SSO with logon tickets. If you cannot avoid
user mapping, configure the connection to the back-end system to use Secure
Sockets Layer (SSL) and Secure Network Communications (SNC). For more
information, see
Transport Layer
Security.
If you use a
directory server, you can store the user ID for the ABAP back-end system in
your LDAP directory. You do not need to configure user mapping. For more
information, see
Using an LDAP
Directory Attribute as the ABAP User ID.
Prerequisites
● Make sure the SAP NetWeaver Application Server (AS) Java is configured to support strong encryption.
For more
information, see
Configuring Strong
Encryption for User Mapping.
● You must define User Mapping Type, Logon Method, and (optionally) User Mapping Fields in the system properties of the systems for which you want to map user data.
For more
information, see
System Properties for User
Mapping.
● You must define a system alias for a system, otherwise the system is not available for selection when the administrator or users configure user mapping.
For more
information, see
Maintaining a System
Alias List.
Changing the default system alias does not affect user mapping. However, if all system aliases are removed, user mapping is lost to that system, even if a new system alias is created with the same name as the previous default.
● Systems only appear in the user mapping display for users, groups, and roles, when you have assigned end user permission to those users, groups, and roles for those systems in the permission editor.
For more
information, see
Setting Permissions in
the Permission Editor.
● If you configure user mapping for SSO with logon tickets to ABAP-based systems, define a reference system.
For more
information, see
Configuring a
Reference System for User Mapping.
Features
● Either users or administrators can perform user mapping.
¡ Users must always enter a password to validate their mapped user ID.
This password is not stored, but is used to confirm that the user is entering a user ID with which he or she has access to the ABAP-based system.
○ Administrators can enter a password to validate their entries.
The UME property ume.usermapping.admin.pwdprotection defines whether or not the administrator must enter a password. By default the administrator must enter one.
● You can map either a user, group, or role to a user ID in a system connected to the portal.
With reference systems, you cannot map groups or roles to a user in the reference system. You can only map a user to a user.
If you map to a single user in the back-end system, do not map to a super user or administrative user. If you use SSO with user ID and password, a malicious, but otherwise legitimate user with an HTTP sniffer program, could determine the user ID and password he or she is mapped to. If you must map to a single user, we recommend mapping to a guest user with the required rights. Do not map users to back-end accounts, which would pose a security risk if the users learned the user ID and password.
● When a user tries to access an iView that requires data from a connected system that does not support logon tickets, the portal attempts to map to a user in the remote system. The portal does this by checking for mappings in the following order:
...
a. To the portal user
b. To any groups the portal user is a member of
c. To any roles the portal user is directly assigned
User mapping does not support mappings to indirect role assignments.
If the portal does not find any mappings that apply, the iView prompts the user to enter mapping data (assuming the iView developer programmed the iView to do so).
If you do not maintain individual user-to-user mappings, map roles or groups to a user in the back-end system. If a specific user in the group needs more or less authorization in the back-end system than allowed by the role-to-user or group-to-user mappings, you can create a user-to-user mapping for this kind of exception. Do not create more than one of the same kind of mapping for the same back-end system. The portal uses the first mapping found. If you map two roles to different users in the same back-end system and you assign both roles to a portal user, you cannot be sure which mapping the portal will use.
Some applications require user mappings to be unambiguous. Applications such as Universal Worklist, perform inverse user mapping and thus require a 1:1 relationship between front-end and back-end users.
Activities
The following methods for entering mapping data exist:
● The portal administrator enters user mapping data for users, groups, and roles when configuring the portal for use.
For more
information, see
Mapping Users:
Administrator Tool.
● The user enters his or her personal mapping data in the portal.
For more
information, see
Mapping Users: User
Enters Own Data.
See also: