SAP Portal - FAQ 5

1. What is the difference between authentication and Single Sign-On?
In computer security, authentication is the process by which a computer, computer program, or another user attempts to confirm that the computer, computer program, or user from whom the second party has received some communication is, or is not, the claimed first party.
Single Sign-On is the subsequent automated authentication for additional systems after the user has logged on once. In this case, the authenticating system passes the user information to the subsequently called system. This is done in the background; that is, the user does not need to authenticate himself or herself again after his or her first logon.

2. What options are there for authentication for the SAP Web Application Server?

2.1 Web-based authentication methods
• Anonymous/ guest access
• User ID/ password (only authentication, not Single Sign-On)
o Form based
o Basic authentication
• X.509 digital certificates
• SAP Logon Tickets
• External authentication methods
o HTTP header variable authentication (not ABAP except for X.509 certificate information forwarding)
o Security Assertion Markup Language (SAML – only Java)
o Through Java Authentication and Authorization Services (JAAS – only Java). External authentication can be performed using a JAAS module with SAP Web Application Server 6.30. The module is not supplied by SAP, but can be implemented by customers and connected using a standardized interface. JAAS allows you to set a separate authentication mechanism for each application

2.2 SAP GUI for Windows
• SAP-certified SNC product, external security product (authentication takes place outside of SAP system)
• SAP provided wrappers for Microsoft Windows authentication mechanisms:
o Windows NTLM
o Windows 2000 Kerberos
• SAP Shortcut Method (SAP Logon Ticket)
SNC is an integration layer with which a partner product for user authentication can be included in the SAP system landscape. SNC can only be used with SAP protocols (DIAG, RFC, SAP ITS AGate/WGate), and not with the Internet protocol HTTP. This means that it cannot be used with SAP GUI for HTML; only SAP GUI for Java und SAP GUI for Windows can be secured using SNC. Pluggable Authentication Service (PAS) can be used for Web-based access - see below.
In addition to the integration of a third-party product, you can also use existing authentication infrastructures, for example for Microsoft Windows NT or Microsoft Windows 2000 through SNC. For an overview of the partner products certified by SAP for this interface (which is based on the Generic Security Services [GSS] standard), see Security Partners.
The user logs on to the partner product; the SNC user name is then mapped to the SAP user name. The SAP system accepts the logon information, and additional authentication is not required. Security mechanisms of different strengths can be used, such as, such as Public-Key cryptography or Kerberos, depending on the product you are using.
SAP provides mapping libraries free of charge for Microsoft Windows NT and Microsoft Windows 2000. These do not contain any cryptographic functions themselves, but rather access the relevant Microsoft Security Provider APIs. These can be used instead of a partner product.
For more information, see http://service.sap.com/security > Security in Detail > Secure System Management

2.3 SAP WebGUI
• X.509 client certificate
• SAP Logon Ticket
**

3. What options are there for single sign-on for SAP GUI?
The procedure used for Single Sign-On depends on the SAP GUI in use.
SAP GUI for HTML (Available with SAP Web AS and SAP ITS)
• SSO can be implemented using SAP Logon Tickets. This is a proprietary SAP solution, contain in the standard version of the software. For more information about SAP Logon Tickets, see How do SAP logon tickets work?.
• SSO can also be implemented using digital certificates - see authentication. There are advantages and disadvantages to this approach, as described under Which is the most secure option?.
• For the ITS, you can also implement external authentication using the Pluggable Authentication Service (PAS). For more information, see Is it possible to connect products from external vendors to implement authentication and SSO outside the SAP system. For more detailed information, see the relevant documentation.
SAP GUI for Java
• SNC can be used in this case; see also Is it possible to connect products from external vendors to implement authentication and SSO outside the SAP system.
SAP GUI for Windows
• You can implement SSO using SNC through a partner product; see also Is it possible to connect products from external vendors to implement authentication and SSO outside the SAP system.
• A cost-effective alternative to a partner product is to use Microsoft Windows NTLM or Microsoft Kerberos, which is contained in Microsoft operating systems at no additional cost. This variant can only be implemented in a purely Microsoft environment; if other components are used, you must purchase an additional partner product (for more information, see SAP Note 352295). For information about certified partners that provide suitable products for SNC, see Security Partners.
• You can implement SSO using SAP Shortcuts. These are available as of SAP R/3 4.0B under Microsoft Windows NT and Microsoft Windows 95 installations. SAP Shortcuts are useful for frequently used transactions or reports; a shortcut of this type means that they can be started directly from the desktop. System data, the name of the transaction or report, and the user’s logon data are stored in the shortcut. The password can also be stored here; this means that it is not necessary to enter it again during the logon. However, we recommend that you exercise caution in this situation: SAP Shortcuts store the logon data directly on the front end. As any user that can access the front end desktop can also activate the shortcut, if there is a lack of security at the front end, there is a danger that the logon data will be misused. The SAP Shortcut could also be copied to another front end computer, if access to the file system is not appropriately secured. Passwords should therefore only be stored in SAP Shortcuts if there is adequate security at the front end. You should also note that this is not a genuine Single Sign-On scenario, as each SAP Shortcut is a separate logon to the relevant SAP system. However, an actual Single Sign-On solution for SAP Shortcuts can be implemented in connection with SNC. As of SAP R/3 4.5, the SNC procedure for SSO also applies for SAP Shortcuts. For more information about SAP Shortcuts, see the SAP R/3 online documentation (as of SAP R/3 4.5) under General Information > Getting Started with R/3 > Daily Start-Up/Shutdown of the R/3 System > SAP Shortcut and SAP Note 99054 .
**
4. Must a user have the same password in all systems that are part of an SSO landscape?
No. The passwords can be different in the different systems; this does not affect the setting up of Single Sign-On in any way.

5. After a year, Single Sign-On suddenly no longer works. What could the reason for this be?
This error can occur due to an expired server certificate on the system that issues the SAP Logon Tickets. Certificates for servers, which are signed by a Certification Authority (CA) such as the SAP Trust Center Service (SAP_CA), are usually valid for a year. Although the SAP Logon Tickets for SSO are still issued after this period, an error message is triggered by the receiving system when it checks the certificates. "Self-signed" certificates, which are not issued by a CA, but by the server itself, usually have a significantly longer validity period. To avoid the certificates expiring in future, a new report has been created that provides warning in good time before the expiration of the validity of installed certificates. For more information about this, see SAP Notes 572035(Warning about expired security certificates) and 499386 ("Invalid logon ticket" for CA certificates).

6. How do SAP logon tickets work? Can they also be used to include non-SAP products in an SSO environment?
SAP Logon Tickets generate SSO for SAP solutions with Web-based access, that is, for applications that are based on SAP Web Application Server or SAP ITS. An SAP Logon Ticket is used only for the purposes of SSO and cannot be used for initial authentication. To obtain a Logon Ticket, the user must first logon using a different procedure, such as a user name and a password or a digital certificate. The Logon Ticket is contained in a cookie that is forwarded to the user’s Web browser by the issuing system. It is forwarded from the user’s browser to the subsequently called systems that are integrated into the SSO landscape. The user logs on only once. The ticket itself contains the user name, a timestamp, information about the issuing system, and a certain validity period, which can be configured using a system profile parameter , and which can range from a few minutes to several hours. To protect the authenticity and the integrity of the ticket, it is digitally signed by the issuing system. The prerequisite for the use of SAP Logon Tickets is the use of identical user names in the systems that issue and accept the ticket. The SAP Enterprise Portal is an exception to this rule; in this case, an external user name can be specified in the ticket itself.
The advantage of SAP Logon Tickets over an SSO solution using digital certificates is that the (person-related) Public-Key Infrastructure, which is required to administer digital certificates and can be cost-intensive, is not required. Logon Tickets that have already been checked can be buffered for the duration of their validity, which improves performance. To avoid it being stolen through interception, the ticket should be protected using SSL. Many external systems can also be configured to accept and verify SAP Logon Tickets. You can do this using a library provided by SAP, which is then integrated into the external software. The following SAP systems can issues SAP Logon Tickets: systems as of SAP Basis 4.6C (see SAP Note 358469), SAP Web Application Server 6.10 and above, SAP Enterprise Portal 5.0 and above. SAP systems as of SAP Basis 4.0 can accept SAP Logon Tickets (see SAP Note 177895).

7. Are authentication and SSO connected with Central User Administration (CUA)?
No. Central User Administration simply centralizes the administration of user and role data across a large number of SAP systems. The data contained there only applies after the user has already logged on; authentication and, if appropriate, Single Sign-On have therefore already taken place. Setting up a CUA therefore does not affect authentication and SSO procedures in any way; however, it does provide the basis for the use of SAP Logon Tickets due to the assignment of uniform cross-system user names. Implementing CUA also does not provide any form of password synchronization between the central and child systems. Initial passwords are an exception to this rule, and it is also possible to reset passwords. This can be done both in the local child systems and in the central system (with distribution to selected systems).

8. Are authentication and SSO connected with LDAP user data synchronization (LDAP Connector, LDAPMAP)?
No. Since SAP Basis 4.6, SAP systems have had an LDAP Connector, which allows connection to an LDAP directory. However, only individual accesses to the LDAP directory are possible in this version. Data synchronization between SAP R/3 and the LDAP directory was standardized with SAP Web AS 6.10, and mass synchronization is possible. The data synchronization applies only to user and role data, however. Authentication and SSO functions are provided neither using the LDAP Connector nor through transaction LDAPMAP. For information about transferring an external authentication to the LDAP directory, see Is it possible to connect products from external vendors to implement authentication and SSO outside the SAP system?.

9. How do authentication and SSO work in the SAP NW Portal?
The SAP Netweaver Portal offers the same possibilities for user authentication as SAP Netweaver AS Java. In Addition Account Aggregation ist supported. With this procedure, a portal user (or a user group) is associated with the user name and password for an application. This allows SSO even for applications that cannot accept SAP Logon Tickets. The administrator, or the user can perform the required mapping using a graphical interface. The portal stores the data in the portal database. For security reasons, all password information is encrypted using a triple DES algorithm.
For more information about authentication and SSO in the SAP Enterprise Portal, see Solution in Detail: Security in the mySAP Enterprise Portal.

10. Does SAP offer a Trust Center?
Yes. For more information, see the SAP Service Marketplace using the alias TCS. SAP offers client certificates, server certificates, for example, for Secure Socket Layer, and router certificates for service connections through SAPRouter.

11. Where is the SAP Passport physically stored?
Passports are stored wherever the browser stores its certificates. In the case of Microsoft Internet Explorer, this is the registry. You can usually also replace the browser storage using a third party product, for example a smart card or a central Personal Security Environment (PSE) server.

12. SAP Passports - where can I learn more about it?
On SAP Service Marketplace at htttp://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000282722& you find a detailed description of the process in the presentation "SAP Passports - How to get started". To test SAP passport functionality in your SAP Workplace, please generate a Certificate Request (CR) and send message on component BC-SEC to SAP via SAP Net R/3 Frontend (OSS) or SAP Service Marketplace. We will send you the necessary certificate for your Registration Authority (RA).

13. Does SAP also support newer standards, such as SAML or the Liberty Alliance Project?
Security Assertion Markup Language (SAML) With SAP Web Application Server 6.30, the SAP J2EE Engine can accept SAML tickets for logon in the browser artifact scenario. For more information about SAML,
SAP is a sponsor of Liberty Alliance Project, an initiative to establish a standard for federated digital identities on the Web. Its aim is to use specifications to develop open standards that can be used internationally across industries.