User Mapping and the Portal 

Use

User mapping is only necessary for Single Sign-On (SSO) when users have different user IDs in the portal and in the back-end systems.

 

When possible, avoid user mapping by using the same user ID in the portal and back-end ABAP systems and enable SSO with tickets. If you cannot avoid user mapping, configure the connection to the back-end system to use Secure Sockets Layer (SSL) or Secure Network Communications (SNC).

More information: Transport Layer Security

If you cannot avoid different user IDs in the portal and back-end systems, you can use user mapping to enable SSO. With user mapping you define systems in the portal system landscape. Then for the defined systems you map portal users to back-end system users with the user management engine (UME). When an application attempts to connect to a back-end system, the  portal requests the connection information from the portal system landscape.

If the system is configured for user mapping, the portal system landscape queries the user management engine (UME) about any user mapping for the current user. The portal uses this information to establish a connection to the target system.

There are the following types of user mapping:

·        User mapping with tickets

·        User mapping with user ID and password

User Mapping with Tickets

This method maps a portal user with a back-end user in a reference system. The reference system represents the user ID to use in all back-end systems in your system landscape that require SSO with tickets. When the portal user receives a ticket from the portal, the portal writes the back-end user ID of the reference system into the ticket. When the user accesses the back-end system, the back-end system extracts the user ID it requires from the ticket.

More Information:

●      Configuring User Mapping with Tickets for SSO

●      Using an LDAP Directory for User Mapping with Tickets for SSO

User Mapping with User ID and Password

This method maps a user, group, or role with a user ID in the back-end system. When the application tries to connect to the back-end system, the UME tries to map the user to a user in the remote system. The UME does this by checking for mappings in the following order:

...

       1.      To the portal user

       2.      To any group the portal user is a member of

       3.      To any roles the portal user is directly assigned

User mapping does not support mappings to indirect role assignments

The portal uses the first mapping found. If the portal does not find any mappings that apply, the application prompts the user to enter mapping data, assuming the application developer programmed the application to do so.

 

If you map to a single user in the back-end system, do not map to a super user or administrative user. 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.

 

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 portal user in the role or 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. 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.

More Information:

Configuring User Mapping with User ID and Password on a Portal