Frequently, a SAP Portal implementation has a requirement to restrict the search results for users in the substitution component of UWL. This screen, also known as the “people picker”, is where users can select someone to receive and act on work items on behalf of them. The substitution rules are not only relevant for portal but also replicated to backend systems connected to the UWL. By default, the UWL pulls all users from the portal User Management Engine (UME) even if you are using custom UWL configurations to restrict connectors by role. Given that the UME is often hooked up to a company Corporate LDAP (i.e., Active Directory) and also likely contains non-portal users this standard configuration may not be ideal. For example, there are often more users in LDAP than the connected backend SAP systems and a project may not want users delegating to non-portal users or even seeing them in the list of selectable substitutes. For example, as shown below in Figure 1 a restricted list of only certain users can be shown in substitution screen.
Figure 1: UWL People Picker Screen Sample Screen Shot
The people picker is a vital piece to UWL substitution functionality. This technical white paper will outline new capabilities delivered in SAP NetWeaver 7.0 Enhancement Pack (EhP1) that allow you to restrict the people picker search results list by certain user attributes that are common to unique sets of users.
The SAP Documentation refers to this functionality as “Differentiating User Data Display in External Portals” and the scope of the functionality is much broader than simply restricting UWL substitution. You can read more about the new functionality on help.sap.com using the following direct link:
In order to implement this solution there is a prerequisite that SAP KMC must be installed on system together with UWL. This is because the UWL uses two different people pickers underneath the covers. When KMC is installed together with UWL, the KM people picker is used. If the KMC is not present on the system, internal UWL people picker is used. KM People picker does have the described functionality in this document and the UWL people picker which does not. If you have installed the usage type EP then you will have the KM People Picker. Usage type EPC has UWL people picker.
Sample Scenario Description
There are many variations that present a unique set of requirements to restrict the users shown in the people picker ranging from portal company membership to organizational attributes stored on the user account such as department code. In this document, we’ll outline a fictional scenario whereby the portal is using a company based concept (users are grouped into separate companies) and the UWL is hooked up to multiple backend SAP clients which are unique to each company. In standard, the UWL people picker would show all users from UME, which means CompanyA users would see CompanyB users and vice versa. The scenario is simple but outlines the fundamental concepts.
The fictional requirement that needs to be met is that only users from CompanyA should be shown when substitution is performed by a CompanyA user.
When using portal companies, you can configure the UME in such a way that each company is represented by a virtual group in the UME. Therefore, all users of Company A also belong to virtual group CompanyA even though there is not an explicit assignment by a security adminsitrator. It is this distinguishing factor that we’ll use to implement our restricted people picker scenario. As shown in Figure 2, CompanyA has Virtual group V_CompanyA with 3 members.
Figure 2: Users of CompanyA
However, as outlined in the documentation, any UME attribute can be used to restrict the people picker display but the users company attribute is chosen in this case. Since a user can only belong to one company, there are no tiered delegation or parent/child relationships. The UWL user will only see users from his company.
In our scenario, we’ll look at fictional user “deleuser” who belongs to CompanyA and is assigned a standard user and sample delegated administration role (Figure 3). If you are familiar with delegated user administration screens, you already know that deleuser can only see users from his company, such delegated Administrator and deleuser2. However, when deleuser tries to perform substitution, he can see users from outside his company in standard configuration.
Figure 3: Roles for fictional user deleuser
As shown in Figure 3, when searching for Administrator deleuser is shown the default Administrator user in addition to his delegated administrator user from his company. Most likely this is not a desired behavior as deleuser should only delegate to Delegated Administrator, who also belongs to his company. For example, s shown in Figure 6, when searching for Administrator deleuser is shown the default Administrator user in addition to his delegated administrator user from his company. Most likely this is not a desired behavior as deleuser should only delegate to Delegated Administrator, who also belongs to his company.
Figure 4: UWL Manage Substitution Menu
Figure 5: Manage Substitution Rules
Figure 6: Search Result in Standard
System Configuration for Company Group Scenario
Since we are using a company based concept, the configuration necessary is minimal and not relevant to overall document purpose but outlined here for completeness. In fact, if you are already using a trading partner (tpd) you most likely already have this step completed. As outlined in Figure 7 below, we have configured three fictional companies in property com.tpd.companies: CompanyA;CompanyB;CompanyC and set the ume.tpd.prefix to be “V_”. These properties can be found in the J2EE Config Tool under Global Server–>Services–>com.sap.security.core.ume.service.
Figure 7: Properties for UME Companies
Implementing UWL People Picker Restricted Functionality
This section is really the purpose of this how to guide and addresses how you can implement the restricted search results functionality. Note that the following configuration steps assume that your user id has at least System Administrator role in portal.
Navigate to System Administration–>System Configuration–>Knowledge Management –> Content Management. Select Repository Managers.
Under Related Areas section, select UME Object Settings.
Figure 10: Related Areas of KM Repository Managers
Next, Select External Facing Extension link
Figure 11: UME Object Settings
Check the checkbox to activate the Extension for user data display in external portals.
Figure 12: Extension for user data display
After saving, under UME Object settings, select the Trusted Attributes link (shown in Figure 11)
Create a new Trusted Attributes setting. In our scenario, we only want to show users who belong to same company. Set the active and passive attributes to Company. This will set the people picker to show only those users to end user for substitution who belong to same company.
Figure 13: Trusted Attributes Settings
Create Roles and Assign Appropriate Actions
In order to prevent the disabling of the search functionality as shown in Figure 15 for those users not assigned to a company or your attribute, you will need to create two roles and assign to users and contain J2EE actions.
Create a role Employee_Company (this provides an Unrestricted view) and assign actions:
Create a role Trusted_External (this will provide restricted view) and assign actions:
That is all we need to do. We should now be set to test!
Initial Scenario Revisited with Enhanced Functionality
As shown in Figure 14, when deleuser navigates back to substitution screen and searches for Administrator, only the Administrator user from his company is shown (not J2EE Administrator).
Figure 14: Restricted People Picker Search
Overall, the new functionality to restrict user display in KM and Collaboration screens, specifically UWL substitution is a great feature for SAP customers. By leveraging this feature you can segregate users by UME attributes and improve the overall security, usability and design of your portal.
In order to avoid the disabling of the Search button for your unrestricted users, you need to implement the roles and assign the correct UME actions outlined in the last step for configuration above. The screen shot is shown here as a tip in case it happens to you. Once activated, the changes are across the board for all portal users. For example, in our scenario if we had users that didn’t belong to a portal company but used the same portal for UWL they would not be able to select any substitutes as shown in Figure 15. This can be eliminated by assigning the actions above to users.
Figure 15: UWL Substitution Disabled for non Company Users