Single Sign-On (SSO)

The main goal of single sign-on is to get rid of multiple passwords. These passwords are usually easy to guess and can pose a security risk.

 

Single sign-on (SSO) is the most efficient way to facilitate user authentication in an enterprise.

 

A nice analogy to SSO is the process of a traveler crossing a boundary, for example, a German citizen who is visiting the U.S. The German citizen has received a passport from the German authorities by presenting his ID card to them.

 

Because the U.S. Immigration office trusts the German authorities, they accept the passport that the German citizen presents at the arrival to the U.S. authorities.

 

 

Single Sign-On Fundamentals

The identity provider (IdP) has a trust relationship with the Service Provider (SP).

 

Looking at our analogy of cross-boundary travel, the U.S. authorities are playing the role of the service provider; the German authorities act as the identity provider.

 

Based on some initial authentication (in our analogy, the ID card), the user gets a security token, which is presented to the consuming application that plays the role of the service provider.

 

Based on the (valid) security token presented, the user is granted access to the SAP Gateway service.

 

Note: In contrast to the cross-boundary scenario, the end-user is not forced to present the security token manually to the service provider. This is done automatically by the browser or consuming application.

 

 

Authentication Options

The OData consumer in an end-user scenario can be any SAPUI5, desktop application, or mobile application. In addition, the consumer can be based on server-to-server communication, for example, cloud application, social network, or server-side code.

 

In the figure, the connectivity layer contains any solution that secures the access of external consumers. Typically this is a firewall and/or a reverse proxy.

 

The next layer is the SAP Gateway hub, which is responsible for the following:

• OData support
• Authentication
• Protection of business function from potential malicious attacks
• Authorization checks on service level and routing

 

The SAP Business Suite back end translates OData requests into corresponding RFC calls that finally call the service implementation in the data provider class. In the back end, the application-specific authorizations of the user are checked.

 

 

HTTP Request —> OData Operation —> ABAP Method

Any OData consumer from the outside world can connect to SAP Gateway by using either HTTP or HTTPS. When this happens, the HTTP request first enters the HTTP framework on the hub (1 in the figure). There it is authenticated using the authentication options provided by the SAP NetWeaver ABAP application server.

 

The gateway hub framework finally (3) calls the gateway back-end framework via an RFC call that uses a trusted RFC connection.

 

The SSO from the hub to the back end is based on SAP assertion tickets that contain the username of the user currently logged on to the SAP Gateway hub system. Because of this, the consumer of an OData service has to have a named user in the gateway hub as well as in the gateway back end with the same user ID.

 

To achieve SSO end-to-end for the consumer, a seamless logon at the gateway hub must be achieved. Therefore it is important to be aware of the authentication options that are offered for OData services by the SAP ABAP application server.

 

 

Authentication Options Supported

The SAP Gateway hub is based on the SAP NetWeaver ABAP platform and supports the following authentication options:

• SAML 2.0 browser SSO
  • Requires an additional system — an Identity Provider (IdP) — such as SAP NetWeaver SSO or MS ADFS
  • Clients such as a desktop or mobile applications that do not run in a browser must behave “like a browser” when handling HTTP redirects, forms, and cookie processing
• 509 client certificate
  • 1
  • 2
  • 3