One key goal of SAP’s Secure Login solution is to establish secure communication between all required components. SSO enables secure communication with certificate lifecycle management and encryption.
Secure Login for SAP SSO provides support for many advanced security capabilities, such as:
- Encryption of data communication for SAP GUI
- Kerberos/SPNEGO, X.509 certificates, and SAML 2.0 support
- Digital signatures
- FIPS 140-2 certified cryptographic functions
- Two-factor authentication
- Risk-based authentication using access policies
- RFID-based authentication
- Hardware security module support
Establishing Secure Communication
From | To | Protocol/Interface |
---|---|---|
SAP GUI | SAP NetWeaver | DIAG/RFC (SNC) |
Business Explorer | SAP NetWeaver | DIAG/RFC (SNC) |
Business Client | SAP NetWeaver | DIAG/RFC (SNC) |
Web GUI | SAP NetWeaver | DIAG/RFC (SNC), HTTPS |
Secure Login Client | Secure Login Server | HTTPS (SSL) |
Secure Login Server | LDAP Server | HTTPS (SSL) |
Secure Login Server | SAP NetWeaver | RFC (SNC) |
Secure Login Server | RADIUS Server | RADIUS (Shared Secret) |
The preceding table displays the security protocol or interface used to secure communications between various components. The following examples are common SSO standard use cases and the associated process and communication flow.
If you want to take your SSO project a step further and cover SAP and non SAP applications, X.509 digital certificates could be your technology of choice. Most systems and applications support this proven internet standard. There are several options for enabling SSO with X.509 certificates:
Secure Login Service (SLS)
- Part of the product SAP SSO.
- Provides short-lived certificates to end-user desktops and backend systems.
- Advantage: SLS enables scenarios such as multifactor authentication and certificate lifecycle management.
- Disadvantage: SLS is an additional component.
The preceding figure illustrates the authentication process flow for using the Secure Login Service:
- The user opens an SAP GUI connection.
- The user authenticates to the Identity Authentication Service.
- Optionally, authentication can be delegated to a corporate IdP (such as Azure AD).
- After successful authentication, the Cloud Certification Authority (CA) issues an X.509 certificate.
- SAP SLS returns the X.509 certificate, valid for one day, to SLC.
- The X.509 certificate token authenticates the SAP GUI user to the ABAP system.
Existing Certificate
SSO using X.509 certificates can use existing Public Key Infrastructure (PKI) to authenticate users seamlessly across multiple systems and applications. This approach provides robust security by using digital certificates.
- SAP SSO can use an existing certificate for authentication.
- Certificates could, for example, come from a smart card or soft token.
- Advantage: No additional component is required, as the SLC does not need to access the cloud services, and the identity provider cannot authenticate.
- Disadvantage: Some value-added scenarios of SLS are not available and can be complex to configure and manage.
In this scenario, the SLS integrates with the existing enterprise PKI for user and server certificates. As a result, certificate signing remains based on established PKI and security policies. Storage and revocation processes remain unchanged.
Some customers already have an approach in place that provides their end users with an X.509 certificate. Options are for example:
- Smart Card: An X.509 certificate coming from a hardware device.
- Soft Token: An X.509 certificate that is automatically deployed on the user’s desktop, for example from a corporate CA.
Secure Login Client can use these certificates for Single Sign-On to the ABAP system as well if the backend configuration is in place. In that case, the Secure Login Client does not need to access the cloud services and there is no authentication by the identity provider.
For organizations that have set up their own public-key infrastructure (PKI), they can simply use it with SAP Single-Sign On. In this scenario, the SLS integrates with the existing enterprise KPI for both the user and server certificates. As a result, certificate signing remains based on established PKI and security policies. Storage and revocation processes remain unchanged.
More scenarios and tools extend the capabilities for using and maintaining X.509 certificates. For example, instant user identification based on radio frequency identification (RFID) is supported for PC/SC and WaveID RFID reader devices.
For more information about Certificate Lifecycle Management for SSO, see: Configuring Certificate Lifecycle Management in the AS ABAP Using Secure Login Server.
Lesson Summary
You can now describe how the SAP SSO solution provides landscape security.