Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

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.



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 - julia.kielbasiewicz/blog/2005/04/17/integration-of-sap-business-warehouse-and-enterprise-portal-150-single-sign-on) 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.

6 Comments