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.

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.

Option 3: Combination

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

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.