WebSphere Portlet Factory (WPF) provides a rich set of SAP tools that allows the integration of every known SAP Interface (and even more). Many customers, IBM Partners and Independent Software Vendors (ISV) discovers the numerous benefits of WPF during modernization of SAP Applications. WPF has become the preferred tool for many of them.

SAP Applications based on ABAP code can be secured in many different ways. The challenge in working with those applications is to manage the (high) complexity of those envrionments. Key to success is to undestand the specific details in a given landscape and to use this understanding for finding the optimal implementation approach. The issue is that no tool can handle this task for you.

The good news is that the WebSphere Portlet Factory development team did a great job designing a very flexible, open and extensible framework that takes care about nearly everything. In fact, it doesn't protect developers to implement best practices patterns, acccording to the given situation the need to cope. The patterns for very common and mandatory tasks are described in the following sections:

Authentication

The authentication mechanism is part of the underlying runtime, e.g. WebSphere Portal Server (or WebSphere Application Server). In some cases the portal username is not identical with the SAP username (sys-uname).
The mapping is typically done using an LDAP attribute or within an SAP Data Dictionary table. Because there are multiple LDAP APIs available this paper will give futher details. A good option is the builder attached in the article Creating a custom builder to provide LDAP data access in this Wiki.

If SAP is doing the user mapping, it is done within the user USREXTID table. The SAP Table Read Builder of WPF helps to retrieve the content. Even if your Integration is based on named user SAP users, the user mapping is part of the infrastructure and should be done using a technical communication user. Make sure, that this user has the following permission: S_RFC (RFC_TYPE=FUGR, RFC_NAME=SYST, ACTVT=16) and S_TABU_DIS (ACTVT=02, DICBERCLS=USREXTID).

Sometimes the initial authentication is done on a ticket or token base. To find out the current username, use the SAP Function Call Builder of WPF and implement USER_NAME_GET.
If you prefer a Java Implementation use this sample code:

Note: Never import the sapjco.jar file into your project. The jar is using Java Native Interface and (often) fails if two jars what to access the same native library. If you have two Portlet Applications on the same page that includes sapjco.jar, one will work and one will throw an Exception.

Authorization/ Role Management

In general, authorization and role management is done with the help of Users and Groups. In some cases it makes sense to extend this model and use the SAP Organization Management structure or the SAP Roles/Profiles.

Using SAP Organization Management

To find out where the employee is located in the organization structure, you need to get the HR Infotyp 0001. It contains the current OrgUnit, Costcenter, Planed Position and Position. That piece of information can be used for all levels of authorization and personalization.

Get the structure using RFCs:
USER_NAME_GET > Get the username (if not known)
BAPI_USR01DOHR_GETEMPLOYEE > Get the employee id by username
BAPI_EMPLOYEE_GETDATA > Get the organization information

Get the structure using Infotype Builder:
USER_NAME_GET > Get the username (if not known)
Infotyp 0105 > Get the employee id by username
Infotyp 0001 >Get the organization information

Using Infotyp 0001 is the fastest way to get bottom up information about where the employee is located and what he/she is doing.
If you want to build a personalized Portlet Factory model based on a more complex organization, a top down appoach is recommended.

Use the BAPI BAPI_ORGUNITEXT_DATA_GET to access any element in a organization structure and expend it. Use OBJID for an unique ID of any OrgManagement element and OTYPE for the typ that element. By default O = Organization Unit, C = Job (Templates for concrete positions like Secretary), S = Position (like Secretary Backoffice HR & Finance.
If the result table ACTORTAB contains Typ P and the employee id, the user is member of that Organization unit or works in that position.

Using SAP Role and Profile Management

There are multiple ways known how to access the internal SAP ABAP Role and Profile Management. Some of them are supported and some of them are well working alternatives. There are four known ways to access the data: using SAPs J2EE Stack, using User Management BAPIs, using J2EE RFCs or using the SAP data dictionary tables. These four options are described in detail in the following paragraphs:

Using the J2EE Stack:

This step is the most supported way, but requires custom development (outside of WPF), infrastructure prerequisites, and knowledge of some SAP J2EE APIs yourarely use. It is also the solution that needs the most resources and will affect the the landscape in terms of performance. The following steps must be undertaken:

1.) Install the SAP J2EE stack if not already installed.

2.) Point the User Management Engine (UME) of that J2EE Stack to an existing ABAP system. It will then work with the ABAP credentials and will map ABAP profiles to J2EE groups.The next step is the preparation of an interface (e.g. WebService) for Websphere Portlet Factory. The service uses the UME API to access the internal user management data and exposes them as an external interface.

3.) Export the WSDL of the created service and design a WPF Provider Model that makes use of the service using the Web Servicve Builder.

Using User Management BAPI

The user management API is a set of well working BAPIs that where initially designed for the SAP central user administration and the use by external identity management (like Tivoli Identity Manager) systems and directory federation tools(like IBM Directory Integrator).

The “PRGN” RFCs are non supported RFCs, but produces less overhead then the User Management API. The original purpose was to use that functions in the SAP J2EE stack to access the ABAP user store. Some versions of SAP J2EE Stack (or more correctly the UME of that J2EE Engines) still use that mechanism.
You can use that RFCs to get some access to the ABAP user management and role assignment.

PRGN_J2EE_GETROLES – Get a list of roles
PRGN_J2EE_USER_GET_ROLENAMES – get the roles assigned to an user

Using SAP Data Dictonary Tables

Using the SAP Table Read Builder and SAP Table Merge Builder is a very strong option cause it will allow you to serve all layers of SAP Access Management and Permissions. It is the most flexible, deepest and most complicated way to handle SAP permissions. There are also some limitations you have to keep in mind.

The SAP Table Read Builder is using RFC_READ_TABLE (internal) and is therefore limited to a rowsize of 255. Make sure that you just retrieve the fields you really need. Don't cross that limit! The “where” option is limited to that size too.

Make sure your use has S_RFC (RFC_TYPE=FUGR, RFC_NAME=SYST, ACTVT=16) and S_TABU_DIS (ACTVT=02) for all tables you need.

A common misunderstanding regarding SAP communication is the security of communication. The term sRFC stands for synchronous RFC and not secure RFC. To secure the RFC communication channel activate SNC (secure network communication). It requires a initial setup in the SAP environment, that is maybe the hardest part. Inside of WebSphere Portlet Factory the setup is done as connection property (properties file or inside the builder). The property files are located in the WEB-INF/config/sap-config folder in your SAP project.

The settings should be consolidated and activated with your infrastructure team:

In the cominination with WebSphere Portal or WebSphere Application Server Security (SSL Setup) you're going to have a end-to-end secure communication.

Single Sign On

There are multiple ways to handle Single Sign with SAP. Using SAP Login Module, installing LTPA Trust at the SAP System, using SAML or SPNEGO are the most common patterns in the market.
All of them will end up by retrieving an SAP SSO Ticket.

After getting a Single Sign On ticket, there are a few things you should be aware off to have a proper SAP SSO Mechanism within Portlet Factory

Use a technical user for the repository. This protects the system from potential problems if a user session ends. Trying to get RFC meta data with an expired ticket can be very critical.

Do the Single Sign On Management in a model and import it into every single model that interacts with SAP

Store the ticket in a shared variable that is available across the user session

Make sure the error handler builder is used to catch JCO Exceptions (JCO.Exception). In the catch Action test again if the reason was an expired ticket and run the RFC once again. Make sure, that the second RFC call throws another exception, to neverending loops within your model, if the SAP doesn't issue new tickets.

Use a Single Sign On Ticket is very simple: the username must be set to $MYSAPSSO2$ and the password to the ticket value.

Picture 1: Use SSO within an SAP Builder

About the author

Tino Friedemann: Is IT-Archtiect at IBM Technical Sales team in germany and former Senior IT Architect at SAP Gernany.