Sean Shea-Schrier

Single Sign-On Challenge in an SAP Retail Environment

Blog Post created by Sean Shea-Schrier on Sep 23, 2015

This blog post describes a unique challenge that my team faced—achieving single sign-on in a retail environment, in which many people work on the same device—and how we solved that challenge.

 

One of oXya’s customers in Canada is a large retailer in the fashion sector, with ~ 500 stores all across Canada, and thousands of SAP users working in these stores. This customer receives a full SAP hosting service from oXya, meaning their SAP environment is managed by oXya’s team of SAP experts, and their SAP environment runs on Hitachi UCP Pro hardware at our datacenter. We also host all of their non-SAP infrastructure, also on Hitachi hardware.

 

This retail customer uses SAP in all of their stores. The cashiers in the stores, at the point of sale, use SAP in order to manage the store’s inventory, requisitions and other activities, and also for accessing non-SAP applications such as their email, time sheets, and more. The customer asked us to find a way to provide its users with a single sign-on experience for all the applications they use in the store.

 

 

The Technical Challenge

 

To explain the challenge, let’s first cover a more “standard” SAP environment. In such environment, when a user logs onto her Windows computer and onto a specific domain, she gets a Kerberos token which serves as evidence that she logged onto that domain. Many applications perform single sign-on this way—they trust that the Windows computer is logged onto the domain, and thus perform single sign-on to the application. SAP operates this way, and so do an endless number of other applications.

mannequins-811144_640.jpg

 

However, everything works differently in a retail (or kiosk) environment. In a retail store, the user does not log on and off a computer, every time she goes to work on the cash register. Instead, she logs on and off the actual application. As a result, no authentication is done at the actual workstation (and the same applies to any environment, in which the user does not log directly onto a computer, or to some type of a Point of Sale (POS) device).

 

Our challenge, then, was to find a way to perform a single sign-on and use the Active Directory authentication, yet do so without having the user actually logging onto their PC with their Active Directory account.

 

In SAP terms, the question that we faced was—how can you perform a single sign-on with an SAP ABAP application, like SAP Fiori or SAP NetWeaver Business Client (NWBC), yet be able to do it in a simple way, for example through the browser, without complicating the user’s life?

 

This challenge may sound simple, but it is actually quite complicated. Both Fiori and NWBC are based on SAP ABAP Webdynpro, which has been around for a long time. An SAP ABAP Webdynpro application can perform single sign-on using modern technologies like NetWeaver SSO. However, what you can’t get around with ABAP based systems is the fact that the user has to have a user account in the ABAP User Store. This means that you have to create user accounts for the user to access Fiori or NWBC which will provide the needed authorization. In the case of Fiori, you need to have two user accounts – one user in the NetWeaver Gateway system (where you access the Fiori applications), and a second user for the backend SAP system, meaning ERP or whatever system is in the back (usually SAP ERP).

 

In other words, these users have multiple user accounts with multiple passwords, and it wasn’t possible to synchronize these passwords. And as a reminder, the users in the store do not operate only within the SAP environment, but also need access to other applications, which meant even more user accounts and passwords for each user.

 

The customer asked us to find a way to authenticate against Active Directory for all of these applications—both SAP and non-SAP. They wanted a method of authentication that is seamless across all applications, using just a single username and password per each user.

 

 

The solution: SAML 2.0 and ADFS

draft-saml-logo-03.png

 

The solution we put together is based on combining the Security Assertion Markup Language 2.0 (SAML 2.0) protocol, together with Active Directory Federation Services (ADFS), to achieve the single sign-on we needed. This solution, based on combining existing technologies, is not commonly used nor widely known in the SAP market.

 

In fact, SAP has excellent integration with SAML 2.0, which is a well-known standard for single sign-on and authentication that almost every application supports. By combining it with Microsoft’s ADFS, we enabled the users to achieve a single sign-on, despite all the limitations described above.

 

Here’s how the solution works: all a user needs to do is to sign onto any SAML Application via the browser that uses ADFS as its identify provider. It doesn’t matter what device she’s using, meaning she can perform this application sign-in via a tablet, PC, or even iOS and Android devices; she does not need to authenticate in any special manner to the device nor to the computer. At this point the user has an SAML token, and will get automated authentication to any other application using ADFS as its SAADFS.pngML Identify Provider.

 

In the case of  SAP applications like NWBC and Fiori, while attempting to logon the user is redirected to ADFS which allows her to enter her Active Directory username and password, and authenticate. From there, the user is redirected back to the Fiori or NWBC application, and is logged on automatically.

 

This process is seamless to the users, and does not require anything except for entering the Active Directory credentials that they are used too. The user essentially has one username and one password, and doesn’t have to worry about managing different accounts and different environments.

 

The above solution, which the customer is very happy with, works across all of the different SAP applications, as well as all of the customer’s other, non-SAP applications. This results in very good experience to the users, enabling them a way to authenticate across all of their applications—SAP and non-SAP—saving them a tremendous amount of headaches, and of course dramatically lowering the number of helpdesk calls from the stores.

 

 

 

Sean Shea-Schrier is an oXya Service Delivery Manager, based in oXya’s Montreal, Canada branch. Sean is a veteran SAP expert with more than 10 years’ experience as SAP Admin and SAP consultant (both Basis and architect). Sean joined oXya more than 2 years ago to help build the Canadian team and onboard customers. oXya was acquired in early 2015 by Hitachi Data Systems.

Outcomes