Java stack Single Sign On issues

Introduction

This blog is part of the #SAPADMIN launch, an idea that was launched to have a space for system administrators on SCN. You can read the leading blog here. Martin English made a dummy concept page which you can check out. Also check today’s blogs for hash tag #SAPADMIN and check twitter for tweets that are tagged with #SAPADMIN. You can find the idea on idea place here.

Random SSO issues in connections

I have been receiving a number of questions on SSO issues and I was also involved in some problem teams to find the root cause of a certain number of problems. When it comes down to Single Sign On it can be a real hassle to find the root cause as it can be very diverse. Lots of technology used, different methods, different configurations in place and so on.

Sometimes you are looking at multiple problems at the same time, they seem to be connected at first but often they are not. One of those common issues are random connection problems when JCO destinations are used. I have seen this a lot lately is that the recommendations from SAP are not commonly known.

SAP Note 1166904

This is the recommendation: SAP Note 1166904 - Assertion ticket SSO for Web Dynpro Java JCO destinations.

Prerequisites

1. You are using one of the following NetWeaver releases / SPs:
   NW04s SP16 (or later)
   NW04s EhP1 (or later)
   NW7.1 EhP1 (or later)
2. The SLD to store Web Dynpro JCO destinations has SLD content / CIM model update from January 2008 or later, cf. note 669669 for details.

Prerequisites are an extract from SAP Note 1166904

Netweaver releases / SPs

The releases are pretty much in big lines so you shouldn’t have a problem detecting what release you are on. If you do have issues detecting the proper version, post in the comments so we can help you out.

SLD version

Picture 1.1

To check the version of the SLD content / CIM model you can have a look at the SLD details by logging onto the SLD using URL http://<host>.<domain>:5<instance number>00/sld. There click on Administration (see picture 1.1).

Picture 1.2

Then click on Details which you can find under header Server (see picture 1.2).

Picture 1.3

On the Details page click on the tab data (see picture 1.3).

Picture 1.4

You will now be able to see the Model Version 1.6.9 in picture 1.4 and the SAP CR Content Version SAP_CR 6.6 (10/06/2010) in picture 1.4. Make sure the version matches the prerequisites recommendation for SAP Note 1166904.

Updating the SLD

You can find instructions how to properly update (level by level) the SLD in SAP Note 669669 - Updating the SAP Component Repository in the SLD. It’s important to follow the correct sequence of packages described in SAP Note 669669 when updating the SLD.

JCo Recommendation

Picture 1.5

To take a look at the JCO destinations that are configured go to the index page of your Java stackhttp://<host>.<domain>:5<instance number>00/index.html and click on Web Dynpro Tools (see picture 1.5).

Picture 1.6

A new screen will open, there you click on Content Administrator (see picture 1.6).

Picture 1.7

This will take you to the Web Dynpro Content Administration page shown in picture 1.7. Click on the button Maintain JCo Destinations.

Picture 1.8

You will then get a list of JCo destinations that are available on your Java stack. By default SAP provides a number of JCo’s that can be enabled for specific scenarios. The JCo destinations in picture 1.8 that have a red status are not in use. Navigate down the list (button on bottom of table) to your active JCo destinations.

Picture 1.9

In picture 1.9 you can see two activate JCo Destinations, SAP_R3_Financials and SAP_R3_Financials_MetaData. For a MetaData JCo destination you have to use user/password authentication and not SSO. The SAP_R3_Financials is using SSO, let’s take a look.

Picture 2.0

Picture 2.1

To check the settings of the JCo Destination, you can click on the Preview button (see picture 2.0), the line will be selected and the settings will appear below the table of the JCo destinations (see picture 2.1).

Once you the settings are visible, click on the Security tab (see picture 2.1) and check the value of the setting User Definition. You can see in picture 2.1 that useAssertionTicket is set which is the correct one.

I often see useSSO defined while it is actually an older method and not recommended anymore. You could notice random connection issues on those JCO destinations and complicated at random SSO issues occuring. So I strongly suggest if you are on a Netweaver release that matches the prerequisites to update your SLD to the latest available version and changing all the JCo destinations that are configured with useSSO intouseAssertionTicket.

Timeouts and popups

Another type of problem that I bumped into regularly is that pop-ups appear requestion user password for end-users while Single Sign On is enabled. Your SAP Portal for example can be using the regular network user of your end-user to logon to SAP using Single Sign On. The end-user doesn’t see any of this as he might just open a browser and land on the intranet page which is running on SAP Portal for example.

What happens sometimes is that end-users do get a pop-up all of a sudden and it confuses them of course since they never have to logon, they don’t know what user they should use and soon they log a incident ticket and once it happens multiple times or with multiple users you are looking at a problem.

One of the most important SAP notes which gives instructions to avoid these kind of problems is SAP Note 842635 - Session Management for Web Dynpro Applications.

Standard settings often seen

First off I will quickly go through what I see most of the times which are standard settings, I don’t know if this has been addressed yet by SAP in new releases but more on that later on in the blog.

SAP Netweaver 7.0x

The settings described below are for SAP Netweaver 7.0x. For newer releases you can find the values in the NWA (Netweaver Administrator).

Security session timeout

Picture 2.2

In the visual administrator under tab Global Configuration and tab Server expand Services (not visible in picture) and click on the service Security Provider (see picture 2.2). You will then see the parameters on the right pane of the visual administrator where you can also change the value.

Parameter: SessionExpirationPeriod

In milliseconds
Current value: 100000000
Recommended value: 57600000

In hours
Current value: 27
Recommended value: 16

SSO ticket timeout

Picture 2.3

In the visual administration under tab Cluster click on a Server <node> then expand Services and click on service Configuration Adapter (see picture 2.3).

Picture 2.4

In the right pane expand the map cluster_data -> server -> cfg -> services -> Propertysheet com.sap. security.core.ume.service' (see picture 2.4).

If you wish to adjust a value in such a property sheet click on the pencil in the toolbar on the right pane to go into edit mode. Next double-click the property sheet to open it.

Picture 2.5

To adjust login.ticket.lifetime click on the parameter value field (where you see 16 in picture 2.5). The crossed checkbox means a custom value is active for this parameter.

Parameter: login.ticket_lifetime

In hours
Current value: 8
Recommended value: 16

Web Dynpro applications timeout

Picture 2.6

In the visual administration under tab Cluster click on a Server <node> then expand Services and click on service Configuration Adapter.

In the right pane expand WebDynpro -> sap.com -> tc~wd~dispwda -> Propertysheet default

Picture 2.7

Depending if you are still in change mode or not, switch to change using the pencil and open the propertysheet. The expiration time of default WebDynpro applications can be set to a value the business finds sensible depending on how long certain applications should stay alive before expiring. Custom built applications can have their own expiration settings.

Parameter: DefaultExpirationTime

In seconds
Current value: 3600
Recommended value: depends on business needs (example is 2 hours but can as well be 16 hours)

In hours
Current value: 1
Recommended value: depends on business needs (example is 2 hours but can as well be 16 hours)

Recommendation

It’s recommended to at least match the security session timeout and the SSO ticket timeout. A good value is a long work day (16 hours for example). The Web Dynpro application timeout has to be set to a sensible value.

If the session timeout is much larger than the SSO ticket timeout you can encounter situations where the end-users suddenly gets a pop-up requesting user/password. This brings confusion and gives the feeling the application is not working properly as the end-user is used to not getting any pop-ups or any request to logon.

I suggest you also read through SAP note 842635 for other tips such as disabling the browsers pop-up blocker. The two main SAP notes referred to in this blog are not connected as related notes although for me they are connected, you will want to have both recommendations in place to avoid SSO issues.