User Mapping-based Single Sign On
In my SAP Logon Ticket-based Single Sign-On, I discussed how to implement SAP logon ticket-based SSO. In this installment, I will discuss how to implement SSO with User Mapping.
When integrating a content-providing backend application (a.k.a. data source) to the portal, sometimes you may not want to or be able to change the way the backend application handles authentication, in order to accept SAP logon ticket, for example, when the backend application is provided by a third party. In such cases, you will need to rely on User Mapping (a.k.a. Account Aggregation) to implement SSO.
First of all, you need to *understand how the backend application handles authentication. *Take a close look at your backend application, and identify:
– What logon credentials, such as user name, password, are required for authentication?
– How should the credentials be presented by the portal iView (acting as a client) to the backend application?
If your application is a Web application accessed through HTTP, then likely one of the following methods is used for authentication:
– HTML Form-based authentication
– HTTP Basic Authentication
– HTTP Digest Authentication
– X.509 Client Certificate (for HTTPS)
If you use not HTTP but some other means, say, API calls, to access the backend application, you likely still need to provide credentials such as user name and password to authenticate to the backend application.
Next, you need to *define a system entry * in the portal System Landscape ( +System Administration -> System Configuration ->
System Landscape +) to represent your backend application. You can find procedural instructions here . After the system entry is created, somebody needs to *provide the actual user mapping data *. The value of the +User Mapping Type + property of the system entry controls who, the portal Administrator, or the individual portal user, can perform the task. More details can be found here .
Now let’s look at how you can implement User Mapping SSO for several common types of portal contents.
*URL iView *
Although URL iView is the easiest way to integrate content to the portal, its support for User Mapping SSO is rather limited.
URL iView does not support HTTP header-based basic authentication to backend application. It only supports the +http://username:password@server/resource.ext + form of basic authentication. However, since our friends in Microsoft have recently become pretty security-conscious and have dropped support to this insecure form of authentication in the Internet Explorer (see this), practically it means that you won’t be able to use URL iView to implement user mapping SSO for basic authentication. First, you need to define a system entry in the system landscape. Since the generic application integrator looks for certain properties that do not exist in the system templates and PAR components that come with the EP6 installation, you will need to download this zip file, extract +com.sap.portal.howtos.webapp.par +, and upload it to the portal. Afterwards, you can define a system entry based on the +WebApplication + component of this PAR file. Once the system entry is created, open it for editing. In the +UserManagement + property category, select +UIDPW + as the +Logon method +, and select desired user mapping type. Also remember to create an alias for the system entry. SAP User Management Engine ( UME , which is used by both SAP WebAS Java and SAP EP) provides APIs to do just so. This page contains sample code. To compile the sample code, you need to add Since Web Dynpro applications run on the Web Dynpro container (which is part of SAP WebAS Java, in parallel to the portal runtime), to achieve single sign-on, as a first step you always need to configure the WebAS Java system on which your Web Dynpro application runs to accept logon ticket issued by the portal system, by following these instructions .