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,” talked about different approaches to configuring authentication in applications running on the SAP NW AS Java software platform. It also identified the areas of responsibility of various project teams (developers, functional consultants, SAP Basis specialists) for performing authentication settings.

    On the general scheme introduced in the first part, he designated the elements that I will now consider - these are the 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 that the web.xml descriptor must be edited by developers through SAP NWDS. Do not change it at the OS level.

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

    To describe authentication settings at the Java container level, in the web.xml descriptor, you must use the tag ... . It sets all the necessary parameters for the description of authentication.

    For a 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 through the web.xml descriptor will not work!
    Next, I’ll talk in detail about these 4 authentication methods.

    The BASIC authentication method is when the system for entering the user’s login and password gives something like this window (the window type depends on the user's browser and cannot be controlled):



    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 authentication mechanisms User Management Engine (UME).



    The BASIC authentication method is set in the web.xml handle using the following tags:

    BASICmyRealm

    In tag The security area is indicated. I’ll try to explain the meaning of this security area using an example:

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

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

    FORM authentication method - this is when the user gives a user-friendly interface to enter the username and password.

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



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

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

    FORM

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

    FORM/mylogin.jsp/myerror.jsp

    Tag sets up a custom login page. Tagsets the page for cases 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.



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



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

    CLIENT_CERT

    This authentication method is bound to the Policy configuration “client_cert”, 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 asks for a username and password. Only in the case of DIGEST, the password hash is transmitted, not the password itself, as in the case of BASIC or FORM authentication methods. However, this authentication method is not widespread. Apparently because it is easier and more logical to configure SSL encryption of the communication channel than to use 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, similar to web.xml, should be edited only by developers through SAP NWDS. Do not change it at the OS level.

    In this descriptor, unlike the web.xml descriptor, you can describe in detail the whole Authentication stack (i.e. a set of login modules in the system (Login Modules)).

    In addition to the description of the Authentication stack, the policy domain should be specified in the web-j2ee-engine.xml descriptor (tag) Policy domain is a security domain (similar to Realm name). The difference between Realm name and 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 accessing 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 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 help.sap.com using the following link .

    Description of authentication scheme via authschemes.xml XML file

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

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

    Linux path to ConfigTool
    /usr/sap/[SID.BIZ/J00/j2ee/configtool/configtool.sh

    To get to the location of the authschemes.xml file, you need to go to the 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.

    This directory contains the authschemes.xml file, which can be uploaded, edited, downloaded back. Just pay attention to the encoding. If you upload it to the OS level, edit and save it in a different encoding, there is a chance that the system will not be able to read it, so be careful!

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

    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 UME APIs when writing code.

    If the application refers to an authentication scheme that is not described in authschemes.xml or no authentication scheme is described in principle in the application, then the authentication scheme specified in the UME parameter: login.authschemes.default will be used for user authentication in such an application.

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



    As you can see from the figure, the authschemes.xml file consists of authentication schemes (Authscheme 1, Authscheme 2, ..., Authscheme N) and a list of links 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.

    I'll start, perhaps, with links (References or Refs). Everything is simple here. The name of the link is written in the tagand the name of the authentication scheme that we want to refer to in the nested tag is indicated. As I have said many times, all standard Portal iViews and Web Dynpro Java Applications use the predefined Refs: “default” and “UserAdminScheme”. Moreover, if you look closely at the standard XML file authschemes.xml, you can see that “default” and “UserAdminScheme” lead to the same authentication scheme: uidpwdlogon.



    If, for example, we want to make different authentication schemes for user iVIew and iView user administrators, we can do this by changing the authentication scheme from uipwdlogon to any other, for example, MyOwnAuthScheme for reference.

    However, the use of links in authschemes.xml is, rather, a feature that, in general, you can not use. 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 content 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. Considering that Login modules are described in the Policy configuration, our authentication scheme will know which registration modules in the System it needs to use.

    Priority I will try to explain the meaning of this parameter using 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 with a user certificate.

    Let Priority for AuthUserPass = 20, and Priority for AuthCert = 40. If the user is authenticated in Application 1 (by identifier and password) and switched to Application 2 (which asks for authentication by certificate), then the user will have to present a client certificate for authentication in Application 2 , since AuthCert (40)> AuthUserPass (20) has priority. Consider the opposite option - the user authenticated in Application 2 (by certificate) and switched to Application 1 (which asks for authentication by login and password). Given that AuthCert (40)> AuthUserPass (20) takes precedence, the System will let the user into Application 1 without asking for a username and password.

    Frontend typeDefines the type of interface that will be called 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 in another servlet (to be honest, it remains a mystery to me which application can be called for this type of frontend - there is very little information. Who knows where this can be used - write in the comments);
    • 1 - TARGET_REDIRECT - indicates that the called application will be located at a different 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, the Frontend target for different authentication schemes contains the following applications:



    These are 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 developers, refine it:

    Linux application com.sap.portal.runtime.logon on the Linux OS level
    /usr/sap/[SID.BIZ/J00/j2ee/cluster/apps/sap.com/com.sap.portal.runtime.logon/ servlet_jsp / com.sap.portal.runtime.logon / com.sap.portal.runtime .logon.war

    This application can also be found in the SAP Portal Content Directory:





    Conclusion


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

    In the next part of the series about configuring authentication in SAP Netweaver AS Java, I will describe the Policy Configurations and the possibilities that can be achieved with them.

    Also popular now: