Single Sign-On (SSO)

Single Sign-On (SSO) in SAP Basis is a crucial aspect of modern enterprise security, streamlining user access to various SAP systems and applications by eliminating the need for repeated authentication. Instead of entering credentials for each system, users authenticate once to a central identity provider and then gain seamless access to all connected SAP resources.

This detailed explanation will cover the most common SSO setup methods in SAP Basis, highlighting critical steps and parameters for each.

I. Understanding SSO Methods in SAP Basis

SAP supports various SSO methods, each suited for different scenarios:

SNC (Secure Network Communication) for SAP GUI & RFC:
- Purpose: Primarily for client-server communication, enabling SSO for SAP GUI users and secure RFC connections between SAP ABAP systems.
- Mechanism: Relies on an external security product (GSS-API V2 library) for strong authentication and encryption.
- Typical use cases: Windows Integrated Authentication (Kerberos), X.509 client certificates, SAP NetWeaver Single Sign-On (SLS).
SAP Logon Tickets (MYSAPSSO2 Cookies):
- Purpose: Enables SSO for web-based applications between SAP NetWeaver ABAP and Java systems (e.g., SAP Enterprise Portal, Fiori Launchpad, SAP BW-Java).
- Mechanism: A central "issuing" system (e.g., Portal) issues a digitally signed cookie (logon ticket) after initial authentication. Other "consuming" systems accept and validate this ticket.
- Typical use cases: Integrating ABAP backend systems with an SAP Portal, Fiori Launchpad, or other Java-based SAP web applications.
SAML 2.0 (Security Assertion Markup Language):
- Purpose: An open standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). Ideal for integrating with external, non-SAP IdPs (e.g., Azure AD, Okta, ADFS) and cloud solutions.
- Mechanism: Browser-based redirection. The user is redirected to the IdP for authentication, and upon success, the IdP sends a signed SAML assertion back to the SAP system (SP).
- Typical use cases: SSO from corporate IdPs, Fiori Launchpad/SAPUI5 applications, SAP Cloud Platform integrations.
X.509 Client Certificates (Direct Authentication):
- Purpose: Strong authentication where users present a digital certificate directly to the SAP system (often via SSL/TLS).
- Mechanism: The SAP system (specifically ICM for web scenarios or SNC for GUI) validates the client certificate against its trusted CAs.
- Typical use cases: High-security environments, smart card integration, situations where strong, non-repudiable authentication is required.

II. SSO Setup using SNC (for SAP GUI and RFC)

SNC provides application-level security, including SSO, for traditional SAP GUI connections and RFC (Remote Function Call) communications.

Prerequisites:

SNC Product: Choose and acquire a GSS-API V2 compliant security product (e.g., SAP NetWeaver Single Sign-On, Microsoft Kerberos for Windows environments, or a third-party PKI solution).
SNC Library: Obtain the GSS-API library file (sapcrypto.dll for Windows, libsapcrypto.so for Unix/Linux) from your chosen vendor.
Trust Establishment:
- Kerberos: Active Directory (AD) configured, and Service Principal Names (SPNs) created for SAP application server service accounts.
- X.509: A Public Key Infrastructure (PKI) in place to issue and manage X.509 client and server certificates.

Critical Steps:

Install SNC Library on SAP Application Server:
- Place the sapcrypto.dll (Windows) or libsapcrypto.so (Unix/Linux) file in a designated, secure directory (e.g., /usr/sap/<SID>/SYS/exe/run or a separate sec directory).
- Ensure proper file system permissions.
- Set the SNC_LIB environment variable for the <sid>adm user (or SAP service user on Windows) to the full path of the library.
Configure Profile Parameters on SAP Application Server (RZ10):
- snc/enable = 1: Activates SNC for the application server. This parameter requires an application server restart.
- snc/gssapi_lib = <full_path_to_snc_library>: Specifies the path to the SNC GSS-API library. (While SNC_LIB env var is often used, specifying it here is also common).
- snc/identity/as = <SNC_Name_of_AS>: Defines the unique SNC name (principal name or distinguished name) of the application server. This is crucial for mutual authentication between client and server.
  - Kerberos Example: p:SAPService<SID>@<YOUR_DOMAIN.COM> (where SAPService<SID> is the Windows service account for the SAP instance).
  - X.509 Example: p:CN=<hostname_fqdn>, OU=<OrgUnit>, O=<Organization>, C=<Country> (matching the Distinguished Name (DN) of the server's X.509 certificate).
- snc/data_protection/min = 3: Minimum Quality of Protection (QoP). For SSO with encryption, set to 3 (Confidentiality).
- snc/data_protection/max = 3: Maximum QoP.
- snc/data_protection/use = 3: Default QoP for outgoing connections initiated by the AS.
- snc/accept_insecure_gui = 0: Critical for enforcing SSO for SAP GUI. If set to 0, only SNC-secured SAP GUI logons are allowed. Set to 1 temporarily for testing if needed, but change to 0 for production.
- snc/accept_insecure_rfc = 0: Similar to above, but for RFC connections. Enforce 0 for secure RFC communication.
- snc/accept_insecure_cpic = 0: Similar to above, for CPIC connections.
- snc/extid_support = 1: Enables support for external IDs, allowing mapping of external user identities (from SNC) to SAP user IDs.
- login/extid_entity_type = P: Specifies that the external ID type is a 'Principal' (standard for SNC).
- login/password_change_for_SSO = 0: (Optional) If 0, users cannot change their password when logging in via SSO, as password management is handled by the IdP.
- Restart the SAP application server(s) after changing these parameters.
Establish Server Credentials (PKI only - STRUST or sapgenpse):
- If using X.509 certificates, generate a Personal Security Environment (PSE) for the application server.
- Import the server's private key and certificate into the "SNC (SAP Cryptographic Lib)" PSE in STRUST.
- Ensure the snc/identity/as value matches the Subject DN of the server's certificate.
Map External User IDs to SAP Users (SU01):
- For each SAP user that will use SNC-based SSO:
  - Go to transaction SU01.
  - Navigate to the "SNC" tab.
  - Enter the user's external SNC name. This name must exactly match the user's identity from the external security product.
    - Kerberos Example: p:<Windows_User_ID>@<DOMAIN.COM> (e.g., p:JOHNDOE@MYCORP.GLOBAL).
    - X.509 Example: p:CN=<User Name>, OU=<Org Unit>, O=<Organization>, C=<Country> (matching the Subject DN of the user's client certificate).
Configure SAP GUI Client:
- Open SAP Logon Pad.
- Edit the properties of the SAP system connection.
- Go to the "Network" tab.
- Check "Activate Secure Network Communication."
- SNC Name of Partner: Enter the exact snc/identity/as value of the SAP application server (configured in step 2).
- SNC Library: Browse to the client-side GSS-API library file (e.g., C:\Program Files\SAP\FrontEnd\SAPgui\sapcrypto.dll).
- Protection Quality: Set to 3 (Confidentiality), or "Max. available" if applicable.
- Ensure the client workstation has the necessary credentials (Kerberos ticket, X.509 certificate) available and accessible by the SAP GUI.

III. SSO Setup using SAP Logon Tickets (for Web Applications)

This method is ideal for creating SSO environments involving multiple SAP NetWeaver systems, especially with a central SAP Enterprise Portal or Fiori Launchpad acting as the initial authentication point.

Critical Steps:

Configure the Issuing System (e.g., SAP Enterprise Portal - AS Java):
- Generate Key Pair: In SAP NetWeaver Administrator (NWA) -> "Configuration" -> "Security" -> "Certificates and Keys" -> "Key Storage" -> "TicketKeystore", ensure the SAPLogonTicketKeypair-cert is valid. This key pair is used to digitally sign the logon tickets.
- Export Certificate: Export the public key certificate of the SAPLogonTicketKeypair-cert from the issuing system (e.g., Portal) in Base64 or X.509 format.
- UME Configuration: Ensure the login.ticket_client property in the UME is set to a client that will be the "origin" of the tickets (e.g., 000, 888). This client should ideally not exist in the consuming ABAP systems.
- login/create_sso2_ticket parameter: While this is typically an ABAP parameter, for consistency, the Java system also conceptually "creates" the ticket.
- Set Fully Qualified Domain Names (FQDNs): Ensure all relevant hostnames (Java system, Web Dispatcher if used) are configured with FQDNs.
Configure Consuming Systems (SAP ABAP - ECC, S/4HANA):
- Import Issuing System's Certificate (STRUST / STRUSTSSO2):
  - Log in to each consuming ABAP system (e.g., client 000).
  - Go to transaction STRUST (or STRUSTSSO2).
  - Select the "SSO Logon Ticket" PSE.
  - Import the exported public key certificate of the issuing system (from Step 1).
  - Add to Certificate List: Add the imported certificate to the list.
  - Add to ACL (Access Control List): This is CRITICAL.
    - Enter the System ID (SID) of the issuing system (e.g., P01 for Portal). This is typically derived from the Common Name (CN=) in the certificate's Subject DN.
    - Enter the Client from which the tickets will be issued (e.g., 000 or 888, matching login.ticket_client on the Portal).
    - Activate CPIC/RFC and Ext. ID: Ensure these checkboxes are ticked in the ACL entry.
  - Save the STRUST changes.
- Configure Profile Parameters (RZ10):
  - login/accept_sso2_ticket = 1: Enables the ABAP system to accept logon tickets. (Requires AS restart)
  - login/create_sso2_ticket = 0: (Generally 0 for consuming systems). If this ABAP system also needs to issue tickets for other systems, set to 1 (tickets with certificate) or 2 (tickets without certificate - recommended for smaller size). (Requires AS restart)
  - icm/host_name_full = <FQDN_of_ABAP_Host>: Crucial for web-based SSO. Ensure the Fully Qualified Domain Name of the ABAP application server is correctly set. This is vital for proper cookie domain handling. (Requires ICM restart, often full AS restart).
  - icm/server_port_<xx> = PROT=HTTP, PORT=<port>, TIMEOUT=600, PROCTIMEOUT=600, EXTBIND=1: Ensure the Internet Communication Manager (ICM) is configured and listening on appropriate HTTP/HTTPS ports for web access.
  - rdisp/gui_auto_logon = 0: Prevents the standard logon screen from appearing automatically if SSO is successful.
- Restart the SAP application server(s) after changing these parameters.
User Mapping:
- Ensure that the user IDs in the issuing system (e.g., Portal) are either identical to the user IDs in the consuming ABAP systems, or that a proper user mapping mechanism is in place (e.g., configured in UME properties or a custom user exit).

Parameters for SAP Logon Ticket SSO:

Parameter Name	Value	Description
`login/accept_sso2_ticket`	`1`	Enables the system to accept logon tickets. (Mandatory for consuming systems)
`login/create_sso2_ticket`	`0`, `1`, `2`	`0`: System does not create tickets. `1`: Creates tickets including certificate (larger). `2`: Creates tickets without certificate (smaller, recommended for issuing systems). (Set to `0` for pure consuming systems, `1` or `2` for issuing systems).
`icm/host_name_full`	`<FQDN>`	Fully Qualified Domain Name of the host. Essential for correct cookie domain and web-based access.
`login/ticket_expiration_time`	(e.g., `8`)	Validity period of the issued logon ticket in hours. Default is often 8.
`login/ticket_only_by_https`	`1`	If `1`, the browser only sends the ticket over HTTPS connections, enhancing security. Recommended.
`login/ticket_only_to_host`	`0`	If `0`, the ticket is sent to all servers in the domain. If `1`, only to the server that created it. For landscape-wide SSO, `0` is usually required.
`rdisp/gui_auto_logon`	`0`	Disables the automatic display of the SAP GUI logon screen if SSO is successful.

IV. SSO Setup using SAML 2.0 (for Web Applications)

SAML 2.0 is the modern, open standard for web-based SSO, highly flexible for integration with various Identity Providers, including cloud-based ones.

Critical Steps:

Activate SAML 2.0 Service Provider (SAML2):
- Log in to the SAP ABAP system (Service Provider, SP) in client 000.
- Go to transaction SAML2.
- Click "Enable SAML 2.0 support."
- Provide a local provider name (e.g., SAPERP_SP).
- Choose a signing key pair. If none exists, create a self-signed one or import from a CA. This key is used to sign SAML requests sent by the SAP SP.
- Set the "Digest Algorithm" (e.g., SHA256).
Configure Identity Provider (IdP):
- Export SP Metadata: In SAML2 transaction, click "Local Provider" tab, then "Metadata." Export the XML metadata file. This file contains the SAP system's (SP's) public key, endpoints, and other information required by the IdP.
- Import SP Metadata to IdP: Import this XML file into your Identity Provider (e.g., Azure AD, ADFS, Okta). Configure the IdP to recognize the SAP system as a trusted Service Provider.
- Configure User Attributes: Configure the IdP to send the necessary user attributes (e.g., NameID - typically the SAP username or email) in the SAML assertion.
Configure SAML 2.0 Trust in SAP (SP):
- Export IdP Metadata: From your Identity Provider, export its SAML 2.0 metadata XML file.
- Import IdP Metadata to SAP (SAML2):
  - In SAML2 transaction, go to the "Trusted Providers" tab.
  - Click "Add" -> "Upload Metadata File."
  - Select the IdP metadata XML file.
  - Review the imported settings, especially the "Authentication Contexts" and "Federation" (NameID format).
  - User ID Mapping: Crucially, configure how the NameID from the SAML assertion will map to an SAP user ID. Options include:
    - Email to User Logon Alias (e.g., email from IdP maps to SU01's Logon Alias).
    - Unspecified or Persistent to User Name (direct mapping).
    - Using a "user mapping" module (e.g., based on attributes).
- Activate IdP: After configuration, activate the trusted IdP.
Configure HTTP/HTTPS Services (SICF):
- Activate the following ICF services in SICF:
  - /sap/public/bc/sec/saml2
  - /sap/bc/webdynpro/sap/saml2
  - /sap/public/bc/sec/cdc_ext_service (if using Central User Administration / CDC for user mapping)
- Ensure the relevant application services (e.g., Fiori Launchpad's /sap/bc/ui5_ui5/sap/ar_srvc_launch) are set to use SAML2 as the authentication method in SICF settings (Service / Handler List tab -> Logon Data).
Profile Parameters (RZ10):
- icm/host_name_full = <FQDN_of_ABAP_Host>: Mandatory for web SSO. Ensure this is the Fully Qualified Domain Name of the SAP application server, consistently used across all web components.
- login/disable_sso_ticket = 0: (Default) Ensures SAML doesn't disable logon tickets if both are intended.
- login/ticket_only_by_https = 1: (Recommended) Ensures cookies are only sent over HTTPS.
- Restart ICM/AS after changing relevant parameters.

Key Parameters for SAML 2.0 SSO:

Parameter Name	Value	Description
`icm/host_name_full`	`<FQDN>`	Crucial for web-based SSO. Must be the exact FQDN of the application server.
(No direct SAML-specific parameters in `RZ10`, most configuration is in `SAML2` transaction)		SAML configuration is primarily driven by `SAML2` transaction, which manages service provider settings, trusted identity providers, and their corresponding authentication contexts.

V. SSO Setup using X.509 Client Certificates (Direct Authentication)

This method provides highly secure SSO by using client-side digital certificates for authentication, often via SSL/TLS.

Prerequisites:

PKI: A robust Public Key Infrastructure (PKI) capable of issuing and revoking X.509 client certificates to individual users.
SSL/TLS configured: The SAP system's ICM must be configured for SSL/TLS (HTTPS) to enable client certificate authentication. This involves creating an SSL server PSE in STRUST and configuring ICM ports for HTTPS.

Critical Steps:

Configure ICM for Client Certificates (RZ10 & SMICM):
- icm/server_port_<xx> = PROT=HTTPS, PORT=<port>, TIMEOUT=600, PROCTIMEOUT=600, EXTBIND=1, SSLCLIENTAUTH=1: Crucial. Set SSLCLIENTAUTH=1 (or 2 for optional certificate) for the HTTPS port to request client certificates from the browser/client.
- icm/host_name_full = <FQDN_of_ABAP_Host>: Ensure FQDN is correctly configured.
- Restart ICM/AS.
Maintain Trusted CAs (STRUST):
- Go to STRUST.
- Select the "SSL Server Standard" (or relevant SSL server) PSE.
- Import the Root CA certificate(s) and any Intermediate CA certificate(s) that signed your user client certificates into the "Certificate List" of this PSE. This allows the SAP server to verify the authenticity of client certificates presented.
Map Client Certificates to SAP Users (SU01 or Rules):
- Option 1: Manual Mapping (SU01):
  - For each SAP user, go to SU01 -> "Certificates" tab.
  - Import the user's client certificate.
  - Map the user's distinguished name (DN) from the certificate to their SAP user ID.
- Option 2: Rule-Based Mapping (CERTRULE transaction - more scalable):
  - Define rules to map certificate attributes (e.g., Common Name, Email Address) to SAP user attributes (e.g., Logon Alias, Username).
  - This is highly recommended for large user bases, as it automates mapping.
Activate Relevant ICF Services (SICF):
- For web applications, ensure the SICF services for the application (e.g., WebGui, Fiori Launchpad) have the correct "Logon Data" settings to use "Client Certificate" as an authentication option.

Key Parameters for X.509 Client Certificate SSO:

Parameter Name	Value	Description
`icm/server_port_<xx>`	`..., SSLCLIENTAUTH=1/2`	`SSLCLIENTAUTH=1` (mandatory client certificate) or `2` (optional client certificate). This tells ICM to request and validate client certificates over HTTPS.
`icm/host_name_full`	`<FQDN>`	Fully Qualified Domain Name of the host. Essential for correct certificate validation and URL resolution.
`login/extid_entity_type`	`DN`	Specifies that the external ID type for user mapping is a Distinguished Name (from the X.509 certificate).
`login/extid_mapping`	`1`	Enables external ID mapping.
`auth/sec_logon_crt`	`1`	Enables logon with X.509 client certificates.
`auth/rfc_security_config`	`RFC_ONLY`	(Optional) For RFC with certificates.

VI. General Best Practices for SSO in SAP Basis

FQDN Consistency: Ensure all systems (ABAP, Java, Web Dispatcher, IdP) are consistently configured with Fully Qualified Domain Names (FQDNs). This is paramount for certificate validation and cookie handling.
Time Synchronization: Critical for Kerberos and certificate-based SSO. Ensure all systems are synchronized with an NTP server.
User Mapping Strategy: Plan your user mapping carefully. Direct 1:1 mapping (e.g., SAP user ID = AD user ID) is simplest. Rule-based mapping (for certificates/SAML) or attribute mapping (for SAML) offers more flexibility.
Certificate Management: If using PKI, establish robust processes for certificate issuance, renewal, and revocation. Expired certificates are a common cause of SSO failures.
Test Thoroughly: Implement SSO in development and quality systems before moving to production. Test all possible logon scenarios (GUI, web, RFC, different users).
Security Audit: Review security audit logs (SM20 for ABAP, HANA audit logs, IdP logs) regularly to monitor SSO events and detect anomalies.
Disaster Recovery: Plan for SSO failure scenarios. Ensure there's always a fallback (e.g., a "break glass" user with password login) in case the SSO system is unavailable.
Centralized Identity Management: Integrate SAP SSO with a central Identity and Access Management (IAM) solution for a holistic security approach.

Implementing SSO in SAP Basis is a complex but rewarding endeavor that significantly enhances both security and user experience. It requires a detailed understanding of the chosen technologies, meticulous configuration, and ongoing maintenance.

Rakshit Ranjan Singh

Search This Blog