Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
Andre_Fischer
Product and Topic Expert
Product and Topic Expert

Single sign-on Technologies supported by the SAP NetWeaver Application Server as a Service Provider in Microsoft based environments

It has been two years that I published this blog. Since a few things have changed meanwhile I thought that it's time to provide an update. The main change is that SAP now offers SAP NetWeaver Single Sign-On as a solution for various SSO scenarios.

I wrote this blog because 2 years ago I had been asked by a colleague to provide some information for partners how they could achieve Single sign-on in a scenario where an ABAP system is accessed via Web-Dynpro and a .NET based Rich Client application that calls a web service in the ABAP backend. It turned out that though numerous publications have been published about this topic there seems still the need for a compact overview. Therefore I thought this would be a good topic for a blog. This statement still holds true :wink: .

I plan to add also some additional information how Single Sign-On can be achieved for SAP NetWeaver Gateway which is the product I am currently working for as a product manager.

If customers want to achieve Single sign-on to access the systems of their SAP System landscape they have different options. The options being available mainly depend on the underlying technology stack (ABAP or Java), the underlying NetWeaver release and the type of user agent (SAP NetWeaver Business Client, Browser, SAPGUI or Web Service Client) that is being used to access a SAP system. Let us first have a look which user agents can be used to consume services from a SAP NetWeaver Application Server:

The ABAP server offers the still widely used legacy type access through the RFC protocol (SAPGUI) or diag protocol used by external applications that are performing RFC calls. Both the SAP ABAP stack as well as the SAP Java stack support browser based access (SAP NetWeaver Business Client, WebDynpro, iViews, BSP pages and SAPGUI for HTML) and web service based access that can be called by any web service client.Customers that are running their client computers in a Microsoft Active Directory are usually looking for an option to leverage this infrastructure. Since “Single sign-on (SSO) is a method of access control that enables a user to authenticate once and gain access to the resources of multiple software systems” (Wikipedia) the ideal Single sign-on scenario they are looking for is shown in the following figure.

The "ideal" Single sign-on scenario

In this scenario a user logs on to his workstation using his Windows Domain credentials (1). During this process the user requests a Kerberos ticket that is issued by the Active Directory (AD) Domain Controller (DC) (2). This Kerberos ticket would then be used by any subsequent service call (3) and the user would be authenticated (4) by the SAP system without the need to enter username and password and would be able to retrieve the requested data (5).

In reality this scenario can usually not be used because the SAP NetWeaver Application server does support Kerberos for Single sign-on only for two scenarios. One is the browser based access to systems that are based on the Java stack that is configured to use the SPNego Login Module. The other is the use of a Kerberos based SNC solution for SAPGUI.

Since Kerberos tickets can thus not be used for authentication by all user agents, Single sign-on can only be achieved if we use an additional ticket issuing instance that itself accepts Kerberos tickets and that issues tokens that are accepted by the SAP NetWeaver Application Server instead. A “real”-World scenario would therefore look like this:

The "real-world" Single sign-on scenario

In this scenario a user logs on to his workstation using his Windows Domain credentials. During this process the user requests a Kerberos ticket that is issued by the Active Directory (AD) Domain Controller (DC) (1). This Kerberos ticket would then be used to perform an authenticated access to a ticket issuing system that issues other tokens (2) such as SAML tokens or SAP Logon Tickets. The user would then finally access the SAP System using this token without the need to enter username and password and would be able to retrieve the requested data (4).So what are the authentications options (tokens) that are supported by the SAP NetWeaver Web Application Server? Let us have a look at the authentication options that are listed in the following table:

SAP Stack

User Agent

X.509

Kerberos

SAP Logon Tickets

SAML 1.1

SAP NW AS ABAP

SAPGUI/RFC

Yes (1)

Yes(2)

Yes

No

Web Browser/ SAP NW BC

Yes

No(3a)

Yes

Yes(4)

.NET Web Service

Yes

No(3b)

Yes

Yes(5)

SAP NW AS Java

WebBrowser / SAP NW BC

Yes

Yes

Yes

Yes(6)

.NET Web Service

Yes

No(3b)

Yes

Yes(7)

  1. In this case one need to deploy SAP NetWeaver Single Sign-On or a 3rd party SNC product that is able to leverage the X.509 certificates from the user’s certificate store
  2. In this case the SAP NetWeaver Application Server ABAP has to run on Windows. See SAP Note 150380. If the SAP NetWeaver Application Server ABAP does not run on Windows one can achieve SSO by using SAP NetWeaver Single Sign-On.
  3. Though Kerberos Authentication is only supported for browser based access on the Java stack this technology can be leveraged indirectly to achieve Single sign-on as follows:
    (a) The authentication options offered by the Java stack can be leveraged for browser based access to a Web Application Server ABAP as well if users are redirected to a a Web Application Server Java in the event of a logon error. This scenario is described in the following SDN Whitepaper.
    (b)Kerberos tickets can only be used using a workaround described in the following Single Sign-On of Windows-based Web Service Clients using SAP Logon Tickets. A SAP Application Server based on the Java Stack has to be used as a ticket issuing instance
  4. SAML Browser / Artifact Profile as of NW 7.1 ABAP
  5. WS-Security SAML Token Profile (HoK) as of NW 7.01 SP1 and NW 7.11 SP1 ABAP
  6. SAML Browser / Artifact Profile as of NW 04 JAVA
  7. WS-Security SAML Token Profile (HoK) as of NW 7.11 SP1 JAVA

From the table above we can conclude that we have basically three options to achieve Single Sign-On.

The first option is to use SAP Logon Tickets. This works well for browser based access where a SAP NetWeaver Portal is used that is configured to support Integrated Windows Authentication. Such a portal can also act as the ticket issuing instance for SAP Logon Tickets for .NET Web Service Clients though this scenario does not work out of the box using standard WCF bindings since the .NET client has to perform an additional service call to the SAP Logon Ticket issuing system. This scenario is described Single Sign-On of Windows-based Web Service Clients using SAP Logon Tickets in SDN.

The second option is to use SAML tokens. SAML tokens can be used for Single-Sign-On in browser based scenarios as well as in Web Services based scenarios. If a user agent in a SAML based scenario tries to access a SAP resource it will automatically being told to access the SAML ticket issuing instance that can be configured to accept Kerberos tickets. Since the Identity Providers (IdP) and Secure Token Service (STS) servers of both vendors are not available yet this scenario will be adopted once these infrastructure components are available.

The third option is the usage of X.509 certificates. These can automatically be issued to end users and distributed to their computers with the help of Microsoft Active Directory. Using automatic enrollment of user certificates Microsoft Active Directory provides a quick and simple way to issue X.509 certificates to users after they have successfully authenticated against Microsoft Active Directory. This scenario has been described in the SAP TechEd session SIM208.

In addtion to my TechEd session I have provided more details in the following Single Sign-On for SAP NetWeaver Leveraging X.509 Certificate Auto Enrollment in Microsoft Active Di.... A solution that does not require the setup of a PKI infrastructure is the usage of SAP NetWeaver Single Sign-On . In this case the secure login server issues a client certificate and pushes it to the Windows Certificate Store. These certificates can also be shortlived and thus do not require the usage of a Certificate Revocation List.

A recommendation which technology one should choose in a specific scenario is out of the scope of this article. There are Pro’s and Con’s with all of them. Therefore I would like to point you to some articles that describe the topic in more depth. 

52 Comments