Integration of the UME Security Policy With External Data Sources

Use

You configure the security policy of the user management engine (UME) independently from the security policy of the ABAP or LDAP server data source. The UME does not take into account any special features of the data source's security policy. If the data source has defined its own security policy, there is no standard interface to pass on any error messages from the data source to the UME user in the same level of detail and in the correct language. The user only receives a generic error message.

Example

The UME security policy specifies a minimum password length of 6 whereas a directory server defines a minimum password length of 8. When an administrator creates a user and enters a password with a length of six for the user, the password adheres to the UME policy but not to the directory server policy. As a result, the administrator receives a generic error message saying that the password is invalid, but not specifying why it is invalid.

ABAP Data Source and LDAP Data Source

To prevent the UME policies from getting in the way of the ABAP policies, the UME ignores its own security policies if you use an ABAP data source with the following exceptions:

When you create a new user, the UME checks the user name against its own security policies.
If you allow the UME to automatically generate a password, the UME generates the password according to its own security policy.
When a user creates a new password, the new password must conform to the UME password rules; for example, number of upper case letters or length. However, the system performs the password history check in the system where the password is stored. For a user stored in the ABAP system, the password history check takes place in the AS ABAP.

In contrast to when you use an AS ABAP as the data source, the UME security policies apply without exception if you use the Java database or an LDAP directory server for the data source.

UME Configuration Options for External Data Sources

You have the following options to configure the security policy of the UME, both with different implications:

Option 1: Same or stronger policy
Option 2: Relaxed policy
Option 3: Combination of options 1 and 2

Option 1: Same or Stronger Policy

Define a security policy for the UME that is the same or stronger than the corresponding security policy in the back-end system.

Result

Users and administrators receive detailed error messages.

Implication

Error tracing is easier because you only need to look in the log files of the UME. Only in rare cases will you need to look in the log files of the data source (ABAP or directory server).

Disadvantage

Users or administrators might experience different reactions for different access paths if the security policy is not the same such as in the following cases:

The back-end system can be accessed directly (for example an ABAP system).
The back-end system serves as a data source for other systems using a UME with different security policy settings.

Option 2: Relaxed Policy

Define a relaxed security policy for the UME.

Result	The UME security policy is so relaxed that only the data source catches any violations against the security policy. The UME cannot pass error messages from the back end in full detail, and as a result, users and administrators receive generic error messages.
Implication	Unexplained policy violations confuse users and administrators as to how they violated the security policy. Error tracing becomes more difficult because you must look in two locations to determine the cause, both in the UME log files and in the back-end log files.

Note

Even if detailed error messages do not appear in the user interface of the UME, the UME writes error messages from the data source in the log files of the AS Java. Where it writes an error message depends on the data source.

If the UME uses ABAP user management as a data source, detailed error messages are written in the security. <n> .log file.
If the UME uses a directory server as a data source, the error messages depend on the directory server being used and are written as error codes in the default trace.

For more information, see Logging and Tracing .

Option 3: Combination

Combine options 1 and 2. This makes error tracing difficult.

Example

Define the minimum and maximum password lengths the same or more stringent than in the back-end data source so that users receive detailed error messages. You define all other security policy settings in the UME to be very relaxed. This means that all other settings are checked by the back-end data source.

Recommended Configuration

We recommend option 1. As far as possible configure the security policies of the UME and its data source to be the same. As a consequence, the UME catches any violations to the policy. This has the following advantages:

Users receive meaningful error messages.
Error tracing is easier for the system administrator.
You obtain a homogenous security policy, regardless of whether you create users in the data sources using the UME tools or another means.

We recommend the following exceptions to the recommended configuration:

Set the auto-lock capability of the UME for locking users who have made several unsuccessful attempts to log on dependent on whether the data source also provides this capability.
- If the UME data source provides this auto-lock capability, you should deactivate the check in the UME. For example, ABAP user management provides this feature, so if you use ABAP user management as a data source, you should deactivate the auto-lock feature in the UME.
  
  To deactivate the auto-lock feature in the UME, set the security policy setting Lock Password on Failed Logon Attempt Number to 0 .
- If the UME data source does not provide the auto-lock function, you can activate it in the UME. In this case, it only applies for logons through the UME.
If all your users are in the user management of an AS ABAP, deactivate the password history in the UME.