Skip to Content

Have you asked yourself how does SAP Logon Ticket (SLT) work ? Is it really secure ? I will try to explain it, with the little help of a picture below.

image

Example landscape directory

Well the SLT is actually a HTTP Cookie issued by the portal system to client browser after a successful logon. It contains portal user name, expiry time and target system identification signed by portal secure certificate.

The logon procedure looks like so:

  • User (2) calls the portal (1)
  • Portal responds with logon page
  • User sends the creditentials to the portal
  • Portal sends back some cookies to the user in 3-4 HTTP roundtrips.
    One of this cookies is the SAP Logon Ticket.
  • User (2) contacting some other system (4) sends the SAP Logon Ticket along the HTTP to that system.

If you would take a closer look at the cookie you would see

This cookie is then send by the browser in all subsequent HTTP calls done by the browser in this session. The recievier system (number 4 in my landscape) – for example SAP Business Warehouse WAS called on the HTTP port, when properly configured (like in Julia Kielbasiewicz’s weblog about Single Sign On – look here) checks the portal certificate with the one stored and then authorizes the user.

Everything seems right until one tries to access some data – for example salary information – that he is not authorized to. Imagine that some other user (number 3 on the picture) turns on network monitoring software. He can there trace our network communication with the portal system and fetch the contents of the ticket. Because the SLT does not verify the user machine, only it’s name anyone fetching the SLT can use it to access other systems in landscape. I have performed a little test. My friend using a prepared HTTP call with my SLT logged on to BSP application onto my account.

Means of protection

  • Using HTTPS so the SLT is not available to third party
  • Additional authorization – for example NTLM

While using HTTPS is quite obvious, i would like to add few words about NTLM. When you use integrated Windows domain logon to portal, a IIS based proxy server authorizes the user and then calls SAP IISProxy module which contacts the portal, forwarding logged user name. This process is rather secure, even when only HTTP is used – it uses challenge-response authorization type, not just simple user/password transfer. But when the SLT Cookie for other system gets transferred over the HTTP the security of the installation is compromised. To protect from this issue, you can use the IIS proxy server to access external systems too. The IIS proxy forwards the request adding AUTHORIZED_USER header variable, which contains name of the user from Windows domain. It can be used together with SAP Logon Ticket to verify user authenticity.

I have proposed a session for the SAP TechEd about SSO in Portal, where i cover the issue in more detail.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Raúl Martínez
    Very good!!!.

    But, my problem is that i want to use the sso with sap logon ticket to no-sap applications (an external j2ee application), do you know article or example?.

    Best Regards,
    Raúl Martinez.

    (0) 
    1. Anonymous
      Hello Raul,

      There is such possibility. I will post a tutorial soon on SDN, you might also want to browse trough help.sap.com. SAP provides Java library for verifying the SLT, i will base my tutorial upon it.


      regards
      Marcin

      (0) 
      1. Anonymous
        Hi Marcin,

        I’m sure the SDN community will be looking forward to that!

        Pranav

        (0) 
    2. Gaurav Gandhi
      Hi Raúl,

      You dont have to wait the the new blog comes for SSO…
      There are two ways to do SSO for Non-SAP Java Based application.
      1) One is using a few JAR files namely iaik_ice.jar and verify.der. For details see webblog:https://www.sdn.sap.com/sdn/weblogs.sdn?blog=/pub/wlg/960. [original link is broken] [original link is broken] Very good blog by Robert Chu.

      2) Other is : Using the verify.pse and SAP Security Libraries. For this see the post /thread/42807 [original link is broken]

      Hey, i think i can also write blogs now..:-)

      Regards
      Gaurav Gandhi

      (0) 
    3. Rick Bullotta
      Search SDN for an example of this posted by Stephan Boecker from SAP and my colleague Tim Mulle from Lighthammer.  We use this approach to use SSO tickets in our own (non SAP) application.
      (0) 
  2. Wolfgang Janzen
    The SAP logon ticket mechanism war originally designed for the SAP Workplace (= kind of predecessor of Enterprise Portal). The key design issue is the fact that there is one central system where user authentication takes place and many other (recipient) systems which should be integrated in this SSO compound; those systems and the central system however do not communicated directly with each; the integrating factor is the user (actually: the web browser).
    Therefore the cookie mechanism was choosen as transport mechanism. The cookie (MYSAPSSO2) contains the SAP logon ticket which is digitally signed. The recipient systems verify the ditigal signature of the SAP logon ticket and perform an ACL lookup (since not every authenticated signer might be trusted) evaluating the information on the ticket creator (“system ID”, “client”).

    The issuer of the SAP logon ticket decides on the (maximum) validity period. The SAP logon ticket contains a creation timestamp (UTC); the recipient systems have to check on the validity of the SAP logon ticket.

    Unlike SAML (authentication) assertions SAP logon tickets are not safe against replay attacks (since the cookie mechanism is based on repeated transmission). Therefore it is important to make sure that SAP logon tickets cannot be intercepted. Using https (SSL) is strongly recommended (not only because of the user credentials but also because of the business data transmitted). Furthermore it is important to make use of the (limited) restriction capabilities the cookie mechanism offers: placing all servers in one common DNS domain (and disallowing other servers to join that domain) allows to control the group of servers which will gain access to the SAP logon ticket.

    Compared with Basic Authentication credentials SAP logon tickets are the better choice since
    – SAP logon tickets do not contain userID/pwd
    – SAP logon tickets are digitally signed
    – SAP logon tickets have a restricted validity
    – SAP logon tickets can be deleted on server request (e.g. on reaction of a “logoff” request)
    – the group of servers to which the cookie MYSAPSSO2 (=> SAP logon ticket) is send is determined (by the cookie domain restriction rules)

    Regards, Wolfgang

    (0) 

Leave a Reply