APP-04

Control Description

Single Sign-On (SSO) is enabled and utilized as the primary authentication mechanism for the majority of users (evidenced by external user mappings in RSUSR300), while fallback password authentication is governed by the application layer and configured to enforce appropriate parameters (complexity, history, minimum length, expiration, and lockout per company policy, verified via RSPARAM

Risk

Failure to properly configure, secure, and enforce authentication mechanisms (SSO and password parameters) may lead to unauthorized access, credential compromise, or privilege escalation, potentially resulting in unauthorized modifications, data leakage, or corruption within the application environment

Implementation Details

Primary Authentication (SSO):
• Single Sign-On is integrated as the mandatory login mechanism for standard business users via protocols like SAML 2.0 (configured through transaction SSO2 or transaction SAML2). User accounts are bound to external identity providers (IdPs) or directory services, creating external ID mappings verifiable in table RSUSR300.

Fallback Authentication (Local Passwords):
• Local password authentication is retained primarily for system administrators, emergency accounts, or technical/integration users who cannot leverage external SSO.

Parameter Enforcement (RSPARAM):
• Password complexity, history, minimum length, expiration, and account lockout thresholds are strictly governed at the SAP application layer. These security parameters are configured and verified via transaction RSPARAM aligning directly with enterprise password policy (e.g., minimum length rules, failed login lockout counts, and password history constraints).

Test Procedures

Test of Design (ToD):

• Inquire of SAP Basis or Security administration to understand the SSO architecture and the fallback application-layer password policy for non-SSO accounts.

• Inspect the corporate Information Security Policy to establish the required baselines for password length, complexity, expiration, history, and lockout thresholds.

• Understand the configuration logic for SAP parameters, noting that when inspecting RSPARAM, the User-Defined Value" dictates the active setting and overrides the "System Default Value."

Test of Operating Effectiveness (ToE):

• Parameter Verification: Obtain an extract of RSPARAM from the production system. Compare the active values (evaluating the User-Defined Value first) against the corporate policy for the following key parameters:

◘ login/min_password_lng (Minimum length)
◘ login/min_password_digits,
◘ login/min_password_letters,
◘login/min_password_lowercase,
◘login/min_password_uppercase,
◘ login/min_password_specials (Complexity)
◘login/password_expiration_time (Expiration)
◘login/password_history_size (History)
◘ login/fails_to_user_lock (Lockout threshold)
◘ rdisp/gui_auto_logout (Idle timeout)

SSO Utilization Validation:

◘ Obtain a listing of all active dialog and service users from table USR02 (filtered by user type).
◘ Obtain an extract of users mapped for external authentication via report RSUSR300.
◘ Perform a comparison between the USR02 active user population and the RSUSR300 mapping to verify that SSO is actively utilized as the primary authentication mechanism for the vast majority of standard users, and confirm that the remaining password-authenticated users are valid administrative or system exceptions.