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
- 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.
||Single Sign-On Mechanism
||SAP User ID and Password
||SAP Logon Ticket
||X.509 Digital Certificates (SAP Trust
||SNC product logon Pluggable Authentication Service
(PAS) Windows NT/Windows 2000
SAP Logon Ticket
||X.509 Digital Certificates
||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'
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 http://service.sap.com/security.
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 (www.SAPpro.com).
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
1 The Internet Engineering Task Force. More
information on IETF standardization is available at www.ietf.org.
2 LDAP (Lightweight Directory Access Protocol).
3 HTTP over the Secure Socket Layer (SSL) protocol.