Typical scenario: you have a Portal system (Java-based) and an ECC system (ABAP-based). You want your end users to access ECC content via Portal, without having a new authentication being required.


By reading SAP note 1257108 [Collective Note: Analyzing issues with Single Sign On (SSO)] you realize that there are several SSO possibilities. This blog will talk about the use of the SM50 logon trace to verify logon tickets (MYSAPSSO2 cookie) for SSO purposes.

Configuration made easy

In order to establish a trusted relationship between the Portal and the ECC system is quite easy.

In the ECC, all you need is execute transaction code STRUSTSSO2, import the certificate from the Portal into the Certificate List of the System PSE (usually used for SSO based on logon tickets) and adjust the ACL:

STRUSTSSO2.jpg

In the Portal, use the Netweaver Administrator tool to access the “Trusted Systems” application, in the “Configuration” tab. This will allow you to a) import the certificate from the ECC system or b) logon to the ECC system, so the Portal reads the certificate from the ECC:

Trusted Systems.jpg

Test made easy

How to test if the SSO is working? I used the Portal URL (http://<FQDN>:<port>/irj/portal) to create a new System (“System Administration” -> “System Landscape” path). There is a wizard to walk you through the steps.

Once I have the new system created, I just went to the “Content Administration” area and created a transaction iView, using the recently created system as the target. I called transaction SU01, just for testing purposes. The goal here is having a preview of the transaction, without the ECC asking for credentials.

Test: web browser side

I logged on to the Portal, using my Portal ID and password. I accessed, inside the “Portal Content” folder, the iView I have created. By right clicking on the node and clicking on “Preview”:

Portal - SU01 test.jpg

The transaction code SU01 was displayed:

Portal - SU01 test 02.jpg

While playing with the browser, I recorded the HTTP traffic using Fiddler tool. Inside the trace file, you should be able to find one cookie called MYSAPSSO2. It contains the actual logon ticket that will grant you access to the transaction code:

Fiddler test.jpg

You can also see that cookie SAPWP_active=1 was sent, telling the ECC that the Portal is active.

As you were able to see SU01 running, the SSO worked as expected. If, however, you were not able to see SU01 and you saw another cookie in the list: sap-ssolist, then you found a reason for the SSO failed. sap-ssolist is a cookie that can be decoded by a Base 64 parser: it will show you the system ID, the client number and the server name that does not accept logon tickets from the Portal you have used.

Test: ECC side, a.k.a. SM50 logon trace

While the web browser test was being executed, the SM50 logon trace was also recorded, by following the steps from my first blog on logon trace.

These are the entries recorded in dev_w2, related to this test:


“…

N DoW MoY dd hh:mm:ss yyyy

N  dy_signi_ext: LOGON TICKET logon (client ccc)

N  mySAPUnwrapTicket: was called.

N  HmskiFindTicketInCache: Trying to find logon ticket in ticket cache.

N  HmskiFindTicketInCache: Try to find ticket with cache key: ccc:ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ .

N  HmskiFindTicketInCache: Couldn’t find ticket in ticket cache.

N  mySAP: Got the following SSF Params:

N         DN      =CN=XXX

N         EncrAlg =DES-CBC

N         Format  =PKCS7

N         Toolkit =SAPSECULIB

N         HashAlg =SHA1

N         Profile =C:\usr\sap\XXX\DVEBMGS00\sec\SAPSYS.pse

N         PAB     =C:\usr\sap\XXX\DVEBMGS00\sec\SAPSYS.pse

…”


Here we can see that the entries are related to a logon ticket logon, on client “ccc”. We can also find the PSE used to store the certificates, SAPSYS.pse (System PSE).


“…

N  Got the codepage 4103.

Got ticket (head) AjExMDAgA         Ww  S gx  T    M4g  E   hc  lj. Length = 484.

N  Convert ticket content from SAP_CODEPAGE >1100< to >4103<

N  MskiValidateTicket returns 0.

N  Got content client = 000.

Got content sysid = ZZZ     .

N  Got date yyyymmddhhmm from ticket.

N  Cur time = yyyymmddhh18.

N  Computing validity in hours.

N  Computing validity in minutes.

N  CurTime_t = 1460495880, CreTime_t = 1460494860

N  validity: 28800, difference:   1020.000.

…”


The entries above show a small part of the logon ticket (head only), as the logon trace was recorded using level 2 (with level 3 trace, the entire logon ticket would be dumped into the dev_w2 trace file). We also found the system that originated the cookie (ZZZ). As the logon tickets have a validity (usually 8 hours), the system will calculate the difference between the time the logon ticket was created with the current time. If the difference exceeds the limit, the ticket cannot be used for authentication.


“…

N  Ticket is without recipient information.

N  Ticket contains no RFC Payload info.

N  Ticket contains no language info.

N  HmskiInsertTicketInCache: Trying to insert logon ticket in ticket cache.

N  HmskiInsertTicketInCache: Inserted new ticket into logon ticket cache with cache key: ccc: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ .

N  HmskiInsertTicketInCache: Inserted new ticket into logon ticket cache with cache info: <USER>=userID     ,<CLIENT>=ccc,<LANGUAGE

N  mySAPUnwrapTicket returns 0.

…”


The ticket is then inserted into the ticket cache for future reference.


“…

N  DyISigni: client=ccc, user=userID     , lang=E, access=H, auth=T

N  usrexist: effective authentification method: SAP logon ticket

N  Get_RefUser(ccc,userID) =>

N  password logon is generally enabled (default)

N  productive password is still valid (expiration period=0 / days gone=0)

N  password change not required (expiration period=0 / days gone=705)

N  usrexist: update logon timestamp (M)

N  save user time zone = >BRAZIL< into spa

N  DyISignR: return code=0 (see note 320991)

…”


Finally, the system checks the user ID from the logon ticket with the existent in the system. The return code equal 0 indicates that the SSO based on the logon ticket worked as expected.

If another access is made, then the logon trace will show:


“…

N  HmskiFindTicketInCache: Logon ticket found in ticket cache.

N  HmskiFindTicketInCache: Ticket information in ticket cache is: <USER>=userID ,<CLIENT>=ccc,<LANGUAGE>=

N  HmskiFindTicketInCache: Ticket information in ticket cache read successfully.

N  DyISigni: client=ccc, user=userID     , lang=E, access=H, auth=T

N  usrexist: effective authentification method: SAP logon ticket

…”


Here the logon ticket was found in the cache, so it is not necessary to the system to decode the logon ticket again.

Additional information

If you have a particular scenario that you would like to discuss, then use the comments and I will improve the blog to address your case.

Stay tuned for my next logon trace blog, involving SSO with X.509 client certificates.

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply