Configuring Authentication in SAP Netweaver AS Java (Part 1 of 3)

Introduction

As part of an application development project based on the SAP Netweaver AS Java software platform, we were faced with the need to configure our own authentication schemes for developed applications. From here the idea was born, firstly, to structure the acquired knowledge, and secondly, to share this knowledge with other specialists in the field of SAP Basis.

The SAP Portal based on SAP NW AS Java 7.5 SP04 was used as a test bench. I don’t think that from the point of view of authentication approaches, something has changed a lot in all SAP NW AS Java since version 7.0, but please keep in mind the version for which this series of articles is being written.

I will use English terminology throughout the text so that there would be no translation difficulties if it is necessary to search for additional information on the Internet or when setting up authentication directly in SAP NW AS Java.

The first article, From General to Particular, will cover two topics:

1. How, from the point of view of authentication mechanisms, it is possible to classify applications based on the SAP Netweaver AS Java software platform;
2. How to determine the boundary between application developers / consultants and SAP Basis specialists in setting authentication for applications.

From general to specific

When I was faced with the need to delve deeper into authentication settings in SAP NW AS Java, through google.com I found a separate description of authentication modules, authentication stacks, or something else, but, unfortunately, I did not immediately stumble upon where to start the search. And we had to start with what types of applications it is possible to run on SAP NW AS Java, since depending on the types of applications, the approach to authentication settings is different.

So let's get started.

From the point of view of user applications, the following types of applications can be distinguished for which the approaches to setting authentication differ:

• Java web applications;
• Web Dynpro Java Applications;
• Portal applications
• Portal iVIews (yes, this is a container for applications, but SAP also refers to applications in its documentation).

The following figure shows the types of applications under consideration and approaches to their authentication settings. The following text describes an approach to configure authentication for each type of application.



Java Web Applications

Java Web Application is any Java application developed for the SAP Netweaver AS Java software platform (in the context of this article, of course). I want to note that SAP Portal is also a large Java application that contains its own structure, its own controls, etc. Authentication for Java Web Applications can be specified in the following ways:

• Through the web.xml descriptor (authentication at the container level of the Java application);
• Via the web-j2ee-engine.xml handle. (authentication at the level of the Java application itself). If authentication is described in the web-j2ee-engine.xml descriptor, then the description in this descriptor is considered to be higher priority than the description in the web.xml descriptor. Most often, the web-j2ee-engine.xml descriptor complements the description in the web.xml descriptor;
• If the descriptors web.xml and web-j2ee-engine.xml do not contain an authentication description, then the Java application for authentication of users uses the authentication scheme defined by the UME: ume.login_context parameter, as well as the user interface for authentication defined by the UME: ume parameter. login.auth_method;
  The ume.login.auth_method parameter can take 4 values: [FORM, BASIC, DIGEST, CLIENT-CERT]. The parameters ume.login.auth_method and ume.login_context must be complementary. For example, if ume.login.auth_method is set to BASIC, then the ume.login_context parameter must point to an authentication scheme with an authentication module by login and password.
• Using the UME API. In this case, developers when developing a Java application will refer to AuthScheme or AuthScheme-ref described in a special XML file, which is defined by the UME parameter login.authschemes.definition.file. By default, login.authschemes.definition.file = authschemes.xml. The following figure shows an example of authschemes.xml.

A detailed description of the structure of the web.xml descriptors, web-j2ee-engine.xml, and the authschemes.xml XML file will be given in the second part of this series of articles.

The web.xml and web-j2ee-engine.xml descriptors are edited by developers through SAP Netweaver Development Studio. SAP Basis specialists can view the contents of these descriptors for a particular Java application in the following way:


Changing these descriptors at the OS level is not recommended, since in the case of developers redeploying the application (Deploy Application), changes made at the OS level will be overwritten.

Web Dynpro Java Applications

Web Dynpro Java Applications is a special case of Java Web Applications. These applications use the Web Dynpro (WD) Runtime Environment component (Application module: webdynpro / resources / sap.com / tc ~ wd ~ dispwda) for their execution. From an authentication point of view, in the WD Runtime Environment settings, there is a parameter:

sap.default.authentication = (true / false)

If the sap.default.authentication = false parameter, then the need for user authentication for each WD Java Application is set by the developers. Using SAP NWDS, in the WD Java Application properties, developers can either activate the Authentication flag to force user authentication, or deactivate it if user authentication is not required in the application.

If sap.default.authentication = true, then the WD Runtime Environment will require user authentication for all WD Java Applications through the authentication scheme defined by the UME parameter - login.authschemes.definition.file.

It should be noted that in all standard Web Dynpro Java Applications, the authentication value is set to “default”. In authschemes.xml, this value must also be defined as a reference to the authentication scheme (the part of the authschemes.xml file that defines authscheme-ref name = “default” is shown below).



Portal applications - portal components

When a developer creates a portal application through SAP NWDS, he creates portal components for this portal application. For each portal component, the developer can set his own authentication scheme. This is done through a special XML file - portalapp.xml all in the same SAP NWDS. The developer can specify an authentication scheme - this is done using the directive:



Authschemename must be either an authentication scheme (authscheme name) or a reference to an authentication scheme (authscheme-ref name), predefined in the XML file, which is defined by the UME parameter login.authschemes.definition.file (i.e. authschemes.xml by default).

Portal iViews

Portal iView is a portal container where you can put various objects, including Web Dynpro Java application, Java web application, and much more. And for each iView, no matter what object it contains, you can configure your own authentication approach. This is done using the “Authentication Scheme” parameter specified in the settings of any iView. In turn, the “Authentication Scheme” parameter accesses the same XML file defined by the UME parameter: login.authschemes.definition.file = authschemes.xml (by default). All standard iViews can be divided into two parts:

1. iViews whose “Authentication Scheme” parameter is equal to default;
2. iVIews, the “Authentication Scheme” parameter for which is equal to UserAdminScheme.

default is the “authscheme-ref name” for custom iViews; UserAdminScheme is the “authscheme-ref name” for iView user management.

The following figure describes both “authscheme-refs” from the XML file defined by the UME parameter: login.authschemes.definition.file:

Conclusion

For all the types of applications considered, if you look again at the figure at the beginning of this article, all the arrows converge in the UME Authentication: Policy Configurations element. This means that further configuration of Login Modules will be configured here for all types of applications.

The second part of this series of articles describes an authentication approach using:

1. web.xml and web-j2ee-engine.xml descriptors;
2. XML file Authschemes.xml.

The following is information on how to access in the System the settings described in this article:

• Gaining access to the settings of UME parameters;
• Gaining access to the settings of Policy Configurations;
• Gets access to the sap.default.authentication configuration of the Web Dynpro Runtime Environment component.

application

Accessing UME Settings

• ume.login_context;
• ume.login.auth_method;
• login.authschemes.definition.file.

All UME settings can be changed through the Netweaver Administrator (/ nwa).

Configuration -> Security -> Identity Management



On the Identity Management screen, click “Configuration”:



Go to Open Expert Mode:



All UME parameters that can be changed if necessary will be displayed.

Gaining Access to Policy Configurations

You can access Policy configurations through the Netweaver Administrator (/ nwa).

Configuration -> Security -> Authentication and Single Sign-On An



application opens where you can create, modify or view existing Policy Configurations.



Gaining access to the sap.default.authentication setting of the Web Dynpro Runtime Environment component

Web Dynpro Runtime Environment component settings can be accessed through the Netweaver Administrator (/ nwa).

Configuration -> Infrastructure -> Application Modules



In the Module List, find webdynpro / resources / sap.com / tc ~ wd ~ dispwda:



Select this module. For it, select the “Web Dynpro Properties” tab. Property Sheet Name - default. Find the sap.default.authentication parameter and, if necessary, change it.