Expand +



Single Sign-On with SAP Systems

by Jurgen Schneider | SAPinsider

July 1, 2001

by Jurgen Schneider, SAP AG SAPinsider - 2001 (Volume 2), July (Issue 3)

In these days of increasing diversity and connectivity of business applications, Single Sign-On is one of the top features on the wish list of enterprises and external portals. The security of business application systems demands that users of these systems be known and authenticated before access is granted to critical transactions and data. But how does this affect your everyday working experience?

  • When you arrive at your office in the morning, how many passwords do you need to remember?
  • How many user IDs do you provide to the various applications in your enterprise before you can effectively start working?
  • How often do you have to input your password over the course of a workday?
  • Because of this, do you actually use long and complicated passwords and change them regularly as your company security policy suggests?

     Most users accept that they have to identify themselves once or twice a day. But too many logon prompts from different systems (or repeated logon prompts from the same system) quickly become annoying, and result in reduced applications acceptance and user productivity. This can have serious negative effects on the security of your systems, because users start to choose simple passwords, which are also easy to guess - or, worse yet, write them down on a piece of paper and put it under the keyboard! Users would prefer and benefit from logging in only once a day, and letting the security infrastructure do the rest.

     This is what Single Sign-On is all about. Users sign-on once (we call this "initial authentication"), and the security infrastructure takes care of repeated user authentication as required by the applications without user interven- tion (the "Single Sign-On mechanism").

Why Is Single Sign-On Really Useful?

     With Single Sign-On, you only need to enforce one secure authentication process, and your users are more likely to fully support one process than many. With only a single sign-on action, users get access to all the systems and applications they need for their daily work, which results in increased motivation and productivity.

What Are the Challenges of Single Sign-On?

     To be really useful, Single Sign-On needs to work across your whole landscape of systems and applications. This includes different vendors, providers, system layers, network zones, and so on. Ideally, your Single Sign-On would work transparently in your intranet and on the Internet. And all this needs to be achieved without compromising the security of your users and applications.

How Can Users Securely Sign On to SAP Systems?

     If you think the only way to log on to an SAP system is by means of SAP user ID and password, let me describe some other, very interesting options for the ini-tial authentication of SAP users. Actually, a wide variety of logon variants are possible with SAP systems today, depending on release and configuration status.

     With SAP's Secure Network Communications (SNC), there is an SAP-certified interface for user authentication with partner products, available since SAP Basis Release 3.1H. SNC relies on an IETF1 Standard, the Generic Security Services API Version 2, and can be used for logon via the SAP Protocols DIAG (SAP Graphical User Interface) and RFC (Remote Function Call).

     For logon from a web browser, SAP Pluggable Authentication Services (PAS) were introduced with the SAP Internet Transaction Server (ITS) and SAP Basis Release 4.6D. SNC and PAS can be used to integrate SAP systems into an existing security infrastructure, such as Windows NT domains or Windows 2000. And as of SAP Basis Release 4.5B, SAP logon using web technology is also possible using X.509 digital certificates, thereby exploiting the benefits of a Public Key Infrastructure (PKI).

     So, you can build your user authen-tication on the SAP user ID and password, but also integrate your SAP systems into externally provided authentication frameworks. Typically, such frameworks today are built on central authentication servers (such as the Windows NT Domain Controller or a Kerberos system), LDAP-accessible2 directories, or a PKI.

How Is Single Sign-On Achieved by SAP Systems?

     With SNC, your SAP systems use the Single Sign-On services from the external authentication infrastructure. With X.509 digital certificates, your SAP systems use the services provided by the PKI in place. This technology even allows extension of the Single Sign-On into the Internet.

     For all the other initial authentication options, Single Sign-On is achieved with the SAP Logon Ticket mechanism. The SAP Logon Ticket was introduced with SAP Basis Release 4.6D and mySAP Workplace 2.10. After initial logon, the SAP System creates a digitally signed ticket that is stored in the user's web browser as a non-persistent cookie. This cookie and the SAP Logon Ticket it contains is sent back to the issuing system and to component systems of the mySAP Workplace, for example, with each new web request following the initial authentication.

     With the required SAP kernel patches installed, SAP systems accept the SAP Logon Ticket down to SAP Basis Release 4.0B. For third-party applications, SAP provides the ticket verification routines as a C runtime library, COM object, or Java class.

     Figure 1 provides an overview of authentication options combined with Single Sign-On for SAP Systems.

Authentication Single Sign-On Mechanism
SAP Infrastructure SAP User ID and Password SAP Logon Ticket
Certificate Password/PIN X.509 Digital Certificates (SAP Trust Center)
External Infrastructure SNC product logon Pluggable Authentication Service (PAS) Windows NT/Windows 2000 SNC
SAP Logon Ticket
Certificate Password/PIN X.509 Digital Certificates
Figure 1 SAP Single Sign-On Solutions

How Is SAP Single Sign-On Protected?

     You should not have to simply accept that your systems and applications participating in Single Sign-On have to reduce their own access controls or even switch off their own authentication. You should also not have to accept that your users' passwords are stored in cleartext somewhere and used on their behalf to accomplish Single Sign-On. Single Sign-On can easily become a "multiple break-in" this way!

     SAP's Single Sign-On mechanisms avoid such security deficiencies. However, depending on whether the SAP Logon Ticket or X.509 digital certificates are used, additional security measures are required. The SAP Logon Ticket and HTTP cookie mechanisms demand deployment of HTTPS3 to protect this information from eavesdropping on network communications. Use of X.509 digital certificates requires ap-propriate storage protection of the pri-vate keys that match users' certificates.

For Further Information

     SAP offers a number of documents that you should study to assess and select the appropriate Single Sign-On solution for your SAP systems. The document "Single Sign-On with the mySAP Workplace" provides a complete overview, and is available with other documentation at the SAP Service Marketplace at

     In addition, look for a full technical article, "Is User 'Sally Smith' Really Who She Claims to Be?! Lessons for Establishing Rock-Solid Authentication and Single Sign-On (SSO) Practices" in the July/August 2001 issue of SAP Professional Journal (

Dr. Jurgen Schneider has been involved in the design and implementation of SAP security functions since 1996. Since 1998, he has been the Development Manager for Security in SAP's Technology Development. He can be reached at

1 The Internet Engineering Task Force. More information on IETF standardization is available at

2 LDAP (Lightweight Directory Access Protocol).

3 HTTP over the Secure Socket Layer (SSL) protocol.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!