Security Policy
Use
The User Management Engine (UME) allows you to define a security policy that controls aspects such as the length and content of user passwords and user IDs, the validity length of user passwords, or the number of failed logon attempts after which a user is locked. The UME checks for compliance to this policy when users log on to the J2EE Engine, when users register themselves using the self-registration features of the UME, when users or administrators change user passwords in the J2EE Engine, or when administrators create new users on the J2EE Engine. If the security policy is not adhered to, the UME provides detailed error messages.
Integration
Integration with Security Policy of UME Data Source (ABAP or LDAP directory)
The UME security policy is independent of the security policy of the UME data source, in particular if the UME uses ABAP user management or an LDAP directory as a data source. It does not take into account any special features of the data source’s security policy. This means that if the data source has defined its own security policy, there is no standard interface to pass on any error messages received from the data source to the UME user in the same level of detail and in the correct language. The user only receives a very generic error message.
For example, the UME security policy specifies a minimum password length of 6 whereas the ABAP user management defines a minimum password length of 8. When an administrator creates a user and defines a password of length 6 for the user, the password adheres to the UME policy but not to the ABAP policy. As a result, the administrator gets a generic error message saying that the password is invalid, but not specifying why it is invalid.
Configuration Options
There are two options to configure the security policy of the UME, both with different implications:
...
1. You define a security policy for the UME that is the same or stronger than the corresponding security policy in the backend 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 very rare cases will you need to look in the log files of the data source (ABAP or LDAP)
Disadvantage: If the backend system can be accessed directly (for example an ABAP system) or serves as data source for other systems using a UME with different security policy settings, users or administrators might get different reactions for different access paths if the security policy is not the same.
2. You define a very relaxed security policy for the UME.
Result: The UME security policy is so relaxed that any violations against the security policy will take place in the data source. The UME does not pass on the error messages from the backend in full detail and as a result users and administrators receive generic error messages.
Implication: Users are confused as to how they violated the security policy. Error tracing becomes more difficult because you need to look in two locations, both in the UME log files and in the backend log files.
If the UME uses ABAP user management as a data source, detailed error messages are written in the security.log file on the J2EE Engine. However, if the UME uses an LDAP directory as a data source, the error messages depend on the LDAP server being used and are written as error codes in the defaultTrace.trcfile on the J2EE Engine. Both of these log files can be viewed using the Log Viewer in the Visual Administrator of the J2EE Engine.
You can also combine these two options, but this makes error tracing very difficult.
For example, you define the minimum and maximum password lengths the same or more stringent than in the backend 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 backend data source.
Recommended Configuration
We recommend that, as far as this is possible, you configure the security policies of the UME and its data source to be the same. As a consequence, any violations to the policy would be caught by the UME. Firstly this means that users would get meaningful error messages. Secondly, error tracing would be easier for the system administrator. Thirdly, you obtain a homogenous security policy, regardless of whether users are created in the data sources using the UME tools or another means.
The only exception to the above recommendation is the configuration for locking users who have made several unsuccessful attempts to log on. 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 following UME property:
ume.logon.security_policy.lock_after_invalid_attempts=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.
Features
The UME security policy provides the following options. You configure the policy by setting UME properties. The properties that you can set are listed under Security Policy. How you set the properties is described in Editing UME Properties.
● Specify the number of failed logon attempts after which a user account is locked. Optionally the system can unlock the user after a certain amount of time elapses.
Related UME properties:
○ ume.logon.security_policy.lock_after_invalid_attempts
○ ume.logon.security_policy.auto_unlock_time
● Specify whether users and administrators can change passwords and if users are required to change the password after their initial log on.
Related UME properties:
○ ume.logon.security_policy.password_change_allowed
○ ume.logon.security_policy.password_change_required
● Define the conditions for password expiration. The user must set a new password after a set number of days. A default start value exists for when the user has never logged in and was created in an external system.
Related UME properties:
○ ume.logon.security_policy.password_expire_days
○ ume.logon.security_policy.password_last_change_date_default
● Define the rules governing what a password looks like. This includes:
¡ The maximum and minimum length of passwords
¡ Whether an old password can be part of a new password
¡ The number of alphabetic and numeric characters required
¡ The number of upper and lower case letters required
¡ The number of special characters required
¡ Whether the user ID can be part of the password
¡ How often a user can use the same password (the number of past passwords saved)
Related UME properties:
○ ume.logon.security_policy.password_max_length
○ ume.logon.security_policy.password_min_length
○ ume.logon.security_policy.oldpass_in_newpass_allowed
○ ume.logon.security_policy.password_alpha_numeric_required
○ ume.logon.security_policy.password_mix_case_required
○ ume.logon.security_policy.password_special_char_required
○ ume.logon.security_policy.userid_in_password_allowed
○ ume.logon.security_policy.password_history
● Define the rules governing what a user ID looks like. This includes:
¡ The maximum and minimum length
¡ The number of numeric characters required
¡ The number of lower case letters required
¡ The number of special characters required
Related UME properties:
○ ume.logon.security_policy.useridmaxlength
○ ume.logon.security_policy.useridminlength
○ ume.logon.security_policy.userid_digits
○ ume.logon.security_policy.userid_lowercase
○ ume.logon.security_policy.userid_special_char_required
● Specify whether the UME logs client host information.
Related UME properties:
○ Ume.logon.security_policy.log_client_hostaddress
○ ume.logon.security_policy.log_client_hostname