Conguring As Java To Accept Logon Tickets

12/8/2023
AS Java
Generated on: 2023-12-08 16:53:44 GMT+0000
Support Content | 1.0
PUBLIC
Original content: https://help.sap.com/docs/SUPPORT_CONTENT/asjava?locale=en-US&state=PRODUCTION&version=1.0
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the https://help.sap.com/docs/disclaimer.
This is custom documentation. For more information, please visit the SAP Help Portal 1
12/8/2023
Single Sign-On with SAP Logon Tickets

Introduction to the SAP Logon Ticket and the MYSAPSSO2 cookie
AS Java as a ticket issuing system
AS Java as a ticket accepting system
Troubleshooting SSO between AS-ABAP and AS-JAVA
Using the SSO2 wizard to set up SSO between java systems
AS Java as a ticket accepting system
Con guring the AS Java to accept SAP Logon Tickets
Ticket accepting - UME properties
Con guring AS Java to accept logon tickets
Purpose
Outline the steps required to con gure the AS Java to accept logon tickets from a ticket issuing system.
Overview
There are two main aspects to the con guration required for the Java AS to accept logon tickets from other systems:
Import public key certi cate of issuing system

The ticket issuing server’s public key certi cate must be imported into the TicketKeystore view of the AS Java’s key storage
service in order to verify the digital signature of the received logon tickets.
Con gure EvaluateTicketLoginmodule/EvaluateAssertionTicketLoginmodule ACL options

Any applications where the received logon tickets are to be used for authentication must use an appropriately con gured login
module stack containing the EvaluateTicketLoginmodule/EvaluateAssertionTicketLoginmodule and the login module's Access
Control List must be con gured accordingly for each ticket issuing system:
The following EvaluateTicketLoginmodule/ EvaluateAssertionTicketLoginmodule options form the Access Control List:
trustedsys<n> = <System ID of the ticket issuing system>,<client of the ticket issuing system>
trustediss<n> = <Distinguished Name of Issuer (issuerDN) in public key certi cate>
trusteddn<n> = <Distinguished Name(DN) in public key certi cate>
SSO2 Wizard
The above two con guration steps are carried out using the SSO2 Wizard which is accessed at http://<host>:<port>/sso2.
When a public key certi cate of a ticket issuing system is imported into the AS Java using the SSO2 wizard, the wizard places
the certi cate in the TicketKeystore view in the AS Java’s key storage service and con gures the Access Control List options
speci c to that ticket issuing system in the EvaluateTicketLoginModule and EvaluateAssertionTicketLoginModule in the AS Java
user store. All existing policy con gurations that already include either of these login modules in their login module stack inherit
the ACL options introduced by the SSO2 wizard allowing authentication to take place using logon tickets issued by that ticket
issuing system.
There are two ways to import the public key certi cate of the ticket issuing system ʻby uploading certi cate manually’ and ʻBy
Querying trusted system’.
12/8/2023
Manually uploading the certi cate requires the manual export of the public key certi cate from the key storage of the
respective ticket issuing system, transaction STRUSTSSO2 if it is an ABAP AS and if it is an AS Java from the key storage
service. Then by selecting Add Trusted System -> by uploading certi cate manually in the SSO2 wizard UI you can browse to the
location of the public key certi cate exported from the ticket issuing system and import it into the AS Java.
Importing the certi cate by ʻQuerying trusted system’ can be done in two ways, by choosing the ticket issuing system from the
SLD or by manually entering the connection details of the ticket issuing system. In both cases the SSO2 wizard connects to the
ticket issuing system, retrieves the public key certi cate and imports it into the AS Java.
As mentioned above, the SSO2 wizard automatically con gures the EvaluateTicketLoginModule and
EvaluateAssertionTicketLoginModule in the AS Java user store with the required ACL options. If there is an example deployed
on the AS Java that does not make use of a policy con guration that currently includes either of these login modules, when they
are added to the policy con guration they will inherit the ACL options. If it is not intended that logon tickets from a speci c
trusted ticket issuing system are used for authentication when accessing an application, you must manually remove the ACL
options speci c to that ticket issuing system from the EvaluateTicketLoginModule/EvaluateAssertionTicketLoginModule in the
applications policy con guration. The management of policy con gurations and login modules is done in con guration
Management Security Authentication and Single Sign-On Authentication
Example screenshots
Con guring trust by Querying ticket issuing system or by manually uploading the public key certi cate of the ticket issuing
system
No system available in SLD, so by choosing from either ABAP or Java system type the system connection details can be
entered
12/8/2023
Entering the connection details for a Java system
Details of the java ticket issuing systems public key certi cate that will be imported
Public key certi cate of the java ticket issuing system imported into the ticket accepting java system via the SSO2 wizard
12/8/2023
The wizard updates the EvaluteTicketLoginModule and EvaluteTicketAssertionModule in the user store and any policy
con gurations containing these login modules show the resulting ACL entries
Querying trusted system: Entering the connection details for a ABAP system
12/8/2023
Details of the ABAP system's public key certi cate that will be imported
ABAP systems public key certi cate imported
12/8/2023
Again the policy con gurations show the changes made by the SSO2 wizard
The TicketKeystore view showing the two public key certi cates imported by the SSO2 wizard
Related Content
Related Documents
Con guring the AS Java to Accept Logon Tickets
Related SAP Notes/KBAs
1083421 SSO2 Wizard
Ticket accepting - UME properties
Purpose
12/8/2023
List and describe the purpose of the UME properties most relevant to the process of veri cation of logon tickets received by the
AS Java
Overview
The UME properties listed here are the most important for ticket validation. They determine which logon ID is retrieved from
the received ticket and the behaviour of the AS Java when the password of the user in the ticket is expired
login.ticket_portalid
As explained in Ticket issuing - UME properties the value of this property in uences which logon ID the AS Java writes in the
logon ticket when it is creating the ticket. It is very important to be aware that this property also in uences the reading of the
logon ID from any recieved logon tickets. Therefore changing the property value to achieve a certain behaviour at logon ticket
creation time may have unexpected results at ticket evaluation time i.e. when the AS Java receives a logon ticket issued by
itself or another system.
Possible values:
yes => The AS Java reads the portal ID from the received logon ticket.
no => The AS Java reads the ABAP user ID from the received logon ticket.
auto => If the ticket receiving AS Java has usage type Enterprise Portal, the AS Java reads the portal ID from the received logon
ticket.
ume.logon.force_password_change_on_sso
When the AS Java receives a logon tickey, evaluates it and retrieves the logon ID from the ticket, the password state of that
user is checked. Depending on the value of this property the user may be requested to change their password if it is in an initial
or expired state
Possible values:
true => the system always forces users to change their passwords (when the passwords expire or are reset).
false => the system only forces password changes during password authentication. When using other authentication methods
the system never forces a password change
Related Content
Related Documents
Ticket issuing - UME properties
Note 843061 NW'04: SSO2 ticket generation and ticket evaluation in Java
AS Java as a ticket issuing system

SAP Logon Ticket creation in AS Java
Description of the UME properties that in uence how the AS Java creates logon tickets
Con gure AS ABAP to accept logon tickets issued by AS Java
Con gure AS ABAP to accept logon tickets issued by AS Java
Purpose
Provide an illustrative guide to the steps required to con gure an AS ABAP to accept logon tickets issued by an AS Java
12/8/2023
Overview
There are two aspects to the con gured required
1. Pro le parameter login/accept_sso2_ticket must be set with value 1
2. The public key certi cate of the AS Java must be imported into the ABAP system using transaction STRUSTSSO2 and
added to the cert cate and access control lists
Set login/accept_sso2_ticket = 1
Refer to Pro le Parameters for Logon and Password (Login Parameters) for more information
Import the public key certi cate of the AS Java into the ABAP system
Export the public key certi cate from the AS Java.
The public key certi cate can exported from the TicketKeystore view in the Keystore Administration of the SAP NetWeaver
Administrator (NWA). Export SAPLogonTicketKeypair-cert as illustrated in the following images
12/8/2023
Select SAPLogonTicketKeypair-cert and then Export-Entry
Export the entry to le in the format of your choosing and ensure that you remember to choose the same format when
importing into the ABAP AS
Import the certi cate into the AS ABAP using transaction STRUSTSSO2
Note: the following steps must be performed in the ABAP client that will receive the logon tickets i.e the ABAP client that the
component/application on the Java AS is con gured to connect to e.g the client speci ed in the portal iview properties or the
client speci ed in a Web Dynpro JCo Destination
12/8/2023
In STRUSTSSO2 the PSE that is used for logon tickets is the default System PSE
System PSE
12/8/2023
Choose the import button to display the Import Certi cate dialog. Choose the le format to be the same as the format in
which the certi cate was exported from the AS Java.
Add the certi cate to the certi cate list
After importing the certi cate, its details are displayed.
12/8/2023
Details of imported certi cate are displayed
Next the certi cate must be added to the certi cate list.
12/8/2023
Choosing button Add to Certi cate List causes the certiifate to be displayed in the certi cate list
Add the certi cate to the Access Control List
Note: When adding the certi cate to the ACL the SID should be set to the SID of the ticket issuing Java AS and the client should
be set to the client that the Java AS is writing to the logon tickets i.e the value of login.ticket_client in the Java AS
In an Add-In installation, where the system IDs are the same, you must change the default client for the J2EE Engine (000) to a
client that does not exist on the SAP Web AS ABAP system. The reason for this change is that the system ID and client
combination must be unique when tickets are to be accepted by an SAP Web AS ABAP system
12/8/2023
Add Entry to Single Sign-On Access Control List
12/8/2023
Enter the system ID of the ticket issuing AS Java and the client that it is writing in the logon tickets that it issues
12/8/2023
Certi cate added to Access Control List
Use transaction SSO2 to check the con guration
Call transaction SSO2 and specify 'NONE' as RFC Destination
12/8/2023
Details of imported certi cate and the value of login/accept_sso2_ticket are displayed
Related Content
Related Documents
Specifying the Client to Use for Logon Tickets
Logon Ticket creation in AS Java
Purpose
Outline some important aspects of the AS Java in a ticket issuing role, including how it creates Logon Tickets and important
UME parameters for ticket issuing.
Overview
A system may be con gured to issue SAP Logon Tickets while at the same time not accepting Logon Tickets from any other
system. Conversely, a system may be con gured to accept logon tickets issued by other systems, but not to issue Logon Tickets
itself. As a result SSO with SAP Logon Tickets is unidirectional. Therefore, although a particular system may be con gured to
both issue and accept logon tickets, each process is distinct and can be considered separately. In this document the AS Java’s
role as a ticket issuing system is outlined.
Authentication and Logon Ticket Creation
Authentication on the Netweaver AS Java is performed using prede ned authentication classes, referred to as login modules. A
login module contains an implementation Java class that de nes the authentication. On the AS Java you can use or de ne
groups of login modules that contain different authentication logic. Such groups are referred to as login module stacks. Each
login module stack enables you to choose different combinations of authentication for applications
During the user authentication process, the server processes the stack of login modules that apply to the application that the
user accesses. If the user is to receive a logon ticket after authentication, then the login module stack for such applications
12/8/2023
must include the login module for creating tickets, CreateTicketLoginModule.
Conceptual diagram showing how the authentication process proceeds down the login module stack dependent on the ag of
each login module.
For applications such as Enterprise Portal and Web Dynpro applications deployed Netweaver AS Java versions before 7.1, in
order for end-users to get access to the applications a logon ticket must be created for the user at authentication time. This is
due to the implementation of the authentication process for such applications where after authenticating via some means such
as userid and password and the creation of the logon ticket, there is a subsequent evaluation of the newly created logon ticket.
If for some reason the logon ticket was not created, the evaluation will fail and the user will simply be presented with the logon
page again. In versions after 7.1 the authentication process has changed and there is no additional check for the presence of a
logon ticket and so the creation of a ticket at authentication time is not mandatory in order to access the application but if one
is not created with certain applications such as Enterprise Portal it could cause issues afterwards.
Authschemes
A Logon ticket issued by the AS Java contains an ʻauthscheme’ value indicating the Authentication Scheme that was used in
authenticating the user on the ticket issuing application server. An Authentication Scheme includes the login module stack used
in the authentication, the user interfaces used to gather the information required to authenticate the user, and an authscheme
priority. It de nes what type of authentication is required for a speci c application. For example, Portal iViews and Web Dynpro
applications always use authentication schemes, other J2EE Web Apps use them only if the use UME authentication and
authschemes are not relevant for ABAP systems.
If a user tries to access an application using her Logon Ticket for authentication, on the same AS Java that issued the ticket or
on another AS Java that is con gured to accept Logon Tickets from it and the application requires a stronger authscheme than
speci ed in the ticket, authentication using the logon ticket will fail and the user must re-authenticate by some other means
such as logon ID and password for example. A new logon ticket will then be issued with the new stronger authentication scheme
speci ed in it.
Authentication stack: [ticket].

[EXCEPTION]
com.sap.security.core.server.jaas.DetailedLoginException: authscheme not sufficient: kerberos<basi
at com.sap.security.core.server.jaas.EvaluateTicketLoginModule.verifyAuthschemesOk(EvaluateTicketLo
at com.sap.security.core.server.jaas.EvaluateTicketLoginModule.login(EvaluateTicketLoginModule.java
Copy this code!
Sample warning in traces where a ticket was evaluated and it was found that its custom authcheme 'kerberos' had a lesser
prioirty than 'basicauthentication' and authentication failed as a result
12/8/2023
All Web Dynpro applications are automatically assigned to the ʻdefault’ authentication scheme, which in turn references the
ticket login module stack. In the portal, each shipped iView template is assigned a reference to an authentication scheme and
initially all references to authentication schemes point to the same authentication scheme (uidpwdlogon).
It is possible to de ne custom authentication schemes and then change the con guration of the portal so that the references
point to these custom authentication schemes.
Excerpt from a authscheme xml le showing the how the 'default' authscheme references the 'ticket' authentication stack
SAPLogonTicketKeypair
As with all systems that issue SAP Logon Tickets, the Netweaver AS Java uses a key pair to digitally sign logon tickets that it
issues. The names of the private key and public key certi cate used for this purpose are SAPLogonTicketKeypair and
SAPLogonTicketKeypair-cert respectively. This key pair is stored in the TicketKeystore view in the AS Java’s Key Storage
service. They pair has a valid from and valid to date and must always use the Digital Signature Algorithm (DSA). The key pair is
created automatically at installation time, but can be recreated at any time by manually deleting the existing key pair and
creating a new key pair, or by simply deleting the TicketKeystore view and restarting the system to allow a new view and key
pair to be created automatically during system startup. Recreating the key pair is required when the valid to date approaches,
otherwise when the key pair is no longer valid SSO to other systems will stop working. Each time the key pair is recreated the
newly created public key certi cate most be imported into any system con gured to accept logon tickets from the ticket issuer.
12/8/2023
Screenshot of the location of the key pair used for the signing of SAP login tickets issued by the AS Java in the Netweaver
Administrator of AS 7.30
Related Content
Related Documents
De ning an Authentication Scheme

Policy Con gurations and Authentication Stacks
Con guring the AS Java to Issue Logon Tickets
KBA 1659382 - After entering correct user ID and password the logon page is displayed without an error message
Ticket issuing - UME properties
Purpose
List and describe the purpose of the UME properties most relevant to SAP logon ticket creation on the AS Java
Overview
The UME properties listed here are the most important for ticket creation. They control what is written to the ticket, the validity
of the ticket and in uence how the browser handles the MYSAPSSO2 cokie containing the logon ticket
Important parameters for logon ticket creation
12/8/2023
login.ticket_client
Its value determines the client number that is written to the logon ticket issued by the Java Application Server.
Default value 000.
Only change this value when con guring SSO between the Java and ABAP stacks of a dual stack WebAS, in any other case the
default value will suffice.
The reason for this change is that the system ID and client combination must be unique in order for tickets are to be accepted
by an SAP Web AS ABAP system. In a dual stack system the system IDs of the AS ABAP and AS Java are the same so you must
change the default client for the J2EE Engine (000) to a client that does not exist on the SAP Web AS ABAP system.
login.ticket_portalid
In a logon ticket issued by an AS Java two users can be written: the R/3 user and the Portal user
As long as the ID used to logon to the Java AS is no longer than 13 characters and user mapping is not con gured, the rst user
called ʻR/3 User’ will have this logon ID as its value. If the logon ID is longer than 13 characters and user mapping is not
con gured, then R/3 User will be blank. If user mapping is con gured, instead of the logon ID being written as the ʻR/3 User’ in
the ticket, a certain pre-con gured mapped ID is written instead.
ABAP systems always read the ʻR/3 user’ from the ticket when evaluating a received ticket
The value of login.ticket_portalid determines whether or not the second user ʻPortal User’ is written in the ticket.
YES = The ʻPortal User’ is always written into the logon ticket.
NO = The ʻPortal User’ is never written into the logon ticket.
AUTO = If a portal installation is detected, the ʻPortal User’ is written into the logon ticket.
ʻPortal User’ has the form ʻportal:<logon id>’
ume.logon.security.relax_domain.level
The URL used to request an application deployed on the ticket issuing Java AS should contain the fully quali ed domain name of
the server if it is intended that the logon ticket is used for SSO to other systems.
By default once authentication succeeds the MYSAPSSO2 cookie will be set with a domain attribute equal to the domain
speci ed in the URL.
The browser uses this domain attribute to decide to which servers the cookie should be sent, i.e. it will usually send the
MYSAPSSO2 cookie with all requests to any server in the domain that matches its domain attribute
The UME allows you to specify the number of sub-domains that the Java AS should remove from the domain in the URL when
setting the domain attribute of the MYSAPSSO2 cookie
This allows some control over where the browser will send the cookie.
For example, if the value is 1 and the logon ticket is issued by the Java Application Server myserver.mycountry.mycompany.com,
the logon ticket is valid for all servers in the domain mycountry.mycompany.com. A value of 2 and the logon ticket is valid for all
servers in the domain mycompany.com
login.ticket_lifetime
Number of hours that the logon ticket is valid
12/8/2023
Default value is 8.
Typically should be set to a value just greater than the users average working day
ume.logon.security.enforce_secure_cookie
Marks the logon ticket as a secure cookie, to enforce that the client browser sends the cookie only when the connection from
the browser to the AS Java or reverse proxy/load balancer in front of the AS Java is SSL encrypted
If set to true and there is no SSL connection to the AS, the client will not send the cookie with request to it and authentication
will fail
ume.logon.httponlycookie
If TRUE, the MYSAPSSO2 cookie has attribute HttpOnly. This prevents it from being read by malicious client-side script code
such as JavaScript
login.authschemes.de nition. le
Speci es the name of the le that contains a list of the available authentication schemes. If there are custom authschemes in
use the le containing their de nition is speci ed as a value for this parameter
Related Content
Related Documents
Logon Ticket creation in AS Java

Logon Ticket UME parameters
SAP Logon Ticket
General SAP Logon Ticket topics
An introduction to the SAP Logon Ticket

Assertion tickets and how they compare to Logon Tickets
The MYSAPSSO2 cookie - Introduction and creation details
MYSAPSSO2 - browser and proxy handling
The MYSAPSSO2 cookie - cookie deletion details
Assertion Tickets
Purpose
Introduction to SAP Authentication Assertion Tickets
Overview
Description of SAP Authentication Assertion Tickets, their uses and a comparison to SAP Logon Tickets
SAP Authentication Assertion Tickets

An Authentication Assertion Ticket is an authentication token similar to a SAP Logon Ticket and is implemented using the same
technology. Assertion tickets have a very similar structure to logon tickets and contain much the same information as logon
12/8/2023
tickets such as the logon ID, Issuing system ID, validity period etc., but there are differences in how assertion tickets are
transmitted and their intended purpose
Comparison with Logon Tickets

Unlike logon tickets which are used for end-user authentication and single Sign-On (SSO), assertion tickets are typically
used for system to system authentication. In such cases no user interaction is necessary
Logon tickets which are typically transmitted in a non-persistent cookie whereas assertion tickets are typically
transmitted as an http header
Logon tickets are not created with a recipient in mind, once created they can be used to authenticate on any number of
appropriately con gured systems. In contrast, assertion tickets are created for authentication on a single speci c
system.
Assertion tickets contain an additional eld for the recipient system ID, whereas logon tickets contain just the issuing
system ID. For an AS ABAP to accept a particular assertion ticket, the recipient ID in the ticket must match the AS ABAP
system ID.
Assertion tickets have a lifetime of just 2 minutes, which is not con gurable. Logon tickets have a lifetime that is
con gurable, with default of 8 hours
Assertion tickets are limited to one-time use. Once the ticket has been veri ed, it is deleted.
The AS Java has speci c login modules for evaluating and creating assertion tickets,
EvaluateAssertionTicketLoginmodule and CreateAssertionTicketLoginModule respectively, whereas the equivalent login
modules for logon tickets are EvaluateTicketLoginmodule and CreateTicketLoginModule
Two sample requests from clients where in the rst request an assertion ticket is transmitted as a http header with name
'mysapsso2' and in the second a logon ticket is transmitted in the MYSAPSSO2 cookie
Related Content
Related Documents
Using Logon Tickets
Difference between SAP Authentication Assertion Tickets and SAP Logon Tickets
MYSAPSSO2 - browser and proxy handling
Purpose
12/8/2023
Outine how the browser decides with which requests to send the MYSAPSSO2 cookie and some important aspects of browser
cookie handling behaviour
Overview
As described in The MYSAPSSO2 cookie - Introduction and creation details when a user logs on to a Logon Ticket issuing
system, the system creates a Logon Ticket for the user and sends it to the browser in the MYSAPSSO2 cookie. This
MYSAPSSO2 cookie has a domain attribute value that the browser uses to decide with which requests to send the MYSAPSSO2
cookie and this ultimately decides to which systems SSO can take place. This document describes some important accepts of
how the browser handles the MYSAPSSO2 cookie
MYSAPSSO2 cookie handling by browsers

For the sake of simplicity, coverage of the nuances of how browsers interpret the domain attribute value in the set-cookie
command is omitted here, and for the purposes of this document it is sufficient to assume that when the set-cookie command
contains a domain attribute, the browser treats this as the cookie’s effective domain and will send the cookie with all requests
that are a domain match. Here we can take this to mean that the browser will send the cookie with all requests to servers in the
same domain or a sub-domain of the domain speci ed as the cookie’s domain attribute value. For a more information refer to
RFC 2965
Domain matching
As stated in The MYSAPSSO2 cookie - Introduction and creation details, the browser uses the value of the cookie’s domain
attribute to determine with which requests it should send cookie and therefore which systems should receive the logon ticket.
Only if the browser considers the cookie’s domain to be a ʻdomain match’ to the domain in the request URL will it send the
cookie with the request. An important aspect of cookie handling to consider is that a browser will not send a cookie with
requests to domains that are parent domains of the domain speci ed as the value of the cookies domain attribute. For example
a cookie with domain attribute value .support.mycompany.com would not be sent with a request to server
myserver.mycompany.com but it would be sent with a request to myserver.support.mycompany.com and to a server in a sub-
domain such as myserver.servers.support.mycompany.com. In essence, the cookie's entire domain attribute value must be
contained in the request URL in order for the browser to send the cookie with the request.
Path attribute
Since the path attribute of the MYSAPSSO2 cookie always has value ʻ/’ it is sent with requests for all resources on a particular
server, once the domain in the URL is considered to be a domain match for the cookie. As a result one does not have to consider
the path attribute when planning a SSO scenario using logon tickets, and can focus on the FQDN of the machines in the
scenario and the domain attribute of the MYSAPSSO2 cookie, since these determine where the browser will send the cookie
and ultimately if SSO using SAP Logon Tickets over http can take place.
Multiple MYSAPSSO2 cookies
Another important consideration is that it is possible for a browser to have multiple MYSAPSSO2 cookies in its memory, each
with different domain attribute values, since according to the standards multiple cookies with the same name but different
"domain" and/or "path" attribute values can co-exist.Furthermore it can occur than more than one of these MYSAPSSO2
cookies could be considered by the browser to be a domain match for a particular request and as a result more than one
MYSAPSSO2 cookie can be sent with the request. This can happen in a multi-system scenario where the end user authenticates
on multiple systems with logon ID and password receiving a logon ticket from each system.
For example if the browser has in memory two MYSAPSSO2 cookies, one with domain .support.mycompany.com and the other
with domain .mycompany.com both MYSAPSSO2 cookies will be sent with a request to server
myserver.support.mycompany.com.
Since there is no ordering de ned for such cookies it is not possible to determine in which order the browser will send the
cookies and therefore this can have indeterminate consequences on the ticket accepting system. This is obviously a serious
12/8/2023
issue when the cookies involved are authentication tokens, and so such situations should be avoided by careful planning of the
SSO landscape.
Secure attribute
It is possible to con gure the ticket issuing system so that the MYSAPSSO2 cookie is set with a secure attribute. For example,
on the Netweaver AS Java this is achieved via the UME parameter ume.logon.security.enforce_secure_cookie. When a cookie
has the secure attribute, the browser will only send it with https requests. If you access the ticket issuing system via plain http,
after successful authentication the browser will not send the MYSAPSSO2 cookie with any requests, including those back to the
ticket issuing system itself and results could include being presented with a logon screen again immediately after entering a
valid logon ID and password combination. In short, if the ticket issuing system has been con gured to set the MYSAPSSO2
cookie’s secure attribute, users must always access the system over https to avoid any problems that could occur due to the
absence of a valid logon ticket.
MYSAPSSO2 cookie handling by proxies
It is not uncommon for a proxy to modify the cookie's domain and path attribute values leading to various authentication issues
such as a causing SSO to fail. For exmaple, the proxy may alter the domain attribute value to be equal to the FQDN in the
request, leading to the browser sending the cookie only with requests to the ticket issuing system or by altering the path value
leading to the cookie only being sent to a speci c application instead of all applications on a particular system. Other erroneous
behaviour includes completely ltering out the cookie from the request or response or caching the cookie some way and later
assocating the cached cookie with an incorrect request causing a security issue. Such behaviour by proxies should be avoided
and analysis of such issues requires analysis of the requests and responses from the client and server sides
Related Content
Related Documents
The MYSAPSSO2 cookie - Introduction and creation details
The MYSAPSSO2 cookie - cookie deletion details
Netscape cookie preliminary speci cation
RFC 2965
RFC 2109
SAP note 654982 URL requirements due to Internet standards
MYSAPSSO2 - deletion
Purpose
Outline how the MYSAPSSO2 cookie is deleted during logoff and some issues to watch out for
Overview
As part of the logoff process the system creates a new MYSAPSSO2 cookie with an empty value that overwrites the cookie that
exists in the browser memory. This document describes this process and some issues that may occur
Logout
12/8/2023
When an end-user logs out from a system that is con gured to issue logon tickets, as part of the log out procedure, the system
creates a MYSAPSSO2 cookie with an empty value and a domain attribute that matches the domain in the URL used to access
the system (or some portion of it depending on the value of ume parameter ume.logon.security.relax_domain.level). This is how
the system removes the logon ticket from the browser.
set-cookie: MYSAPSSO2=; path=/;domain=.mycompany.com
Copy this code!
When the server’s response reaches the browser, this new cookie with an empty value overwrites the existing MYSAPSSO2
cookie in memory that has the same domain attribute value, if one exists. This occurs irrespective of whether the overwritten
cookie was originally created by the system that the user logged out from or some other system, and is due to the standard
stating that cookies with the same name and domain attribute cannot co-exist. As a result authentication, including SSO using
the overwritten logon ticket can no longer take place.
Example of a POST request resulting from 'log off' in Enterprise Portal being clicked and the server's response where a
MYSAPSSO2 cookie with empty value and expiration details is included
It can occur that there is no existing MYSAPSSO2 cookie with the same domain attribute existing in the browser and therefore
no cookie is overwritten. Consider the case where the user initially logged onto ticket issuing system server.mycompany.com
and was issued a logon ticket with domain attribute value .mycompany.com. If they use this logon ticket to authenticate on
server server.support.mycompany.com and later log out from server.support.mycompany.com, as part of the log out
procedure, this server creates a MYSAPSSO2 cookie with an empty value and domain attribute .support.mycompany.com.
When the browser receives this cookie in the server’s response, it does not overwrite any existing MYSAPSSO2 cookie since
there is no existing cookie with domain .support.mycompany.com. Since the MYSAPSSO2 cookie with domain attribute value
.mycompany.com still exists, it can still be used for SSO to systems in that domain and its sub-domains including the system
from which the user logged out. One observable symptom of this may that it appears that log off from the ticket accepting
system appears to fail, when really what is happening is that the user is being re-authenticated immediately after log out, using
the logon ticket that issued earlier by the ticket issuing system
In newer versions of the AS Java, during the log off process in addition to creating the MYSAPSSO2 cookie with an empty string
as the value, the system also makes the cookie expire by specifying a value for the cookies ʻexpires’ attribute to a time in the
past.
set-cookie: MYSAPSSO2=; max-age=0; expires=Thu, 01-Jan-1970 00:00:00 GMT; path=/; domain=.mycompany
Copy this code!
If a MYSAPSSO2 cookie with the same domain exists in the browser memory it is overwritten by this cookie and this since this
cookie with empty value is already expired, it too is removed from the browser memory. In earlier versions of the AS Java, see
SAP note 1500865, a value for the expires cookie attribute is not set by the system during the log out procedure and therefore
the MYSAPSSO2 cookie with empty value remains in the browser memory and can still be sent with requests where the URL is
a domain match for the cookie. On very rare occasions this can lead a problem like described in MYSAPSSO2 - browser and
proxy handling, where there are multiple MYSAPSSO2 cookies in the browser with domain attribute values that are domain
match for the domain in the request URL. If the MYSAPSSO2 cookie with the empty value is evaluated by the ticket accepting
system instead of the intended MYSAPSSO2 cookie containing the valid logon ticket, SSO will fail.
Expired or not yet valid ticket received

12/8/2023
Another way in which the MYSAPSSO2 cookie can be deleted and which can to lead to SSO unexpectedly breaking, can occur
when an AS Java receives a logon ticket issued by a system that it has been con gured to trust, but when it evaluates the logon
ticket it nds that the ticket is not yet valid or has expired. The AS Java that received the logon ticket will then set a
MYSAPSSO2 cookie with an empty value and domain attribute value that depends on the domain in the request URL and the
value of the UME parameter ume.logon.security.relax_domain.level. If the newly created MYSAPSSO2 cookie has the same
domain attribute value as the cookie that was received and deemed to be not yet valid or already expired, the newly created
cookie with empty value overwrites the existing one. In this case, not only will SSO using the logon ticket fail, but the absence of
the original logon ticket may cause problems on the ticket issuing system and any other systems that are con gured to accept
tickets from that system. Such issues can occur if the time of the ticket accepting system is not tightly time synchronized with
that of the ticket issuing system. See SAP note 1761987 SAP Logon Tickets Rejected Due to Clock Synchronization Issue for
more details
Related Content
Related Documents
Netscape cookie preliminary speci cation
RFC 2965
RFC 2109
SAP note 1761987 SAP Logon Tickets Rejected Due to Clock Synchronization Issue
SAP Logon Ticket - Introduction
Purpose
Introduction to the SAP Logon Ticket and how it can be used for Single Sign On (SSO)
Overview
The SAP Logon Ticket is an authentication token that can be used for repeated authentication on the system that created it or
for authentication on systems other than the system that created it, eliminating the requirement to repeatedly enter logon IDs
and passwords to get access to those systems. It is typically transmitted as a non-persistent cookie and contains details about
the user and the system that created it but no user passwords
SAP Logon Ticket
The SAP Logon Ticket is an authentication token that represents a user’s credentials. Once a user is authenticated by any
supported means (e.g. logon ID and password) on an appropriately con gured system, the system creates a Logon Ticket for
the user. The Logon Ticket can then be used to access resources on that same system that require authentication, or can be
used to gain access to other systems that ʻtrust’ the system that created the Logon Ticket, eliminating the requirement for a
user to repeatedly enter a Logon ID and password for each system accessed (Single Sign-On /SSO)
A SAP Logon Ticket contains the following data
Ticket Version
Ticket Codepage
User name
Issuing System ID
12/8/2023
Issuing System Client
Creation Time of the ticket
Validity Period of the ticket
Digital Signature using the private key of the issuing system
Authentication scheme
A SAP Logon Ticket does not contain any passwords.

The SAP Logon Ticket has a lifetime that is con gured in the system that creates the ticket
SAP Logon Tickets for Single Sign-On
SAP systems can be con gured to both issue and accept SAP Logon Tickets. In order for SAP Logon Tickets to be used for
Single Sign-On (SSO) there must be one system con gured to issue SAP Logon Tickets and one or more systems can be
con gured to accept logon tickets issued by that system.
After a user successfully authenticates on a ticket issuing system, by entering a logon ID and password for example, the system
creates a SAP Logon Ticket for that user. In order for the Logon Ticket to be used by the user for successive authentication, the
server stores the ticket in a non-persistent cookie named MYSAPSSO2 which is sent back to the client with the http response of
the server to be kept in the browsers main memory.
This cookie is then sent by the browser with all requests where the domain speci ed in the URL of the request matches the
value of the domain attribute of the cookie. This means that if there is a request that goes to some system in that domain, that
system will receive the cookie containing the Logon Ticket and it can be used to SSO to that system.
In certain scenarios Logon Tickets can also be transferred via JCo connections for authentication purposes. For example in the
Web Dynpro adaptive RFC model the JCO connection used for application data can be con gured to send a Logon Ticket
Note on SSO con guration

A system may be con gured to issue SAP Logon Tickets while at the same time not accepting Logon Tickets from any other
system. Conversely, a system may be con gured to accept logon tickets issued by other systems, but not to issue Logon Tickets
itself. As a result, SSO with SAP Logon Tickets is unidirectional.
SAP Logon Tickets are implemented using Public Key Cryptography. When a system creates a SAP Logon Ticket the system
digitally signs the ticket using a using a public and private key pair. Other systems verify the digital signature of the SAP Logon
Ticket using the public key of the key pair used to sign the ticket. This is achieved by exporting the public key from the system
that created the ticket and importing it into each system that will receive Logon Tickets issued by that system.
SAP Logon Tickets - Prerequisites

Except in cases where User Mapping is con gured, users must have the same logon ID in the ticket accepting system(s)
as they do in the ticket issuing system.
Since Logon Tickets have a nite lifetime with an expiration time speci ed that is checked by ticket accepting systems,
the times of the ticket accepting system(s) should be tightly synchronized with the time of the ticket issuing system, via
NTP for example.
The ticket issuing system must possess a public and private key pair and public-key certi cate so that it can digitally sign
the logon ticket
Systems that accept logon tickets must have access to the issuing server's public-key certi cate so that they can verify
the digital signature provided with the ticket
Where the SAP Logon Ticket is transferred via http in a MYSAPSSO2 cookie:
End user’s browsers must accept cookies.
Any systems that are to accept the logon ticket should be located in the same DNS domain or (sub-domain) as
the ticket issuing server. This is because the browser checks the value of the domain attribute of the MYSAPSSO2
12/8/2023
cookie containing the Logon Ticket against the domain in the request URL to decide if it should send the cookie
with the request or not. If they are not a ʻdomain match’ then the cookie will not be sent with the request and
SSO cannot take place. (There are two exceptions to this rule when the ticket issuing system is an AS Java; The
SAP Logon Tickets for Multiple Domains feature of Enterprise Portal facilitates the creation of a second
MYSAPSSO2 cookie containing the same logon ticket but with a completely different domain attribute value and
the domain relaxing feature of the AS Java allows one or more sub-domains to be removed from the MYSAPSSO2
cookie’s domain attribute value, therefore widening the scope of the cookie)
The MYSAPSSO2 cookie
Purpose
Introduction to the MYSAPSSO2 cookie, how it is used to transmit the SAP Logon Ticket and some important aspects of the
MYSAPSSO2 cookie creation process
Overview
The MYSAPSSO2 cookie is a non-persistent cookie that is stored in the browser's memory. Its value is the encoded content of
the SAP Logon Ticket. The browser is used to transmit the Logon Ticket from system to system via the MYSAPSSO2 cookie.
After a user authenticates on a ticket issuing system, the system issues the user a logon ticket, which the user can use for
access to successive systems. The ticket issuing system encodes the logon ticket and sets it as the value of non-persistent
cookie with the name MYSAPSSO2.
An example of a POST request from a browser where the end user enters logon ID and password in the Enterprise Portal
logon page and the server's response to the successful logon including a MYSAPSSO2 cookie containing the user's newly
created logon ticket
The cookie is sent back to the client with the server’s response where it is stored in the browser memory. The browser uses the
value of the cookie’s domain attribute to determine with which requests it should send cookie and therefore which systems
should receive the logon ticket. Only if the browser considers the cookie’s domain to be a ʻdomain match’ to the domain in the
request URL will it send the cookie with the request. It is this browser behaviour that results in the prerequisite for SSO with
SAP Logon Tickets that the ticket accepting system(s) must be in the same DNS domain (or sub-domain) as the ticket issuing
system. This domain restriction is an important consideration when planning a SSO scenario in a multi-system landscape. For
more details on how the browser handles the cookie refer to The MYSAPSSO2 cookie - browser handling
MYSAPSSO2 creation
Setting the cookie's domain attribute
When creating the MYSAPSSO2 cookie the ticket issuing system sets the domain speci ed in the request URL as the value of
the cookie’s domain attribute. For example if the logon ticket is issued by server server.support.mycompany.com, the
MYSAPSSO2 cookie will usually have a domain attribute value of .support.mycompany.com. Therefore in a SSO scenario using
Logon Tickets, all URLs used should contain the Fully Quali ed Domain Name (FQDN) of the server and not the hostname or IP
address. If the FQDN name is not contained in the URL, and instead the hostname is used, the hostname is set as the cookie’s
domain attribute value. Likewise if an IP address is contained in the request, the IP address is set as the cookie’s domain. In both
of these cases, the browser will only send the MYSAPSSO2 cookie with requests back to the ticket issuing system and therefore
SSO to other systems cannot take place.
12/8/2023
The value that a ticket issuing system sets for the MYSAPSSO2 cookie’s domain attribute can be observed in the server’s http
response to the client’s authentication request. This response contains a set-cookie response header with MYSAPSSO2 and the
encoded logon ticket as the set-cookie name-value pair. Appended to the cookie value is the domain attribute and value.
set-cookie: MYSAPSSO2=AjExMDAgABBwb….; Domain=.support.mycompany.com; Path=/;
Copy this code!
Domain relaxing
The Netweaver AS Java offers domain relaxing functionality. Using the ume property ume.logon.security.relax_domain.level the
server can be con gured to strip one or more sub-domains from the FQDN when the MYSAPSSO2 cookie is being created. For
example, if the value is 2 and the logon ticket is issued by the server server.support.mycompany.com, the MYSAPSSO2 cookie’s
domain attribute value will be .mycompany.com.
This domain relaxing widens the scope of the MYSAPSSO2 cookie so that the browser will send it with all requests to domain
mycompany.com and its sub-domains rather than just with requests to support.mycompany.com and its sub-domains.
The domain relaxing feature does not allow SSO between two completely different domains since it only strips away one or
more subdomains from the cookie's domain attribute value and the root domain in the attribute remains unchanged.
Related Content
Related Documents
The MYSAPSSO2 cookie - browser handling
Troubleshooting SSO issues between AS-ABAP and AS-JAVA
Where are you asked to enter credentials?
AS ABAP prompts to enter credentials (AS-JAVA is the ticket issuer)
AS JAVA prompts to enter credentials (AS-JAVA is the ticket accepting system)
In case AS-ABAP prompts for credentials perform the steps below:

Step 1: Start the SSO2 wizard on the J2EE engine and check it's own certi cate:
Step 2: Note down the client the j2ee engine issues the MYSAPSSO2 cookies. (999 in the screenshot above)
Step 3: Click on View certi cate and check the "Issuer DN" and the "Not valid after" period of the J2EE certi cate. The validity
12/8/2023
period must not exceed the date:
January 01 2038. See note: #1055856 - Common error messages when setting up Single Sign-On for more details on the
expiration period.
Step 4: Start transaction STRUSTSSO2 on the ABAP client which is called from the SAP J2EE engine. (E.g. if ABAP client 001 is
called from the engine STRUSTSSO2 must be started in that client.)
Step 5: Select the j2ee certi cate from the certi cate list. You can nd it based on the "Issuer DN" property from Step 3. Make
sure that the validity period is the same in STRUSTSSO2 as in the SSO2 wizard. This is just to ensure that the certi cate was
not exchanged in the meantime.
Step 6: Make sure that an ACL entry exists which contains the SID of the AS-JAVA installation, the client and the "Issuer DN"
shown in the SSO2 wizard. (In our example the ACL must contain an entry with ERP, 999, and the "Issuer DN")
Step 7: If all the aboves are correct (e.g. the correct certi cate was imported and the ACL entry is also OK) prepare the ABAP
system to create a security trace as per note:
#495911 Trace analysis for logon problems
Step 8: Reproduce the issue as follows:
a) logon to any j2ee application which issues a MYSAPSSO2 cookie like:
http://<AS-JAVA FQDN>:<j2ee port>/useradmin
b) then call this from the same browser (make sure that the ping service was activated in transaction SICF before):
http://<AS-ABAP FQDN>:<ICM port>/sap/bc/ping?sap-client=<ABAP client>
Make sure AS-JAVA and AS-ABAP are accessed through the same domain
Back to top .
In case AS-JAVA prompts for credentials perform the steps below:
Important notice: it may happen that you don't see the logonpage of the ticket accepting system, but the following scenarions
fail: FPN test, search for Remote Roles on the producer portal in the FPN scenario, BI supportdesktool shows red lights at
certain locations.
Step 1: Start the SSO2 wizard on the called system and make sure the calling system is con gured as trusted. There must be a
green light at the certi cate of the calling system:
12/8/2023
Step 2: In case the issue happens in an FPN, or the AS JAVA is called from the BI transaction RSPLAN, add the
EvaluateAssertionTicketLoginModule to the second position of the ticket stack with the same options as the
EvaluateTicketLoginModule.
Step 2: Start the webdiagtool on the called system as described under Example 3 in SAP Note: #1045019 Web diagtool for
collecting traces and reproduce the issue.
Step 3: search for errors above the row where the LOGIN.FAIL was protocolled:
Typical errors will be like:
None of the systems defined in the ACL of EvaluateTicketLoginModule in [ticket] authentication stac
equals to SAP Logon Ticket issuing system.
Copy this code!
Back to top .
Multi domain SSO failure
SSO might fail if the portal is accessed through SAP Webdispatcher or proxy
Let's say the webdispatcher is installed in the domain external.net but the sapsystems in internal.net.
If the portal is called in the intranet through hostname.internal.net a MYSAPSSO2 cookie will be issued for the internal.net
domain. In this case when the second system is called, the browser will send this cookie and the SSO will work.
If the portal is called through the webdispatcher the MYSAPSSO2 cookie will be issued for the domain external.net. This cookie
won't be sent by the browser in the SSO scenario as the domains are different.
By setting the ume.login.mdc.hosts = http://<hostname.internal.net>:<port> the portal will execute a 'redirect' to himself and
by this a second cookie for the internal.net domain will be issued even if the portal was called through the internet.
12/8/2023
Using the SSO2 wizard to set up SSO between java systems
Purpose
This page will give a rough guide on ow to use the SSO wizard to set up SSO using login tickets between seperate Netweaver
java application servers.
Overview
We will list the prerequsites needed for SSO and detail with screenshots con guring SSO in both directions between a 7.00 and
7.30 java system.
Prerequsites
All documentation on SSO with login tickets can be found here:
http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4a/446f50dc3d2baee10000000a421937/frameset.htm
Both systems need to have the same DNS domain.
Client Browsers need to accept cookies.
Operating clocks need synced as close as possible.
The user has to exist on both systems.
The SSO2 wizard
The SSO wizard can be accessed with following URL: http:\\<hostname>:<http port>\sso2
In this example we are going to con gure SSO between a java 7.02 system (J70) and a 7.3 system (J73).
The certifcate of the issuer (J70) needs exported to the accepter (J73), so run the wizard on J73, then select "Add Trusted
System" -> "by qureying trusted system"
The following pop up appears:
12/8/2023
You can nd the system this way but just click cancel. Then we see the rst step in the wizard, select java system and enter
issuer details (J70):
Afte clicking next the wizard automatically logs on to J70 and pulls the certifcate from it:
12/8/2023
Clicking nish adds the certifcate to the trusted list:
You can now login into J70 initially and assuming you meet the SSO prerequsites you will be automatically logged into J73, the
process can be reversed by running the wizard on J70
Common SSO (AS JAVA to AS ABAP) issues, solutions and further troubleshooting
<<<<CONTINUATION FROM SAP KBA 2551642>>>>
PURPOSE:
The purpose of this document is to proactively check (and rectify) common Single Sign On (SSO) issues between SAP
Application Server JAVA and SAP Application Server ABAP on the actual servers involved.
12/8/2023
EXAMPLE SCENARIO:
Lets say the con gured Single Sign On (SSO) setup between SAP Portal and the SAP Application Server ABAP fails and you get
a logon page:
Another example of an error would be that you test a portal system connection (Con gure System Connection in SAP
Enterprise Portal) and this fails with an SSO error:
To check if SSO between the ABAP and the J2ee server is working, test using the method mentioned in SAP Note 1903560.
Similarly use the technique mentioned in SAP Note 2028229 to ascertain the SSO between 2 JAVA servers.
COMMON SSO ERROR SCENARIOS AND THEIR SOLUTIONS:

1)
ISSUE: SSO FAILS DUE TO USER ID MISSING/MISMATCH on the ABAP SERVER/ USER MAPPING FAILS.
If the user which was used to login to the SAP Application Server JAVA does not have the same logon ID on the ticket accepting
system (R/3 server), then the SSO logon will fail.
SOLUTION:
Make sure that the user IDs are the same in the ticket issuing and the ticket acception server (but the passwords can be
different). The User Mapping option is only available if there is an Enterprise Portal. User mapping option maps a portal user ID
to the user ID of the back-end system.
For different User mapping options, check:
https://help.sap.com/saphelp_nwmobile71/helpdata/en/46/3e52f9f3a502eae10000000a155369/frameset.htm
and
How User Mapping with SAP Logon Tickets works

12/8/2023
If theer are issues with the user mapping, check SAP KBA ##1913922 - Single-Sign-On (SSO) failed with user mapping.
2)
ISSUE: BROWSER DOES NOT ALLOW COOKIES
In the HTTPWATCH traces, you do not see the MYSAPSSO2 cookie.
SOLUTION:
Firstly make sure that the browser employed is as per SAP standards (check PAM: https://support.sap.com/en/release-
upgrade-maintenance.html ).
If the browser does not accept the SAP cookie, then this can be resolved by removing the cookie restriction in the browser:
3)
ISSUE: SSO fails due to MYSAPSSO2 cookie not being created
SOLUTION:
The CreateTicketLoginModule should be part of the authentication stack.
***************************
Ticket Login Module Stack*
***************************
_____________________________________________________
Login Modules Flag |
|
EvaluateTicketLoginModule SUFFICIENT |
|
BasicPasswordLoginModule REQUISITE |
|
12/8/2023
CreateTicketLoginModule OPTIONAL |
_____________________________________________________
More information along with sample stacks are available here:
Sample Login Module Stacks for Using Logon Tickets
4)
ISSUE: MYSAPSSO2 COOKIE IS NOT SENT TO THE ACCEPTING SYSTEM AS IT IS IN DIFFERENT DOMAIN
If the accepting system is in a different domain, the MYSAPSSO2 cookie may not be sent since it is valid only for systems in the
same domain as the issuing system.
SOLUTION:
SSO with SAP Logon tickets for multiple domain is supported starting with EP6 SP6. You can also use domain relaxing if the
domains differ only in a subdomain name. In this case, specify the number of subdomains to be cut from the SAP Application
Server JAVA domain name using the parameter ume.logon.security.relax_domain.level.
For more help, check SAP Note 701205.
Example: If the host name for the Portal is portal.wdf.sap.com and ume.logon.security.relax_domain.level=2, then the
MYSAPSSO2 cookie is sent to all servers within the domain sap.com.
An HTTPWATCH trace will help in such cases.
If the SAP Application Server JAVA and the ABAP server are on completely different domains, check point 16.
5)
ISSUE: MYSAPSSO2 COOKIE VALUE IS OVERWRITTEN
When a user successfully authenticates on two systems where both systems do not accept SAP Logon Tickets issued by the
other and if both systems set MYSAPSSO2 cookies with the same domain attribute, then the MYSAPSSO2 cookie set by the
rst system is overwritten.
This can cause authentication/SSO failures if there are subsequent requests where the SAP Logon Ticket issued by the rst
system should be used for authentication.
SOLUTION:
Create TRUST between the two servers using the SSO2 wizard (see SAP NOTE ##1083421) and con gure domain parameters
accordingly.
6)
ISSUE: MULTIPLE MYSAPSSO2 COOKIES ARE BEING SENT BY THE BROWSER
In a multiple system scenario where a user has successfully authenticated on more than one system, it is possible that there
are multiple MYSAPSSO2 cookies in the browser’s cookie store, each with different values and domain attribute values. It can
occur with certain requests that, based on their domain attribute values; more than one MYSAPSSO2 cookie is sent.
SOLUTION:
12/8/2023
Usually this is a SAP system landscape design issue. Most likely the adjusting the value of ume.logon.security.relax_domain.level
in the SAP Application Server JAVA can work around the problem. For more help, check SAP Note 701205 and SAP NOTE
1368384.
There is a known issue when tabbed browsing is used. More details are available in SAP KBA ##2097889 - Using tabs with
different Systems and users with SAP Netweaver AS Java can lead to issues.
7)
ISSUE: MISSING SAPLogonTicketKeypair ON THE ISSUING SYSTEM
If the issuing server does not have a key pair exactly named SAPLogonTicketKeypair, it cannot sign the ticket. That way the
ticket won’t be created at all. Another similar issue is when the below error occurs in the traces:
************************************************************************
Cannot verify ticket. A le entry with the name <ticket name> cannot be found in the con guration "keystore..”
************************************************************************
SOLUTION:
Create or replace the key pair as per requirement. More help:
Creating a Key Pair and Public-Key Certi cate
http://help.sap.com/saphelp_nw73/helpdata/en/36/7627aa3fe440369150a434f8137eda/frameset.htm
Replacing the Key Pair to Use for Logon Tickets
http://help.sap.com/saphelp_nw73/helpdata/en/75/c80b424c6cc717e10000000a155106/frameset.htm
Final con guration should look like this:
12/8/2023
Also see SAP Note ##791649 : User unable to logon by ticket
8)
ISSUE: MYSAPSSO2 SECURITY ISSUE:
If a user manages to get hold of a logon ticket, as long as this ticket is valid, it will be accepted even if the user has logged off
from the system in the meantime.
SOLUTION:
Set the login.ticket_revocation as mentioned in SAP NOTE ##1598793 - Logon ticket revocation. Possible values are:
none - no logon tickets will be revoked
all - the logon ticket of the user will be revoked as soon as they log off, regardless of which system actually issued it
own - the logon ticket of the user will be revoked as soon as they log off only if they log off from the same system that
issued the ticket
9)
ISSUE: : RECEIVING SERVER DOES NOT HAVE THE ISSUING SERVER'S PUBLIC CERTIFICATE
If this certi cate is not present, the accepting system cannot verify the ticket, which was signed with issuing system’s private
12/8/2023
key and can be veri ed only by its public key (contained in the certi cate).
SOLUTION:
The SAP Application Server JAVA certi cate should be added to the /nSTRUSTSSO2 Tcode on the accepting ABAP server.
Do note that if the SAP Application Server ABAP has several instances, a "DISTRIBUTE" needs to be one for the ocn guration
changes to be available on other servers as well.
10)
ISSUE: SSO FAILS CAUSE THE MAXIMUM VALIDITY IS SET TO A VERY HIGH LIMIT
SOLUTION:
The maximum validity of the certi cate should not exceed the date: January 01, 2038 (See SAP Note ##1055856 for more
details).
12/8/2023
11)
ISSUE: DISCREPANCIES IN THE VALUES OF SESSIONEXPIRATIONPERIOD and the LOGON TICKET
VALIDITY
SOLUTION:
The timeout value for the security sessions (default 27h) and the timeout value for the SSO ticket (default 8h) should ideally be
set to the same value. It should be a value that is higher than the maximum working time of an employee, e.g. 16 hours.
and
12/8/2023
12)
ISSUE: TIMEZONE ISSUES
An example from actual traces:
************************************************************************
N Got content client = 000.

N Got content sysid = BJP .
N Got date 201306271516 from ticket.
N Cur time = 201306271519.
N Computing validity in hours.
N Computing validity in minutes.
N CurTime_t = 1372432740, CreTime_t = 1372432560
N validity: 120, difference: 180.000.
N *** ERROR => HMskiCheckValidity failed. [ssoxxkrn.c 1080]
N {root-id=51BA347B347A0E24E10000000AF00318}_{conn-id=00000000000000000
000000000000000}_0
N dy_signi_ext: ticket expired
"
************************************************************************
The Ticket is valid for 120 seconds = 2 Mins and it seems to have expired as there is a difference of 3 minutes between the SAP
Application Server JAVA and the SAP Application Server ABAP clocks. The ticket has the time 201306271516 (that is
27/06/2013 15:16) while the ABAP server time is 201306271519 (that is 27/06/2013 15:19).
SOLUTION:
Synchronize the SAP Application Server JAVA and the SAP Application Server JAVA clocks. This will make sure that the ABAP
and the JAVA servers have the same time as this can lead to issues with the validity of the cookie.
On the AS JAVA, check SAP NOTE ##1867012 - SAP JVM Time zone values in SAP AS Java and SAP Note ##1367871 - Timezone
updates for SAP JVM.
On the AS ABAP, check Timezone changes best practices .
13)
ISSUE: ABAP SERVER REJECTS THE MYSAPSSO2 COOKIE
12/8/2023
If the user which was used to login to the SAP Application Server JAVA does not have the same logon ID on the ticket accepting
system (R/3 server), then the SSO logon will fail.
In this case the response from the ABAP system includes a cookie named sap-ssolist. The sap-ssolist cookie contains base64
encoded information about the application server which received the MYSAPSSO2 cookie but did not accept the SAP Logon
Ticket. The cookie value can be decoded to get this information which is very useful particularly in the case where there are
multiple instances of the ABAP system.
SOLUTION:
Set the pro le parameters:
login/accept_sso2_ticket = 1
and
login/create_sso2_ticket = 2
on the ABAP server. Once done, make sure that the /nSTRUSTSSO2 “distribution” has been done. More help:
Con guring the AS ABAP for Issuing Tickets for Logon
14)
ISSUE: OLD PSE FILE ON THE AS ABAP LEADS TO ISSUES
SOLUTION:
On the SAP Application Server ABAP, replace the SSO PSE of the server before the public-key certi cate expires. Otherwise,
users cannot receive logon tickets and cannot use SSO. More help:
https://help.sap.com/saphelp_nw73/helpdata/en/59/6b653a0c52425fe10000000a114084/frameset.htm
15)
ISSUE: MYSAPSSO2 COOKIE IS NOT FORWARDED FROM AS JAVA TO AS ABAP
SOLUTION:
12/8/2023
Checks to be done in such cases:
1) Check if hostnames of the servers involved are as per SAP standard. (see SAP Note 611361: Hostnames of SAP servers).
"
General rule for hostnames according to RFCs 952, 1101, 1123, 1178: Alphanumerical string of alpha characters [A-Z] and [a-z]
and digits [0-9] and the hyphen (or minus) character "-". Although the newer RFCs permit hostnames beginning with digits we
recommend hostnames to begin with an alpha character.
"
Also check SAP Note ##654982 : URL requirements due to Internet standards, SAP Note ##1334956: Various problems that
are solved by using FQDN in portal URL and
SAP Note 2497800 - SSO fails with underscore character in hostname.
2) Load balancer should not halt the cookie transfer. To isolate the issue further, try to check bypassing the load balancer.
More info:
http://wiki.scn.sap.com/wiki/display/ASJAVA/MYSAPSSO2+-+browser+and+proxy+handling
3) The browser that is being used is not as per SAP standards. If so, make sure that the browser employed is as per SAP
standards (check PAM: https://support.sap.com/en/release-upgrade-maintenance.html ).
16)
ISSUE: THE TICKET ISSUING SERVER AND THE RECEIVING SERVER ARE ON COMPLETELY DIFFERENT
DOMAINS
The MYSAPSSO2 cookie is not forwarded in such a scenario.
SOLUTION:
A setup similar to the one mentioned in SAP Note No. ##1604482 needs to be considered to get the con guration to work. In
this case, the UME parameter : ume.login.mdc.hosts may have to be amended. For more help:
Con guring Logon Tickets for Multiple Domains
https://help.sap.com/viewer/7ba199e10fdc488293db33f0709f9225/7.3.17/en-US/e0fa984050a13354e10000000a1550b0.html
17)
ISSUE: SSO BETWEEN SAP Application Server JAVA TO 3rd PARTY SERVER FAILS
SOLUTION:
Only SAPSSOEXT solution is supported in such cases. For more help, check:
http://service.sap.com -> Technology Components -> SAP SSOEXT-> SAP SSOEXT

and:
12/8/2023
https://wiki.scn.sap.com/wiki/display/ERPHCM/SAP+SSO+Authentication+with+verify.pse+using+SAPSSOEXT
18)
ISSUE: AFTER CONNECTION IS MADE TO THE AS ABAP, NO DATA IS DISPLAYED
From the HTTPWATCH traces, the content-length header is 0. This means that the client (browser) will close the connection
right after receiving the headers and any following attempt to send something will fail. Any Content-Length greater than zero is
a valid value.
SOLUTION:
-> Check network proxy.

-> Browser being used.
-> Connection between the servers involved.
→ The Load balancer might have an effect on this
19)
ISSUE: LOGIN.TICKET_CLIENT AND THE VALUE OF THE ABAP CLIENT ARE SAME IN AN ADD IN SERVER
Compatibility Issues can occur on ADD IN (DUAL STACK) servers when the client in the SAP Application Server JAVA UME
property login.ticket_client is the same as the TCode /nSTRUSTSSO2 ACL (Access Control List) on the R/3 server.
SOLUTION:
Change the login.ticket_client value to a client that is not present in the ABAP server (say 678) and restart the Application
Server JAVA server. Then run the SSO2 wizard (as per SAP NOTE: ##1083421) again and then update the /nStrustsso2.
20)
ISSUE: SSO VIA PROTOCOL: HTTPs WORKS, BUT FAILS WITH PROTOCOL: HTTP
SOLUTION:
Using the Con g Tool, check the value of the ume property ume.logon.security.enforce_secure_cookie.
If it has value true -> only https will work.
and
If it has value false -> https and https will work
More help: Ticket issuing - UME properties
12/8/2023
21)
ISSUE: "TICKET" POLICY CONFIGURATION IS INCORRECT
SOLUTION:
The 'ticket' policy con guration's login module stack must contain at a minimum EvaluateTicketLoginModule,
BasicPasswordLoginModule and CreateTicketLoginModule in that order from top to bottom with appropriate ags at some
point in the stack.
EvaluateTicketLoginModule to accept logon tickets for SSO.
CreateTicketLoginModule for creating logon tickets
BasicPasswordLoginModule and DigestLoginModule to perform the authentication with user ID and password. For more help,
check:
https://help.sap.com/saphelp_nw70/helpdata/de/99/f66e424925c253e10000000a1550b0/frameset.htm
and
SAP NOTE ##2273981: Con guring Authentication stacks for Netweaver Application Server JAVA.
22)
ISSUE: NO PORTAL AND NO ABAP USER. TICKET CREATION IS ABORTED
Neither a portal user ID nor ABAP user ID could be written to the logon ticket so the creation of the ticket was aborted.
SOLUTION:
This can occur if the user that is logging on has a logon ID greater than 12 characters, for example the 'Administrator' user, and
either the UME property login.ticket_portalid has value no or login.ticket_portalid has value auto but no Enterprise Portal is
installed. Since ABAP user IDs must be 12 characters or less, longer IDs cannot be written as the ABAP user in the logon ticket.
As the login.ticket_portalid is NO, this means that the logon ID will not be written as the portal user ID in the ticket either.
Therefore ticket creation is aborted.
Con guring a value of yes for login.ticket_portalid will ensure that the logon ID is written as the portal ID in the ticket and the
ticket creation will succeed.
12/8/2023
23)
ISSUE: TICKET SIGNING CERTIFICATE DOES NOT USE DSA ALGORITHM
SOLUTION:
Recreate the key pair used for SAP Logon Tickets.
NOTE: Be aware that if you have con gured SSO with SAP Logon Tickets where the Netweaver AS Java is the ticket issuing
system you must re-import the public key certi cate of the AS Java into all ticket accepting systems after recreating the key
pair
24)
ISSUE: AFTER SAML AUTHETICATION, MYSAPSSO2 COOKIE IS NOT CREATED (FOR SSO TO AS ABAP)
In this case, the SAP Application Server JAVA is the SP (Service provider). Once the SAML logon happens the MYSAPSSO2
cookie is not generated and subsequent SSO to the AS ABAP does not occur.
SOLUTION:
Check SAP KBA ##2435661 - MYSAPSSO2 cookie (logon ticket) not created after SAML logon for SSO
NOTE: ALSO CHECK SAP NOTE 1055856: Common error messages when setting up Single Sign-On for
other comon issues.
FURTHER TROUBLESHOOTING:
Say the above checks have been done and the issue still persists. Now it is time to delve deep into the server logs and
investigate further. This is needed to narrow down the issue as to whether it is an SAP Application Server JAVA or an SAP
Application Server ABAP or a browser issue (the list can go on) . For this, an END TO END trace is needed.
For more help, check SAP KBA ##2487383: How to Troubleshoot SSO with Logon Tickets with the SAP Netweaver Java AS.
The detailed steps are:
12/8/2023
1)
Clear all the browser cache.
2)
Set the security trace level in the ticket accepting system (R/3 server)
======================================================
2.1. Call transaction SM50 (process list):
2.2. Process -> Trace -> Reset -> Workprocess Files
2.3. Key combination: F5 (select all), CTRL-Shift-F7 => Dialog box;
2.4. Set trace level=3 and ONLY(!) check the “Security” component;
If necessary, you must repeat these steps for each server (see transaction SM51), unless you can use a speci c server
for reproducing the error (for example, by excluding the load distribution).
======================================================
3)
Run the web diagtool as outlined in SAP Note 1045019 (example 1) if you are on SAP Netweaver release 6.40 or 7.00 or as
per SAP Note 1332726 (incident “General Security”) if you are on 7.1, 7,2, 7.3, 7.4 or 7.5 version. It will be ideal to run it on the
server 0 (check SAP Note 1589567).
4)
While the diagtool is running, reproduce a failed SSO scenario to the backend.
5)
When the SSO fails, wait for a minute and then press return in the diagtool console so that the resulting traces are picked up.
6)
Also download the httpwatch tool (free from www.httpwatch.com) and take a complete end to end trace (by reproducing the
issue). More information is available in SAP Note 1558903 – How To Trace a Portal Scenario Using HttpWatch.
The HTTPWATCH le should show the MYSAPSSO2 cookie being forwarded from the SAP Application Server JAVA to the SAP
Application Server ABAP.
Incase a Firefox browser is being used, use the Live HTTP Headers.
7)
Check the diagtool traces and the ABAP workprocess traces for more details on the exact error. You can use the technique
mentioned in How to search for speci c error content in ABAP server logs and How to check logs for particular J2EE application
issue to narrow down and pin point on the exact cause.
NOTE: If you are still uncertain after all the steps mentioned in this blog and the issue still persists, contact SAP Support /
SDN and attach the below documents/logs:
— The html Diagtool log

— The J2EE server default traces
— The /nSM50 trace
12/8/2023
— Step by step screenshots of error reproduction
— the exact time at the issue was reproduced and the user ID involved.
— The screenshots ofthe TCode /nSTRUSSSO2 and the ACL.
Possible Workaround to Consider: ASSERTION TICKETS
The usage of the option “Assertion ticket” will help in such issues cause the ticket used for Single Sign On in the connection to
the R/3 backend system is only used once thus avoiding problems inherent to the SSO ticket mechanism. Refer the below links
for more on this:
Assertion Tickets – SAP Netweaver Application Server Java – SCN Wiki
and
Authentication Assertion Tickets

Conguring As Java To Accept Logon Tickets

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Conguring As Java To Accept Logon Tickets

Uploaded by

Copyright:

Available Formats

12/8/2023

Support Content | 1.0

Original content: https://help.sap.com/docs/SUPPORT_CONTENT/asjava?locale=en-US&state=PRODUCTION&version=1.0

For more information, please visit the https://help.sap.com/docs/disclaimer.

Single Sign-On with SAP Logon Tickets

AS Java as a ticket issuing system

AS Java as a ticket accepting system

Troubleshooting SSO between AS-ABAP and AS-JAVA

Using the SSO2 wizard to set up SSO between java systems

AS Java as a ticket accepting system

Con guring the AS Java to accept SAP Logon Tickets

Ticket accepting - UME properties

Con guring AS Java to accept logon tickets

Import public key certi cate of issuing system

Con gure EvaluateTicketLoginmodule/EvaluateAssertionTicketLoginmodule ACL options

trustediss<n> = <Distinguished Name of Issuer (issuerDN) in public key certi cate>

trusteddn<n> = <Distinguished Name(DN) in public key certi cate>

Entering the connection details for a Java system

ABAP systems public key certi cate imported

Con guring the AS Java to Accept Logon Tickets

Related SAP Notes/KBAs

1083421 SSO2 Wizard

Ticket accepting - UME properties

Ticket issuing - UME properties

Related SAP Notes/KBAs

AS Java as a ticket issuing system

Con gure AS ABAP to accept logon tickets issued by AS Java

Con gure AS ABAP to accept logon tickets issued by AS Java

1. Pro le parameter login/accept_sso2_ticket must be set with value 1

Export the public key certi cate from the AS Java.

Add the certi cate to the certi cate list

After importing the certi cate, its details are displayed.

Details of imported certi cate are displayed

Add the certi cate to the Access Control List

Add Entry to Single Sign-On Access Control List

Certi cate added to Access Control List

Use transaction SSO2 to check the con guration

Call transaction SSO2 and specify 'NONE' as RFC Destination

Specifying the Client to Use for Logon Tickets

Related SAP Notes/KBAs

Logon Ticket creation in AS Java

Authentication and Logon Ticket Creation

Authentication stack: [ticket].

Copy this code!

De ning an Authentication Scheme

Related SAP Notes/KBAs

Ticket issuing - UME properties

Important parameters for logon ticket creation

Default value 000.

NO = The ʻPortal User’ is never written into the logon ticket.

ʻPortal User’ has the form ʻportal:<logon id>’

Number of hours that the logon ticket is valid

Logon Ticket creation in AS Java

Related SAP Notes/KBAs

SAP Logon Ticket

General SAP Logon Ticket topics

An introduction to the SAP Logon Ticket

SAP Authentication Assertion Tickets

Comparison with Logon Tickets

Using Logon Tickets

Related SAP Notes/KBAs

MYSAPSSO2 - browser and proxy handling

MYSAPSSO2 cookie handling by browsers