User Authentication and Single Sign-On

SAP NetWeaver provides a number of mechanisms for user authentication and single sign-on (SSO).

Authentication Methods

Authentication Methods
Method	Description
User ID and password	User ID and password is the standard mechanism supported by all SAP NetWeaver systems. However, the verification routines used depend on the underlying technology as follows: For cases where HTTP is used as the transport protocol, the standard HTTP Basic Authentication and form-based authentication mechanisms are supported. Note When using Basic Authentication, the user's information is passed to the server over the HTTP connection in a header variable as a base-64 encoded string. With form-based authentication, the information is passed as a URL parameter. Note When using user ID and password authentication in productive environments, the preferred authentication method is form-based authentication. For cases where the SAP protocols (dialog and RFC) are used, SAP routines are used. Recommendation In all cases, the user ID and password are only encoded when transported across the network. Therefore, we recommend using encryption at the network layer, either by using the Secure Sockets Layer (SSL) protocol for HTTP connections, or Secure Network Communications (SNC) for the SAP protocols dialog and RFC. For more information, see Network and Communication Security.
Client certificates (X.509)	Many SAP NetWeaver systems also support the use of the SSL protocol and client certificates for user authentication. Authentication takes places using the underlying protocols and no user intervention is necessary, which also provides for an SSO environment. Users need to receive their client certificates from a Certification Authority (CA) as part of a public-key infrastructure (PKI). The CA you choose to use must be designated as a trusted CA on the Web server. Recommendation As X.509 certificates remain valid for a relatively long time, we recommend implementing a method to revoke the certificates to minimize the security risk, for example if a mobile device is lost.

Integration

Single sign-on provides for an environment where users are allowed access to multiple systems based on an initial authentication. The available mechanisms for SAP NetWeaver systems include the following.

Single Sign-On Mechanisms
Mechanism	Description
Logon tickets	Recommendation The standardized authentication methods Kerberos, X.509 certificates, and SAML 2.0 provide additional security and flexibility features compared to proprietary logon tickets. For example, you can define user mappings and shorten token validity periods or session lifetimes on the server. Therefore, we recommend using Kerberos, X.509 certificates, or SAML 2.0 where technically possible. To provide for single sign-on to multiple systems, a user can be issued a logon ticket after being authenticated on the SAP system. This ticket can then be presented to other systems (SAP or non-SAP) as an authentication token. Instead of having to provide a user ID and password for authentication, the user is allowed access to the system after the system has verified the logon ticket. Recommendation When using logon tickets for authentication with Web applications, the user's ticket is stored as a non-persistent cookie in the user's Web browser. This cookie contains the information necessary to log the user on to additional systems without having to provide an explicit password authentication. Therefore, protect the logon ticket from being compromised or manipulated during transfer by using SSL between Internet-enabled components. For more information, see Network and Communication Security. As logon ticket are transferred as browser cookies, you can only use this authentication mechanism if all systems in your system landscape are located within the same DNS domain.
Client certificates (X.509)	When using client certificates for user authentication, the user is re-authenticated with each request using the SSL protocol. However, no user intervention is necessary, which provides for a single sign-on environment for the end user.
Additional mechanisms	Additional mechanisms are also available with SAP NetWeaver, depending on the underlying technology used, for example, using RFC trusted systems between two ABAP servers. For such scenarios, see the security guide for the specific product.

In addition, the use of external authentication mechanisms is also supported by the SAP NetWeaver products.

The following mechanisms are supported.

External Authentication Mechanisms
Mechanism	Description
Secure Network Communications	With SNC, user authentication and single sign-on is supported for connections between the SAP GUI for Windows or SAP GUI for Java and SAP NetWeaver AS for ABAP. In this scenario, the user authentication is performed by an external security product. Supported external security products are certified by the SAP Software Partner Program. SAP also offers SAP Single Sign-On. For more information, see the following: Secure Network Communications (SNC). SAP Single Sign-On
Using header variables or integrated Windows authentication	SAP NetWeaver AS for Java supports the use of header variables for SSO. This means that you can delegate user authentication to any external product, which authenticates the user and returns an authenticated user ID as part of the HTTP header. Users only have to authenticate once against the external product and can then access applications on SAP NetWeaver AS for Java, such as the portal, with SSO. There are security measures to take when using header variables for Single Sign-On. For more information, see Using Header Variables or Integrated Windows Authentication for User Authentication.
Java Authorization and Authentication Service (JAAS)	SAP NetWeaver AS for Java supports the use of external authentication mechanisms using the JAAS specification. In this case, you can include external modules in the login module stack of SAP NetWeaver AS for Java.
Security Assertion Markup Language	The Security Assertion Markup Language (SAML) version 2.0 is a standard for the communication of assertions about principals, typically users. The assertion can include the means by which a subject was authenticated, attributes associated with the subject, and an authorization decision for a given resource. SAML 2.0 provides authentication across domains and enables single log-out from all systems, where the user is logged on. For more information, see SAML 2.0. SAML 2.0 requires the use of an identity provider from an external product. SAP Single Sign-On offers an identity provider. For more information, see SAP Single Sign-On
Kerberos	During logon, Kerberos (or SPNego) authentication requires access to an issuing system (for example, Microsoft Active Directory). As this system is typically located within the corporate network, Kerberos cannot be used for most internet-facing deployment scenarios. To enable SSO with Kerberos from outside your corporate network, you might have to set up a VPN connection. Kerberos is available with SAP Single Sign-On. For more information, see SAP Single Sign-On
OAuth 2.0	With OAuth 2.0, users allow web-based client applications to access the resources. The application that is authorized by the resource owner accesses the resources on behalf of the user. Thus users who do not want to reveal their user names and passwords for the service provider where the resources are located are able to delegate access to the resources using an OAuth 2.0 access token. The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to a resource using OAuth 2.0 scopes either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the resource, or by allowing the third-party application to obtain access on its own behalf. For more information, see OAuth 2.0 Introduction and Concept for AS ABAP.