Symptom
You are having problems with your implementation of Single Sign-On (SSO).
Other Terms
logon, login, Single Sign-On, SSO, authentication, SNC, Kerberos, Logon Tickets, X.509 Client Certificates, Java Add-In, Dual Stack, Diagtool, password
Reason and Prerequisites
This note should help you identify the cause of logon problems when a solution for SSO is implemented. There are a number of different technical solutions available for providing SSO, so this note contains several chapters, one each for the technical means used to implement SSO.
This note concentrates on problem analysis, but also mentions some of the most common specific issues. This note will not list all known issues that are related to SSO, as there are simply too many possible details involved. Unfortunately, even though the note concentrates only on the most common cases and how to analyze them, it is rather long.
Keep in mind that SSO solutions may appear quite complicated, especially if they span over a broad variety of system types that may exist in your system landscape.
Differentiate the possible implementations/solutions
The initial step to approach problems in SSO, of course, is to identify what SSO solution actually is being used. A first indicator is the client software: do you use a Web browser for accessing your servers, or do you use SAP's "classical" client program SAPGUI (sometimes called WinGUI)?
Attention: Newer client development and the related use of words make it easy to mix up certain versions of the Web browser-based clients with SAP's standalone client SAPGUI for ABAP servers. In the context of this note, the term SAPGUI will not be used for those Web-browser based clients.
Web browser-based clients can use either of the following mechanisms for implementing SSO:
- SAP logon tickets (covered in this note) or
- X.509 client certificates (covered in this note) or
- SAML Browser/Artifact Profile (AS Java since NW 2004, AS ABAP since NetWeaver 7.10) (NOT covered in this note)
The SAPGUI always requires Secure Network Communications (SNC) for SSO.
Typical Scenarios
The most common situation where SSO is used are system landscapes that are made accessible by an SAP Enterprise Portal.
Here, usually SAP logon tickets are used, because they are easily available and can be created and accepted by all SAP server products. In a typical portal landscape, the SAP Enterprise Portal issues the user a logon ticket after the initial logon, which is then used for further authentication purposes, both in the portal itself as well as in all SAP back-end systems that are being made accessible from the portal. Some third party services can also use the SAP logon ticket for authentication through the use of SAPSSOEXT (a Java-based toolkit for verifying SAP logon tickets).
A completely different situation exists when the client software for accessing ABAP-based SAP servers is SAPGUI. With SAPGUI, the only
way to implement SSO is to install SNC. SNC, in turn, can be implemented in a number of ways - but it always makes use of the GSS interface provided by SAPGUI and the ABAP-based SAP servers.
For more general information about SSO, see SAP Notes 138498 and 550742.
In the following, we refer to the servers involved as the AS ABAP and the AS Java for ABAP-based and Java-based system, respectively.
Solution
In the following, you will find hints on how to analyze problems with logon and Single Sign-On, ordered by the technical means for authentication that are being used.
1. SSO based on SAP Logon Tickets
SAP logon tickets are messages that confirm a successful (primary) logon. They are created on the SAP server and are passed to the user's client. From there, they are also passed to the intended target system(s) (in newer implementations also directly to the target system). SAP logon tickets provide a "simple", but proprietary solution for Single Sign-On.
The actual strategy for analyzing problems with SAP logon tickets is to follow the path of the SAP logon ticket from its creation, and then along the paths it takes in the network, until it is finally received and verified in the destination server.
The (now outdated) note 356691 is intended to help with this, but it refers to older releases, where the "standalone Internet Transaction Server (ITS)" was common for Web-based access. This note may still be useful though in some situations, especially when you try to access SAP systems of older releases.
To assert the authenticity of a user, SAP logon tickets make use of digital signatures based on the DSA algorithms. (These functions fall under the SAP component for Secure Store and Forward BC-SEC-SSF.) As a consequence, Secure Store and Forward (SSF) needs to be configured correctly to be able to verify the logon tickets. This includes the configuration for trusting the SAP logon ticket issuer (in terms of SSF), which is done by storing the logon ticket issuer's public key (certificate) in the target system's certificate store. (The target system is the system that verifies the incoming logon ticket.) Additionally, the logon ticket issuer needs to be entered into an access control list (ACL). The required steps differ between the involved system's base technology (ABAP or Java), but from the SSF point of view, they serve the same purpose.
In general, tracing SAP logon tickets will follow the same pattern, which is independent from the base technology:
- 1. Check whether the initial logon was successful.
- 2. Check whether a SAP logon ticket was issued after the initial logon.
- 3. Check whether the SAP logon ticket was passed to the client software (Web browser).
- 4. Check whether the same SAP logon ticket was forwarded to the target system for authentication.
- 5. Check whether the SAP logon ticket was processed for authentication purposes on the target system.
- 6. Check whether the SAP logon ticket was successfully verified on the target system.
As you see, after the SAP logon ticket is created, it is forwarded through several layers within the ticket-creating system and then passed to the user's Web browser (or to the receiving system directly). The Web browser then needs to decide whether to forward the ticket (a cookie named MYSAPSSO2) to the target server(s). There the logon ticket is received, and again forwarded through some internal layers of the server to finally be verified in the programs responsible for authentication. Each of these steps can fail, and in most cases, the result will be just another popup asking for the user's logon ID and password. Unfortunately, only rarely a significant error message can be displayed.
1.1. SAP logon ticket creation and verification on the AS ABAP
On the AS ABAP, the profile parameters login/create_sso2_ticket and login/accept_sso2_ticket control the creating and receiving of SAP logon tickets on the server. See the online documentation for details.
Since SAP logon tickets make use of SSF, also the correct setup of SSF on the AS ABAP is required. To check the version of the installed security toolkit for SSF (and whether a security toolkit is available at all), run the report SSF02, using the default selection "Determine version". For further configuration of SSF for SAP logon tickets, which includes maintaining the Personal Security Environments (PSEs) of the server and maintaining the ACL, use the transaction STRUSTSSO2. Keep in mind that the maintenance here depends on the configuration of your system. Therefore, you may be required to run STRUSTSSO2 in both the working client (the one you are logged on to) and client 000. If you configure your system as recommended by SAP, the PSE used for handling SAP logon tickets is the system PSE, and in this case, all PSE and ACL maintenance can be done in the actual logon client.
Note: If you need to replace a certificate for use with SAP logon tickets, make sure that you not only replace the certificate in the certificate list of the related PSE in the target system, but also that you replace the ACL entry, even if the new certificate uses the same subject name as the one to be replaced.
The transaction SSO2 originally was set up to configure SAP logon tickets on mySAP Workplace systems. Keeping this in mind, you will find that SSO2 can still provide helpful information in analyzing SSO with logon tickets, but unfortunately is no longer so helpful in modern landscapes where an AS Java creates the SAP logon tickets for users (such as the portal).
In current landscapes, there is a configuration wizard available with the SAP NetWeaver Administrator that replaces the old SSO2 transaction. For more information, see SAP Notes 1083421 and 1014077.
The most important procedure for analyzing problems when creating, accepting, or verifying SAP logon tickets on the AS ABAP is described in note 495911.
Codes and error messages that are reported in the logon trace according to note 495911 are explained in note 320991.
Also see note 1055856 for several common issues related to using SAP logon tickets.
The corrections from note 1159962 extend the AS ABAP's error messages with a message that refers to the specific issue that can occur when a Java-based system issues incomplete tickets (most probably due to configuration mistakes).
Inside the AS ABAP, the Internet Connectivity Framework (ICF) is responsible for cookie handling. The SAP logon ticket is no exception, so you also need to check the security settings for applications in transaction SICF. The settings in SICF can be maintained differently for each Web service being offered.
1.2. SAP logon ticket creation and verification on the AS Java
On the AS Java, the creation and receiving of SAP logon tickets is configured in the login module stack of the service being called. Usually, it is sufficient to run the SSO2 wizard in the SAP NetWeaver Administrator to enable the use of SAP logon tickets (note 1083421).
For storing the 'SAPLogonTicketKeypair', which is used to sign its SAP logon tickets, and for storing the public-key certificates of other ticket-issuing systems, the AS Java reserves a special view in the Key Storage service named 'TicketKeystore'. If you have to re-create the logon ticket key pair manually, make sure you create it in the 'TicketKeystore' view and give it the name 'SAPLogonTicketKeypair'. Also keep in mind that the key pair must use the DSA algorithm, and (for the time being) the validity of the certificate can not exceed January 1st, 2038. SAP Note 912229 describes how to replace the key pair and certificate on your AS Java.
Also see the online documentation for your product for specific instructions.
The most important checks for settings are summarized in note 701205. If checking these (static) settings does not help, use the diagnostic tool described in notes 1045019 and 957707 for further analysis.
Finally, see note 1159962, which refers to a common configuration issue in the AS Java's login module stack and related error messages on the (receiving) AS ABAP.
1.3. SAP logon tickets on a dual-stack system
For the analysis of logon issues with SAP logon tickets on a dual-stack system, basically the two previous chapters apply at the same time.
In addition, see the attachment to note 701205, named 'Add-InDoku.zip', which refers to settings that are specific for Add-In and dual-stack installations.
1.4. Tracing the SAP logon ticket on the client (Web browser)
On the client side, SAP logon tickets are stored as non-persistent cookies named MYSAPSSO2. This means the cookies are stored in the main memory of the Web browser process only. Of course, this main memory is volatile, which makes SAP logon tickets difficult to detect. In the most simple case, if you enter 'javascript:alert(document.cookie);' as an URL, the Web browser reveals the cookies that are currently known, but unfortunately this method of detecting cookies is not always helpful.
A lot more information can be obtained from an HTTP trace, like URLs being used; names, domains and content of COOKIEs; or Web page content.
We recommended using an HTTP proxy tool to trace the HTTP traffic
directly at the client. SAP uses HttpWatch (http://www.simtec.ltd.uk or http://www.httpwatch.com). There is a free version that you can use to provide a trace file ('*.hwl' file) that can also be
analyzed/read in SAP support. Please ZIP before uploading!
1.5. Considering COOKIE properties
Since SAP logon tickets are handed over to the client (Web browser) in the form of a cookie, all cookie properties apply. This means that they are assigned a name ('MYSAPSSO2'), and the Web browsers will most likely only forward them to URLs inside the same DNS domain as that where they were created. Also, only one cookie with a given name can exist for a single domain.
Keep in mind that SAP has no influence on the way cookies are handled inside Web browsers, as the Web browser's behaviour is defined by the respective vendor's programming.
For further information related to cookies and Internet standards, see note 654982.
1.6. Special cases
There is a very specific situation where so-called reentrance tickets (a version of SAP logon tickets) can be used to log on to an HTTP-based session from an already existing SAPGUI session on the same application server. The solution described in note 612670 works for this specific situation. The use of this ticket for authentication on other servers (other instances or other systems) is neither intended nor supported.
For integrating non-SAP components into an SSO landscape that uses SAP logon tickets, SAP provides an interface named SAPSSOEXT, which can be used to evaluate and verify SAP logon tickets and return the data contained. For more information, see note 304450 and its referenced notes. Note 1040335 contains information about how to trace the activities of SAPSSOEXT.
2. SSO based on X.509 client certificates
Based on Internet standards, X.509 client certificates offer a nonproprietary solution to implement SSO. The use of X.509 client certificates for authentication requires the target system to offer HTTPS/SSL (see notes 510007, 739043 or 1019634, resp.).
In all cases, authentication using client certificates has two
prerequisites: the client certificate needs to be mapped to a user ID (logon name) that already exists in the system, and the client certificate needs to be accepted in terms of trust.
Note that trust can only be configured for certificates that are issued by a Certification Authority (CA). You cannot exchange individual X.509 client certificates to establish trust in this case.
2.1. X.509 Client Certificates on the AS ABAP
The AS ABAP uses the PSE maintenance in transaction STRUST for establishing trust. The certificate(s) of the CA that has issued the client certificates need to be present in the certificate list of the SSL server PSE that is being used to handle incoming HTTPS/SSL requests.
The mapping of the client certificate to the internal user ID is provided in the table USREXTID (maintenance view VUSREXTID). It takes the external identity type (here 'DN'), the subject name from the client certificate, and the internal user ID (that is, USR02-BNAME) as field values. Note that some encodings of the DN are interpreted differently in the kernel than in the ABAP layer. We recommend using plain ASCII for Distinguished Names (DN).
The setting of the profile parameter icm/HTTPS/verify_client determines whether the AS ABAP generally accepts or requires X.509 client certificates. As with accepting SAP logon tickets, the actual ICF service's security settings (transaction SICF) may influence the system's behavior.
For problem analysis when using X.509 client certificate authentication, see the developer traces provided with the procedure described in note 495911. In addition, the ICM traces can be helpful. For displaying the certificates that are exchanged between the client and server during SSL negotiation, set the trace level to 3. For all other SSL related messages, trace level=1 should be sufficient. (High trace levels reduce readability!).
2.1.1. SAP Passport
SAP offers the SAP Passport as a comfortable solution to provide X.509 client certificates to users of SAP systems. For more information, see the SAP Support Portal at http://service.sap.com/TCS and follow the links "SAP Trust Center Services in Detail ==> SAP Passports in your SAP solution" and/or "==> Single Sign-On with SAP Passports".
In addition to the items already mentioned, when doing problem analysis, you need to keep an eye on the validity of the system's Registration Authority (RA) certificate. (This certificate is the server's own certificate and it is in the system PSE of your AS ABAP. It is signed by the SAP DSA CA).
2.1.2. The general case
In the case that you are not using SAP Passports, you need to provide the required system settings mentioned manually. In particular, the user mapping in VUSREXTID can be tricky if your client certificates contain non-ASCII characters. In this case, to get the correct representation of the subject name (owner name) from the client certificate, open the certificate in STRUST (menu "Certificate --> Import") and copy the content of the field "Owner".
2.2. X.509 client certificates on the AS Java
The AS Java uses the Keystore service for maintaining encryption keys, certificates, and therefore, to establish trust. The certificate(s) of the CA that has issued the client certificates need to be present in the Keystore view named 'TrustedCAs'.
On the AS Java, the SSL service is where you configure whether a client certificate is accepted or required for authentication. For the published services, the configured login module stacks define the authentication options. If you want to accept X.509 client certificates for authentication, the 'ClientCertLoginModule' needs to be configured accordingly.
It is also the ClientCertLoginModule that defines the rule(s) to use to map the client certificate to the user'd ID on the AS Java. Certificates can be stored directly with the user account (and thus are explicitly mapped), or the rule extracts the actual user name from the SubjectName or SubjectAlternativeName attributes contained in the X.509 client certificate.
In case of issues, check the "Troubleshooting" topics in the online documentation for the User Management Engine (UME).
3. SSO based on SNC
With one exception (*), SSO can be considered a by-product when implementing message encryption with SNC on the AS ABAP. Encrypting the data traffic of DIAG (SAPGUI<-->server) and RFC (server<--->server) protocols requires that each partner possesses keys to use for encryption, and these keys are also used for mutual authentication. Therefore, when using SNC for encryption, everything is in place for providing SSO.
(*) The one exception is when implementing SSO by using the NTLM from the Microsoft Windows System Security Provider Interface. NTLM can only provide client-side authentication (which suffices for user-side SSO), but no encryption.
Note 66687 gives a summary about SNC in general. More detailed generic information is contained in the online documentation.
When analyzing SNC issues, you should always look into the traces that are written by the involved executables, that is, the SAPGUI trace if the SNC issue is on the client side, and the developer traces 'dev_w##' if the server side is concerned (display using transaction ST11).
Error messages related to SNC use the terms 'SNC' and/or 'GSS', so it is a good idea to search the server's work directory for occurrences of these terms using tools like 'grep' (UNIX) or 'find' (Windows).
3.1. Third-party security products
SNC uses 'Generic Security Service' (GSS). These GSS functions that are available for use with SNC are implemented in an "external security product", and not in the SAP kernel itself. This means that the functions themselves must be made available through dynamically loaded libraries (DLLs, shared libraries or shared objects) from a separate product.
SAP does provide libraries that are licensed for use with server-to-server communications, however, not for use on the client side. So, SNC for SSO will always require in a third-party product. For issues with the SNC implementation of your chosen product, refer to the support organization of your respective vendor.
3.2. SNC for Windows
To make the security products that are available with the Microsoft Windows operating system (SSPI = System Security Provider Interface) available for the GSS interface used by SAP programs, SAP does provide "wrapper libraries" for either NTLM or Kerberos on Windows 32bit or 64bit platforms.
See note 352295 for the libraries themselves as well as a description of the known issues with this SNC implementation.
3.3. Unsupported solutions
While the wrapper libraries attached to note 352295 make the Kerberos implementation coming with Microsoft Windows available, these are only available for pure Microsoft Windows landscapes. Other implementations of Kerberos may be interoperable, but SAP neither tests for interoperability, nor is SAP able to provide support for those Kerberos
implementations.
See note 150380 for a more detailed discussion.
4. Related issues
Finally, here are some additional issues that are more or less related to SSO.
4.1. Password-based logon
Password-based logon can behave like SSO if the password is being stored on the client side (example: destinations in transaction SM59).
Note 622464 discusses the relation between user types and password expiration. For user types in general, see note 327917.
In Releases beginning with 7.00, the AS ABAP offers new password rules (distinguishing upper and lower case, and an extended password length). In system landscapes where older and newer systems exist side by side, there may be issues when components that provide the "old" policies need to access newer systems. Note 1023437 discusses the use of downward-compatible passwords.
Often, SSO is mistaken for solutions that provide identical passwords throughout a large number of systems. From our experience, such attemps for password synchronization can not work completely successfully and also reduce the level of individual password security. Hence, password synchronization is not supported, as note 376856 describes.
4.2. SPNego
This is a special initial login on AS Java that does not require a user to enter a password to access the server. It is based on the user's login to the Microsoft Windows domain. It makes use of the Windows APIs called 'SPNego'.
The central note for issues related to SPNego (note 968191) unfortunately may contain some obsolete references and may also miss some of the newest related notes. However, it still offers a valid entry point for problem analysis and an overview of the concepts use. In addition, see the online documentation.
In new releases of the AS ABAP, SPNego is also supported with SAP NetWeaver Single Sign-On release 2.0 (or newer). Downports exist also for older (supported) releases, please see note 1798979.
4.3. SAP Shortcuts
SAP Shortcuts can store the user's password and therefore simulate SSO. Nevertheless, because the 'normal' password authentication is being used, it is not regarded as a "true" SSO implementation.
4.4. Other (third-party) products
Other third-party products for SSO (for example CA's SiteMinder) may be functional, but since SAP's support does not have any experience or information available, therefore, contact the respective vendor's support channels if you have any questions or issues.
4.5. Additional tips/common problems
Several common error messages and issues that occur when setting up Single Sign-On are addressed in note 1055856.
When using some implementations of SSO, it may be cumbersome to continue to keep your passwords valid. On the AS ABAP, you can set the profile parameter login/password_change_for_SSO to set whether passwords that have become invalid need to be updated. Note 869218 contains some corrections that need to be in place to make the API available for checking this profile parameter. Keep in mind that some front-end and middleware components may still require a related correction to make the concept finally work.
A list of all error codes that may be recorded in the developer trace during processing logon attempts is provided in note 320991.
No comments:
Post a Comment