Skip to Content

Single-Sign on in your SAP Landscape has changed with the gradual introduction of the SAP Web AS Java for use with each of your applications. With the delivery of SAP’s most widely used J2EE application, the SAP NetWeaver Portal; and the use of the Web AS Java for many other Java applications being delivered by SAP, there is an increasing need for the Java Engines within your enterprise to be enabled for Single-Sign On.

As the basis for any of the SAP System Trust relationship, we will need to take the Public key from each of the SAP Systems and exchange them, to allow  non-repudiation. This step allows each of the Portal system to be certain that the SAP Logon ticket it receives was really created by the System it has been told to trust.


To report this post you need to login first.


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

  1. Nice informative blog indeed.

    But I am wondering why this process is so complex? Couldnt someone invent a wizard that abstracts from all different admin tools that are
    needed to achieve this (e.g. J2EE admin, Portal admin tool etc..)

    1. Former Member Post author
      Hi Kiran,
      The procedure does seem complex, which is the reason for this blog in the first place ๐Ÿ™‚

      Breaking it down into these three steps is aimed to help someone keep in mind what they are doing.

      The reason for the perceived complexity is :
      a) so this Single-sign On functionality remains flexible enough to allow specific SAP systems in your landscape to be included/excluded, on an as-needed basis. This granularity lets customers with many SAP systems decide which ones they want to enable Single-Sign on between.
      b) that SAP adheres to the industry standard public key pair mechanism, and conforms to that de facto standard.
      Hopefully I’ve simplified it enough for the users to see the flexibility possible.

    1. Former Member Post author
      Hi James,
      Because, in this case, the portal is using SAP Logon tickets as the authentication mechanism, all that happens when you move from one URL to the next is that the Portal (and therefore the underlying J2EE Engine) interrogates the Logon Ticket that you have embedded in your browser (it’s a cookie called MYSAPSSO2)and that you acquired when you first authenticated to one of the Portals. Because the Logon ticket is issued by a J2EE Engine that we have explicilty set up to trust in the previous exercise, it accepts that ticket and allows you immediate access.

      The platform on the client side, AND on the server side are irrelevant, since it does not use NTLM or any platform-specific authentication mechanism. All the authentication is done by SAP’s SSO through the Logon tickets.

    1. Former Member Post author
      Hi Ravinkath,
      This Single-Sign On procedure is completely Java-based, which means that it will work whether or not your system has an ABAP stack installed. In fact, the SSO mechanism is completely ignorant of whether ABAP is present or not. In addition, the first time I actually implemented this, it was between an EP 6.0 SP2 (Which means Web AS 6.20) and a NW04s BI system (7.00)

Leave a Reply