Our experience with NWSSO

[Former Member]

Hello Everybody. This is our first sdn blog , so please be so kind . In this blog, we try to share our experience in the last one year we (I and my colleague from the SAP security team Subramaniam Iyer)  have worked with the NW SSO 1.0 and 2.0 products for implementing SSO to SAP ABAP systems. We will not delve into technical details for setting up Single Sign On to SAP as the folks from SAP have already done a fantastic job in this aspect.  (I have anyways tried to put together a few blogs that I have used for reference quite a lot in the recent past)

SAP Netweaver Single Sign On as you might know is the new name for SECUDE (which SAP has purchased and rebranded about two years ago). SECUDE has been in existence since early 1990s and has been one of the very few third party companies whose library was able to interface well with the SNC ABAP layer to provide single sign on and encryption for SAP releases beginning as early as 4.6

In this blog we try to focus more on the surrounding areas of setting up a Single Sign On Project within your organization. The guides from SAP for Secure Login Library, Secure Login Client and Secure Login Server are pretty exhaustive and have all the information that administrators would need to do the installation/configuration for setting up SSO. However, there are a few missing pieces that we had to put together when we started setting up our SAP systems with SSO. We have listed some of them below

1)      SSO Compatible SAP Systems: The first very common question that comes from the management is whether this product can provide SSO for all the applications in the SAP landscape. Well there are solutions for SSO to pretty much most of the SAP systems today but still there are a few SAP products that don’t fit these criteria. For E.g. SAP MDM thick clients, SAP CLM contexts etc. So the first step in such a project would be to be to ensure which systems within your landscape can be “completely” covered under the umbrella of NW SSO. It would be help to make a list of SAP systems in your landscape something like below:

2)      Web applications: Next task was to identify web applications for ABAP webdynpro/bsp or rather anything serviced by the ABAP ICM.

Recently with NW 731 SP7, SAP has come up with “SPNego” based SSO for even the web layer on ABAP and there is a Downport note 1798979 for lower releases as well. This is in line with the SPNego setup we have already today for the java stack. However if your SAP release does not match the ones in the SAP note, it’s not end of the worldThere are many options again. Some of them are (in my order of preference )

-          SAML: To use SAML 2.0 your SAP system needs to have a certain release level (702 and above for example)

-          Certificates – SSO using X.509 certificates for web access is an age old solution which still works today. (refer next section on SSO technology)

-          Redirect – Refer to the famous blogs from Holger Bruchelt which talks about redirect based solutions.

3)      Choice of Technology:  The product offers solutions based upon Kerberos and X.509 certificates for SAP GUI SSO.  Choose the one that fits best in your infrastructure, which depends on many factors . If you want to use X.509 client certificates for SSO then by installing secure login server (SLS) you have the option of generating short lived certificates on the fly. This could be an option if you don’t have your own PKI, but if you have your PKI then you could leverage it for SSO just by installing SLC and SLL. Kerberos mechanism on the other hand relies on the AD domain setup and the trust relationship amongst them.

A few things that you need to check if you want to use X.509 for SAPGUI SSO:

1.     Do all your SAP users have a client certificate issued by your PKI?
2.     The PKI registration process at your customer
3.     Auto-enrolment of client-authentication certificates possible?
4.     If the above process is complicated, could it be compliant within the organization to  use a generated CA using SLS to issue client certificates?
5.     Which attribute in the client certificate would uniquely identify a user?

A few things that you need to check if you want to use Kerberos for SAPGUI SSO:

1.        What is the AD domain setup  within the organization. Probably you need to talk to your AD administrators to get this information.
2.        Is it a multi domain setup? If so, is there a transitive trust relationship ?

4)      SNC name setup - automation:  Global companies today in general have a multi domain setup. But when it comes to SAP, it is not possible to determine based on the SAP user id  which domain the user belongs to . To have SSO , we need to maintain the user’s SNC name in SU01 with the appropriate domain extension.  You could check within your organization for any such repository of information which stores the users domain information. E.g. A Corporate Directory or Database etc. One could then write an interface to this central repository from your ABAP system and use the program behind  the standard mass maintenance transaction SNC1 (RSUSR300) for user mapping uses a fixed prefix and suffix for maintaining the user SNC names in SU01.

If you use SAP GRC for user provisioning, then it can also be used to provision the SNC names for the new accounts during creation. Refer to SAP GRC configuration guide for details.

5)      SNC Name Security:  Once you achieved SSO, a  major concern  would be to ensure that the SNC names were not manually tweaked by end users. Remember that once SSO is switched on, everything is controlled by your SNC name. So if I could go to any user master record and change the SNC name to mine, then login to SAP as that user which is a BIG risk. For this SAP has very recently released an SAP note 1882254 to control the authorization for maintaining SNC names.

6)      Electronic Signatures (21CFRPart11): Is your product regulated by FDA? Do you have electronic signatures mandated for certain SAP transactions? If you are not sure whether such transactions are used in your SAP system, check the security audit logs (SM20) for logon type=U and this should provide you the user id and the transaction code that was used for re-authentication. If so then users executing these transactions would still need to remember their SAP passwords.

SAP has now come up with a solution in NW SSO 2.0 with an SAP Note 1862814. After applying this note and some custom development you can determine the authentication method that was used by the user while logging on to SAP and thereby authenticate on the digital signature windows either based on SAP password or the windows password.

7)      Authentication Logs: Once SSO is implemented, one would be interested to measure how many logins are happening with SSO and how many users still are using SAP passwords.  The security audit logs normally record the type of logon that was used to access the SAP server. In the past this was not a concern because all dialog logons used only one authentication method i.e. SAP password. NW version 700 upwards AND Kernel release 721 upwards, SAP provides a feature for recording the authentication method that was used in the security audit log. SAP Note 1789518 may be required on NW 700 to modify the message text. Method=S is denotes SSO and Method=P denotes authentication using SAP password.

😎      GUI rollout: Though the basis and security teams could switch on SSO on the system at a planned time,  an end-user might not be able to use it till the time his GUI settings for that system are not adapted appropriately. This can be a challenge to get all users GUI updated at the same time.  One can avoid asking end users to adapt the changes in the GUI by editing the saplogon.ini file centrally (you need to already have a centrally managed GUI distribution setup) and distributing it to the user pc’s,

Hope this helps ..... 🙂

Thank you Sub for your creative contributions (as always) to this article

Reference links:

http://scn.sap.com/community/netweaver-sso

http://scn.sap.com/docs/DOC-40178

http://scn.sap.com/people/holger.bruchelt/blog/2010/01/11/single-sign-on-to-bsp-pages