Organizations that upgrade their SAP GRC systems from 5.3 to 10.0 might face big challenges in the areas of user management and user authentication for accessing their SAP GRC applications. This is primarily because SAP GRC 5.3 was on a Java platform and the application components were installed on a Java-based SAP NetWeaver application server, whereas SAP GRC 10.0 is on an ABAP platform.

The user management and authentication technologies supported on the SAP NetWeaver Java-based application server are different from those on the SAP NetWeaver ABAP-based application server. It is not easy to match the as-is situation on the ABAP platform. On version 5.3, for instance, there was default access with a basic end-user role for every employee in the organization or the user could log on to an SAP GRC application using the windows active directory password.

Such requirements are new and not a regular use case for applications on ABAP platforms. No single document highlights all the challenges you face during an implementation or upgrade to SAP GRC 10.0, or provides the solution to the requirements mentioned above. SAP does provide a few standard functionalities that support some of these requirements to an extent. However, there are plenty of gray areas. We discuss these areas and guide you in making the right decisions in selecting the right solutions.

Background: User Management in the Java-Based SAP NetWeaver Application Server (SAP GRC 5.3)

The User Management Engine (UME) of the Java-based SAP NetWeaver application server can be configured to read user information from any of the following data stores (Figure 1):

• The J2EE database of the Java-based SAP NetWeaver application server
• A Lightweight Directory Access Protocol (LDAP) server
• An SAP NetWeaver ABAP-based application server

Figure 1

UME options for SAP GRC 5.3 on an SAP NetWeaver Java-based application server

Organizations usually prefer the second option (LDAP) and make use of directory services to configure the UME to read user information from the LDAP server. SAP provides standard configuration files for each data source. You can map the SAP GRC end-user roles to the Java UME or LDAP group and users can be set up quickly (Figure 2).

Figure 2

Role mapping to provide default access to SAP GRC 5.3

Users can authenticate using their Windows credentials on the GRC login screen and there is no need for managing their passwords as the corporate Active Directory (AD) policies handle them (Figure 3). The directory integration also automatically manages user provisioning and inactivation.

Figure 3

Windows authentication on the SAP GRC 5.3 login screen

Post Upgrade to SAP GRC 10: User Management in an ABAP-Based SAP NetWeaver Application Server (SAP GRC 10.0)

User management on an ABAP-based application server is quite different from a Java-based application server, especially to meet the as-is scenario when implementing or upgrading to SAP GRC 10.0. Users on ABAP-based SAP systems are managed locally on the database of the application server. Although directory integration on ABAP-based SAP systems is possible using standard SAP tools, you still need to create a local copy of the users on the SAP system.

Program RSLDAPSYNC_USER can read users from a directory server and can create them on the SAP ABAP system. Using the right variant for running the program, you can manage provisioning and de-provisioning of users through LDAP synchronization (Figure 4). This program has to be scheduled to run regularly as a periodic job in the SAP system. SAP has supported the LDAP synchronization for decades, and you can find well-documented information from the SAP help documentation to set up the directory synchronization.

Figure 4

User management on an ABAP-based application server using LDAP synchronization

However, there is still a limitation with the LDAP synchronization program—it does not make any role assignments to users. To provide SAP GRC end-user authorizations, you need to develop a custom mechanism. A simple program can be written that reads all active user master records, checks the assignment of a default end-user basic role for SAP GRC access, and updates the users who have not been assigned the role. This program, in combination with program RSLDAPSYNC_USER, should take care of your user management problem on an SAP ABAP-based application server. Refer to the “SAML 2.0-Based SSO” section for an explanation alternative solution for managing users.

The bigger challenge, however, is managing the SAP passwords. The default authentication mechanism to an SAP ABAP system through SAP GUI or Web access is the SAP password. It is not possible to set up authentication on the logon screen against an active directory password. There are a few third-party products and SAP’s own product for SAP NetWeaver Single Sign-On  that do support Windows authentication on the SAP GUI logon screen to add a layer of security instead of providing direct single sign-on (SSO) to the SAP GUI. However, these products, including SAP NetWeaver Single Sign-On, have user license costs associated with them.

When using Web access you could use some custom mechanisms. For example, if you have a Java-based application server in your landscape that is set up already with an LDAP UME, then you could redirect to the SAP GRC application after successful authentication on this server.

These options are either expensive or non-standard ways of tackling the issue. LDAP synchronization does the user creation only, but it is not the answer to the authentication problem.

User Authentication on SAP GRC 10.0

Many organizations that used SAP GRC 5.3 set it up in a way that the applications could be accessed by all end users without the need to manually administer them in the SAP GRC user store. The end users did not have to request access to the SAP GRC system. They also could use their Windows Active Directory password to access the tool. These were the advantages offered by the LDAP UME architecture on a Java-based application server. It was even easy for the approvers who seldom use SAP GRC except for approving the requests.

In GRC 10.0, however, the default solution for authentication provided by SAP is to use the ABAP password on the logon screen for Web access to the SAP GRC system. However, this may not be practical as the users (especially approvers who seldom use SAP GRC) have to remember their SAP GRC passwords. One of the best solutions to this problem is to provide an SSO to the SAP GRC application. There are plenty of options available to enable SSO to ABAP applications for Web-based access. Organizations must choose the right technology after analyzing the available system infrastructure, technical expertise, support process, service level agreements (SLAs), and IT services in their IT landscape.

The solutions listed in the next section are supported by SAP for Web-based SSO on SAP GRC 10.0.

SSO Using SAP Logon Tickets (SAP GRC Access via the SAP NetWeaver Portal)

SSO using SAP logon tickets from an SAP NetWeaver Portal to other SAP ABAP and Java systems is an SAP-proprietary solution (Figure 5). The mechanism uses a persistent cookie that carries the user’s credentials (not a password) for a defined validity period that is passed on to the SAP GRC application. A trust relationship has to be set up as a prerequisite between both systems by importing the portal X.509 server certificates in the SAP GRC application using transaction code STRUSTSSO2.

Figure 5

SSO to GRC using SAP Logon Tickets from SAP NetWeaver Portal

This option is useful if there is a stable portal infrastructure in place in the organization’s SAP landscape that is configured to use an LDAP server for its UME.

Based on our experience, we recommend that you complete the following actions before using this option:

• Make sure that the SSO to the portal or UME authentication using Windows credentials is already in place.
• Use LDAP as the data store for the portal so that users need not be created twice (on the portal and on the SAP GRC system).
• Ensure that you have adequate support from the portal administration team for creation of a system object to connect to the SAP GRC system from the SAP NetWeaver Portal and also for creation of portal content for the SAP GRC system.

There are two ways to configure portal-based SSO for SAP GRC 10.0:

• Using the portal user interface (UI) for SAP GRC 10.0. The portal is the UI to access the SAP GRC application. There is standard content available in the SAP marketplace in the form of a business package. The setup might require some portal expertise to implement the content and, if required, to configure the content based on company requirements. This method also requires the creation of a system object to connect to SAP GRC from the SAP Netweaver Portal using SSO.
• Using the SAP NetWeaver Business Client UI. If the organization wants to simplify the portal implementation it can still continue to use the SAP NetWeaver Business Client UI. In this case you can configure portal-based SSO by creating a URL view and by adding it to an end-user portal role. After you assign this role to the users, they can access the SAP GRC application URL through the portal.

SSO to SAP GRC in both these cases is done using SAP logon tickets.

More detailed information about the setting SSO with SAP logon tickets scenario can be found in this link.

SSO Using X.509 Certificates

The SAP ABAP server supports the use of X.509 certificates during client authentication for Web-based access. Organizations that have a well-established public key infrastructure (PKI) and registration process for distributing client certificates for each user workstation can use the certificates for user identification and authentication to the SAP GRC application.

The Certificate Authority (CA) of the client certificates must be trusted by the SAP GRC application server. When a user tries to access an SAP GRC application through the Web browser, the browser accesses the certificate store of the user’s machine and passes the user’s client certificate to the SAP GRC application (Figure 6).

Figure 6

SSO using X.509 certificates to SAP GRC

Because the Web application server on which the SAP GRC is installed trusts the CA that issued the client certificate, it authenticates the user. Next, the SAP application tries to identify a matching user in the ABAP user store. This requires mapping the SAP user IDs (SU01) with the subject name in the certificate (DN) in a table VUSREXTID. If a matching entry exists for the user, then the user is allowed to log on without any further authentication.

The best part about SSO using X.509 certificates is that there is no dependency on an external server for implementing SSO. In the case of an SAP NetWeaver Portal-based solution with SAP logon tickets, if the portal had to be down for maintenance or if it broke down, then it also prevents users from using the GRC application.

This option has the following prerequisites:

• The company should have a well-established PKI for distribution and management of client certificates to every user workstation.
• A custom program may be required for mapping of users (table VUSREXTID) to the distinguished names as per their certificates.

This solution requires heavy maintenance, especially with the requirement for distribution and revocation of client certificates and also the mapping of users to the VUSREXTID table. If the user base is very large or if there is a special registration process put in place by the customer’s PKI agency for client certificates, this option might not be easy to manage (for more information see the section titled “SSO Using SAP NetWeaver Single Sign-On”). However, if you consider your SAP GRC application to be critical and sensitive, then you should note that the certificate-based SSO is much more secure than using SAP logon tickets.

More detailed information on setting SSO with X.509 certificates scenario can be found in this link.

SSO Using SAP NetWeaver Single Sign-On

A couple of years back SAP released a product called SAP NetWeaver Single Sign-On that supports SSO to various SAP applications in both the SAP GUI as well as Web-based environments. The product supports SSO to different SAP and non-SAP applications using various authentication mechanisms such as Kerberos and X.509. It provides out-of-the-box PKI capabilities by adding a server called Secure Login Server (SLS) for organizations that do not have their own PKI. The SAP CA (Certification Authority) generated from the SLS can also integrate into an existing PKI if an organization has its own. The SLS also provides identity federation services in the role of a SAML IDP (see the “Security Assertion Markup Language [SAML] 2.0-Based SSO” section).

As per SAP Note 1798979 - SPNego ABAP: Downport on version 2.0 of SAP NetWeaver Single Sign-On it is also possible to use Kerberos-based authentication for Web access to SAP ABAP applications. This feature is available on SAP NetWeaver 7.02 version from Support Pack 14 along with SAP NetWeaver Single Sign-On 2.0.

This option has the following prerequisites:

• SAP NetWeaver 7.02 SP 14 or higher (Check the note for the SP levels for each NW version)
• Kernel: 7.21 (EXT) PL 41 (or higher)
• Secure Login Library (SLL) as part of SAP NetWeaver Single Sign-On 2.0

This method of SSO is recommended for SAP GRC only if you already have the product installed or if you plan to install SSO to other SAP systems in your SAP system landscape, not only SAP GRC. This is because the product involves a license cost per user.

More detailed information for implementing SSO with SAP NetWeaver Single Sign-On can be found in this link.

Security Assertion Markup Language (SAML) 2.0-Based SSO

SAML is a standard mechanism for SSO for Web applications. It is used worldwide in many organizations especially in the area of cross-domain authentication that is not easily supported by any other SSO solution. In SAML, an application outsources the authentication process to another server (Figure 7). This solution thereby requires an identity management (IDM) server or a similar server that acts as an SAML identity provider (IDP). The IDM server plays the role of identifying and authenticating the users. Usually, the IDP uses an authentication server for this purpose, which is configured to validate the users based on some form of user credentials such as a Windows password, a Kerberos or NTLM token, or an X.509 certificate.

Figure 7

SSO using SAML 2.0 to SAP GRC

At the end of the process users receive a digitally signed and encrypted SAML assertion (token) that is accepted by the SAP application server (known as a service provider as it provides the application services) because it trusts the server that signed the assertion. If the SAP system is able to find a valid user account as supplied in the SAML assertion the SSO is successful.

If the company has an identity management application server or an equivalent application server that provides SAML service then this option is the best when compared to all the other options for SSO discussed earlier. The SAML configuration is only a one-time configuration and does not require any custom mechanism for mapping of users. This is also our recommended option and one solution to all user management and authentication problems posed by SAP GRC 10.0.

This option has the following prerequisites:

• An IDM server or similar application server which provides SAML 2.0 service.
• GRC application server installed on NW 702 SP10 or higher

In addition by using SAML 2.0 you can also solve the problem cited earlier for creation of users (details in SAP Note 1799402 - Automatic account creation for SAML 2.0 SP). This way, you do not have to create the entire user population in the system, but users are automatically created with default roles as and when required (Interactive Federation of Identities) when they do their initial logon to SAP GRC. Therefore, there is no need to run LDAP synchronization or develop a program for assigning roles to users. More detailed information on setting up SSO with SAML 2.0 can be found in this link.

Approval Reaffirmation

Some organizations prefer to have an approval reaffirmation (re-authentication) when approving a request in SAP GRC. In SAP GRC 5.3 the authentication was done against the UME of the J2EE application server. In SAP GRC 10.0 the default implementation checks for the SAP system password. After implementing SSO you want to make sure that the users do not have to remember their SAP passwords to access the SAP GRC system. You can overcome this challenge with a small enhancement within the WebDynpro component GRAC_UIBB_ACCREQ_APPROVAL to authenticate against the LDAP server using the FM LDAP_SIMPLEBIND, which can make use of the LDAP connectors for authenticating the user. SAP recommends that you create more than one connector if the system usage is high for balancing the load on the connectors. For more information see SAP Note 670075.

We recommend that developers implementing the re-authentication solution using LDAP_ SimpleBind read the following SAP Notes for LDAP connectors before they start their implementation:

• Note 1123877 — Runtime restriction for connections of the LDAP Connector
• Note 587790 — LDAP-API documentation for application developers
• Note 670075 — LDAP030 with LDAP_SIMPLEBIND/LDAP_SYSTEMBIND
• Note 506671 —LDAP Connector (Version 2.3)

Nitin Aggarwal

Nitin Aggarwal is a chartered accountant and a certified information systems auditor with more than 10 years of experience in SAP implementations, business process control reviews, access and authorizations reviews, and IT audit. He is a subject matter expert on SAP Access Control and has been involved in numerous implementations over the past seven years.

You may contact the author at Nitin_Aggarwal09@infosys.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Subramaniam Iyer

Subramaniam Iyer is an experienced security professional with more than 12 years of experience, including six years as an SAP security consultant with a multinational pharmaceutical organization. He has strong understanding, knowledge, and experience in the key areas of access control to SAP applications, including applying concepts, methodologies, and techniques in the areas of authentication and authorization mechanisms.

You may contact Subramaniam via email at Subramaniam_iyer@infosys.com.

 

You may contact the author at Subramaniam_iyer@infosys.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.