Configuring Authentication in SAP Netweaver AS Java (Part 3 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 second part , the structure of the web.xml and web-j2ee-engine.xml descriptors was described, as well as the structure of the XML file authschemes.xml.

In the general scheme introduced in the first part, I identified the elements that I will consider now - this is Policy Configurations.
')


Policy Configurations General structure

As we already found out, for different types of applications, we can describe in different ways how user authentication will be performed:

• In the web.xml descriptor, we describe an authentication method that is inextricably linked to the policy configuration (for example, the “FORM” authentication method is associated with the policy configuration “form”);
• In the web-j2ee-engine.xml descriptor for Java web applications, we even describe the policy configuration itself with all Login modules. By the way, Policy configurations for such applications are displayed with the Web type (see figure below). Most of the Web Policy configurations are listed, since each Java application for which the developer has created a web-j2ee-engine.xml descriptor or web.xml will be displayed in a separate policy configuration.

• For Portal applications, Web Dynpro Java Applications and iViews, we use Authentication Schemes (Authschemes) and links to them (Authschemes-refs), which are also displayed in the form of Policy configurations, but with the Other type.

We can also create our own policy configurations through the editor in the SAP Netweaver Administrator (NWA) and link them to applications as Templates, or set them in the UME parameters described in the first two articles. Created through the editor policy configurations will be of type Custom.

So, Policy Configuration is an entity that has a set of properties (Properties) and includes an Authentication Stack.

Properties show properties such as: realm_name, policy_domain, priority, template, frontendtarget, auth_method, etc. If the policy configuration is created through the editor manually, then, if necessary, we can also add properties manually. If this is done via web.xml or web-j2ee-engine.xml descriptors, then we will see in properties what the developer asked in these descriptors.

The Authentication Stack is an entity that consists of the elements shown in the following image:



Template . As a template for newly created Authentication Stacks, you can use the already ready Authentication Stack with the “Template” or “Custom” type. In this case, the new Authentication Stack inherits the Login Modules and Session Fixation Protection settings from the template. Logon policy settings are not inherited.

Session Fixation Protection . It can happen that the client software calls two applications with different Authentication stacks almost simultaneously (with a difference of no more than 2 seconds). This is a rare case and in the standard this is unlikely to happen. But if this happens, the server can generate an error 403 - "Possible session fixation error!".

If we are sure that we do not have such applications, then Session Fixation Protection must be set to Strict (it is used by default). If two different applications with different Authentication stacks are to be called in parallel, and this is the only solution in your particular case (which is best avoided), the Session Fixation Protection parameter should be set to Grace Period for the application that generates error 403 - “Possible session fixation attack detected! ... ”.

Policy domain - it was already written in detail in the second part , so I will not repeat.

Login Modules and Logon Policy - both of these elements are the most interesting for us in terms of setting up the authentication stack. Login Modules are directly related to authentication (i.e., client authentication). A Logon Policy is a set of rules that allow or prohibit a user by any criteria from using the Authentication Stack when accessing an application (for example, if the user is not in the Administrators group, then authentication is prohibited).

Login Modules

The login module is a software module that allows the SAP system to verify the authentication data provided by the user. In the standard delivery of SAP Netweaver AS Java 7.40, I counted 21 Login Module and each of them has its own specific parameters for tweaking. The description of each such module separately deserves a separate article, so I will only give a few of the most frequently used modules and give a brief description for them:

• BasicPasswordLoginModule - performs user authentication using the credentials provided through the FORM or BASIC authentication methods (login and password);
• CreateTicketLoginModule - creates an SAP Logon Ticket (that is, essentially creates a session cookie for the client’s web browser), which under certain conditions and for a certain period will be your “passport” for logging into applications;
• EvaluateTicketLoginModule — performs SAP Logon Ticket authentication, obtained using the CreateTicketLoginModule module;
• ClientCertLoginModule - performs user authentication using a client certificate.

The Login Modules tool allows you to link individual modules into a sequence of executable modules to provide a flexible authentication process in the system.

I propose to consider the following sequence of modules:



The figure shows that for each Login Module from this sequence, a flag is specified that determines the behavior of the executed module. In the following sequence will occur the following:

1. The login module EvaluateTicketLoginModule will be executed. If the user's web browser is valid for the SAP Logon Ticket system, subsequent modules will not be executed, as the SUFFICIENT flag is set (ie, this module is sufficient for user authentication and no subsequent modules are required). If the authentication is not successful, then the execution is passed to the next module - ClientCertLoginModule;
2. The ClientCertLoginModule module, receiving data, usually from the CLIENT-CERT authentication method, verifies this data. The figure shows that the OPTIONAL flag is set for this module. This means that regardless of the success or failure of the authentication check by this module, we will move to the next module (in our example, CreateTicketLoginModule), but the result of the check by the ClientCertLoginModule module will be available to the next module in the list, i.e. module CreateTicketLoginModule;
3. The CreateTicketLoginModule module will receive the result of the check by the previous module. In case of successful authentication on the previous module, the SAP Logon Ticket will be generated for the user's web browser and transmitted. Also, CreateTicketLoginModule will perform an authentication check on the issued SAP Logon Ticket (it will certainly succeed) and, given that the SUFFICIENT flag is set for this module, control will be transferred back to the program (subsequent modules will not be executed). In case of unsuccessful authentication by the previous module, the CreateTicketLoginModule module will not issue the SAP Logon Ticket to the user and, of course, will not even check it and, as a result, will simply transfer control to the next module (BasicPasswordLoginModule);
4. In our example, the BasicPasswordLoginModule module has a REQUISITE flag. This means that in case of unsuccessful authentication by this module, subsequent modules will not be executed and control will immediately be sent back to the program with the result - “not successful authentication”. In case of successful authentication, the next module will be executed. Those. in case of successful authentication by login and password, control will be transferred to the CreateTicketLoginModule module, the work of which we have already described.

In our example, for the BasicPasswordLoginModule module, we could set the OPTIONAL flag — nothing would have changed. And for the fifth module (CreateTicketLoginModule) - the flag SUFFICIENT or leave the same OPTIONAL - the result of the whole stack would be the same ...

There is another flag that is not in the example — the REQUIRED flag. In case of any result of module execution with this flag, control will be transferred to the next module. But, if the authentication performed by this module is not successful, then the result of executing the entire stack of modules will also not be successful.

Logon policy

As mentioned earlier, the Logon Policy is a set of rules that allow or prohibit a user, by any criteria, from using the Authentication Stack when accessing an application.

By default, this functionality is not active in the SAP system. Therefore, if you decide to use it, then you need to set the UME parameter: ume.logon.apply_logon_policies to true.

Creating and editing Logon policies is available from the SAP Netweaver Administrator (NWA): Configuration -> Authentication and Single Sign-On. Authentication tab -> Logon Policies).

The structure of the Logon policy is as follows (see figure below):



Logon policy can contain many rules (Rules), and each rule must contain the conditions for the implementation of this rule - Conditions.

The possibilities of Logon Policies are best seen in the following example. Suppose that in a fictional project there is the following task: to certain applications, you must allow access only to the Administrators group from IP addresses 10.1.4.0/32. And in general, let the Administrators work only during working hours - from Monday to Friday, from 8:00 to 18:00. For these purposes, we will create a Logon Policy (for example, MyOwnLogonPolicy) with one rule (for example, MyOwnRule1) and four conditions (see figure below), which will determine our requirements for our fictional project.



In addition to the categories that we have identified in our example (Group, Days Of Week, IP Address, Time), there are other equally interesting categories that can be used:

• User - allows or denies authentication to specific users of the system;
• Role - allows or denies users with specific roles from authenticating;
• HTTP Header - allows or denies authenticating users whose HTTP request header contains certain values. This includes regular expressions for HTTP header values. (see picture below).

Thus, using the HTTP Header category, you can significantly extend the capabilities of Logon Policies.

Conclusion

So, we learned about the approaches and tools that are available in SAP Netweaver AS Java to configure authentication in various types of applications. I hope you find it interesting, and this information will simplify the process of setting up authentication in SAP Netweaver AS Java applications.