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

Introduction

The first part of the series “Configuring Authentication in SAP Netweaver AS Java” covered various approaches to configuring authentication in applications running on the SAP NW AS Java software platform. It also identified areas of responsibility of various project groups (developers, functional consultants, SAP Basis specialists) for making authentication settings.

In the general scheme introduced in the first part, I identified the elements that I will now consider - these are web.xml, web-j2ee-engine.xml descriptors, and the authschemes.xml authentication scheme XML file.


')
Authentication description in web.xml descriptor

Once again I want to remind you that the web.xml descriptor must be edited by developers through the SAP NWDS. Do not change it at the OS level.

This descriptor describes a Java container that contains a Java application. At the level of this container, you can configure the authentication scheme.

To describe the authentication settings at the Java container level, in the web.xml descriptor, you must use the <login-config> ... </ login-config> tag . It sets all the necessary parameters to describe the authentication.

For the Java container, we can use only 4 standard authentication methods:

• BASIC
• FORM
• CLIENT_CERT
• DIGEST

If you want to use Kerberos or SAML authentication, the approach of describing the authentication method only via the web.xml descriptor will not work!
Further I will tell about these 4 authentication methods in detail.

BASIC authentication method is when the system for entering the username and password of the user gives approximately this window (the window view depends on the user's browser and its view cannot be managed):



This authentication method is tied to the policy configuration “basic”, which by default contains one Login Module: BasicPasswordLoginModule. This login module verifies the entered login and password through the standard User Management Engine (UME) authentication mechanisms.



The BASIC authentication method is specified in the web.xml descriptor using the following tags:

<login-config> <auth-method>BASIC</auth-method> <realm-name>myRealm</realm-name> </login-config> 

The <realm-name> tag indicates the security scope. I will try to explain the meaning of this security area with an example:

Consider two applications: Application 1 and Application 2. For both applications, the following are specified in the web.xml descriptor: auth-method = BASIC and realm-name = MySecurityRealm.

The user accesses Application 1 and the application requests his login and password through the BASIC form. The user enters his credentials and successfully authenticates to Application 1. The user then goes to Application 2. The system will not prompt the user to re-enter their credentials, since the realm-names of both applications are the same as MySecurityRealm. If another realm-name were specified for Application 2, then when switching to Application 2, the System would ask the user to enter the user credentials again.

FORM authentication method - this is when the system gives a user-friendly interface to the user for entering the login and password.

SAP provides its own interface for entering user credentials and usually looks like this:



The standard interface has its own settings, but I will not describe these settings in a series of articles on authentication. I can only say that the standard interface can be modified: for example, you can replace a picture, a logo or slightly expand its functionality without involving developers. But any Company may want to completely rewrite the standard login and password entry interface with the help of the developer, and this is also possible.

If we plan to use the standard interface, it is enough to define the following tags in the web.xml descriptor of the Java application:

 <login-config> <auth-method>FORM</auth-method> </login-config> 

If we want to use the developed interface for our Java application, we need to define the following tags in the web.xml descriptor:

 <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/mylogin.jsp</form-login-page> <form-error-page>/myerror.jsp</form-error-page> </form-login-config> </login-config> 

The <form-login-page> tag sets the designed login page. The <form-error-page> tag sets the page for when a user authentication error has occurred.

The FORM authentication method is bound to the policy configuration “form”, which by default contains one Login Module: BasicPasswordLoginModule.



The CLIENT_CERT authentication method is when an application requests a user to provide a user certificate for authentication. For the user, it will look something like this:



To use the CLIENT_CERT authentication method, the following tags must be defined in the web.xml descriptor:

 <login-config> <auth-method>CLIENT_CERT</auth-method> </login-config> 

This authentication method is bound to the “client_cert” policy configuration, which by default contains one Login Module: ClientCertLoginModule.



DIGEST authentication method . This authentication method is similar to the BASIC and FORM methods, i.e. also requests a login and password. Only in the case of DIGEST, the password hash is transmitted, and not the password itself, as in the case of BASIC or FORM authentication methods. However, this authentication method is not widespread. Apparently, it will be easier and more logical to configure SSL encryption of the communication channel, rather than using the DIGEST authentication method.

This authentication method is tied to the policy configuration “digest”, which by default contains one Login Module: DigestLoginModule.



Description of the authentication scheme in the web-j2ee-engine.xml descriptor

The web-j2ee-engine.xml descriptor, by analogy with web.xml, should be edited only by developers through the SAP NWDS. Do not change it at the OS level.

In this descriptor, unlike the web.xml descriptor, it is possible to describe in detail the whole Authentication stack (that is, the set of login modules (Login Modules)).

In addition to the description of the Authentication stack, the Policy domain (<security-policy-domain> tag) must be specified in the web-j2ee-engine.xml descriptor. The policy domain is a security domain (similar to Realm name). The difference between the Realm name and the Policy domain is as follows:

• Realm name : Used only as part of BASIC authentication. In the case of the same Realm name for two different applications, the system will in any case call the Login Module to verify authentication when applying to Application 2 after successful authentication in Application 1. This module will see that Application 2 is in the same Realm name as Application 1 and will not re-request user credentials.
• Policy Domain: Used for the Authentication stack (i.e. for a group of different Login Modules). If the same Policy Domain is specified for two different applications and the authentication in Application 1 is successful, then when calling Application 2 the system will not initiate user authentication through the specified in Application 2 Authentication stack. If the Policy Domains for the two applications are different, then the authentication check will be initiated by the system through the Authentication stack specified in Application 2.

The structure of web-j2ee-engine.xml is well described on the help.sap.com portal via the following link .

Authentication scheme description via authschemes.xml XML file

If creating and editing web.xml and web-j2ee-engine.xml files is a developer's task, then the XML file authschemes.xml, which is defined by the UME parameter: login.authschemes.definition.file, is the responsibility of the SAP Basis specialists.

This file is in the System database and can be accessed through a standard graphical tool - ConfigTool.


To get to the location of the authschemes.xml file, go to Configuration editor mode in ConfigTool:



In the tree menu we get to the directory:
Configurations :: cluster_config -> system -> custom_global -> cfg -> services -> com.sap.security.core.ume.service -> persistent.

In this directory is the file authschemes.xml, which can be downloaded, edited, downloaded back. Just pay attention to the encoding. If you unload it to the OS level, edit it and save it in another encoding, then there is a chance that the system will not be able to read it, so beware!

You can also create your XML file with template authentication schemes or from scratch as you like. Just do not forget then in the parameter UME login.authschemes.definition.file specify your new XML-file. And also do not forget that all standard Web Dynpro Java Applications will search in this XML file “authscheme-ref name” = default, and Portal iViews will search in it “authscheme-ref name” = [default or UserAdminScheme].

If everything is clear with these nuances, then you can begin to study the structure of the standard XML file authschemes.xml

The structure of the file authschemes.xml

Authentication Schemes (authschemes.xml) is a list of authentication schemes that can be used by portal applications, Web Dynpro Java applications, and portal iViews within the System. Java web applications can also use Authentication Schemes if developers use the UME APIs when writing code.

If the application refers to an authentication scheme not described in authschemes.xml or the application does not describe any authentication scheme in principle, then the authentication scheme specified in the UME parameter: login.authschemes.default will be used to authenticate the user in such an application.

In the next picture, I depicted the structure of the authschemes.xml XML file.



As seen from the figure, the authschemes.xml file consists of authentication schemes (Authscheme 1, Authscheme 2, ..., Authscheme N) and a list of references to authentication schemes (Authscheme-ref 1, Authscheme-ref 2, etc.). Authentication schemes and links to them can be any number, depending on your design requirements.

To begin, I, perhaps, with links (References or Refs). Everything is simple here. The name of the link is written in the <authscheme-ref name> tag and the name of the authentication scheme that we want to link to in the nested tag is indicated. As I have repeatedly said, all standard Portal iViews and Web Dynpro Java Applications use predefined Refs: “default” and “UserAdminScheme”. Moreover, if you look at the standard XML file authschemes.xml, then you can see that “default” and “UserAdminScheme” lead to the same authentication scheme: uidpwdlogon.



If, for example, we want different user authentication schemes for user iVIews and user administrators for iView, we can do this by changing the authentication scheme from uipwdlogon to any other, for example, MyOwnAuthScheme for the link <authscheme-ref name = ”UserAdminScheme”>.

However, the use of links in authschemes.xml is rather a feature, which, in general, can not be used. In applications that use Authentication Schemes, you can immediately refer to any of the authentication schemes defined in authschemes.xml.

Each AuthScheme from the authschemes.xml file has its own set of parameters:

• Authentication template;
• Priority;
• Frontend type;
• Frontend target;

Authentication template. This is a predefined policy configuration, the creation and filling of which I will describe in the third part of a series of articles about setting up authentication in SAP Netweaver AS Java. As a template, we must specify one of these Policy configurations. Taking into account that the Policy configuration is described by the Login modules, our authentication scheme will know which registration modules it needs to use in the System.

Priority. I will try to explain the meaning of this parameter with an example. We have two applications:

• Application 1, which uses the AuthUserPass authentication scheme only by login and password;
• Application 2, which uses the AuthCert authentication scheme only by user certificate.

Let Priority for AuthUserPass = 20, and Priority for AuthCert = 40. If the user is authenticated in Application 1 (by ID and password) and transferred to Application 2 (which asks for certificate authentication), the user will have to present a client certificate to authenticate to Application 2 , since the priority is at AuthCert (40)> AuthUserPass (20). Consider the opposite option - the user is authenticated in Application 2 (by certificate) and transferred to Application 1 (which requests authentication by login and password). Considering that the priority of AuthCert (40)> AuthUserPass (20), the System will let the user into Application 1 without requesting a login and password.

Frontend type. Specifies the type of interface that will be invoked for interaction between the System and the user The following options are possible: 0, 1 or 2:

• 0 - TARGET_FORWARD - indicates that the call will be made to another servlet (honestly, it remains a mystery to me which application can be called for this type of front-end - there is very little information. Who knows where to use it - write in the comments);
• 1 - TARGET_REDIRECT - indicates that the application being called will be located at another HTTP address (a redirect will be made);
• 2 - TARGET_JAVAIVIEW - indicates that the called application for entering credentials is a portal Java iView. As a rule, this option should be used for standard authentication methods (used for all portal applications).

Frontend target. Indicates which application should be launched by the System when interacting with the user to provide credentials. In the standard authschemes.xml file, applications are listed as Frontend target for different authentication schemes:



These are the Portal components that belong to the same Portal application: com.sap.portal.runtime.logon. This Portal application can be found at the OS level of the SAP system and, with the help of the developers, modify it:


You can also find this application in the SAP Portal Content Directory:

Conclusion

This article has reviewed the structure of the web.xml and web-j2ee-engine.xml descriptors. The structure of the authschemes.xml XML file was also reviewed. If you have any questions, write in the comments, try to answer.

In the next part of a series of articles on configuring authentication in SAP Netweaver AS Java, I will describe the policy configurations and capabilities that can be achieved with their help.