Authentication

Access control, normally based on the identity of the user who requests access to a resource, is essential to effective security. Our Launchpad makes use of different authentication methods within SAP.

Connection

Set up basic connections to your mobile client

Connection Settings

Server URL: To connect to Neptune, the URL you use will depend on whether you are connecting through SAP Mobile Platform or the Neptune RESTful internet service on an ABAP web application server. For the Neptune RESTful internet service, provide the internet service URL of the SAP ABAP Web Application Server where Neptune is installed. You can use the name of the main Neptune internet service node (named 'neptune') or a sub-node. Internet services can be viewed using transaction 'SICF' in the SAP ABAP backend. For SAP Mobile Platform or Hana Cloud Platform, specify the URL of your on-premise or cloud SMP server.

Android Security

Allow HTTP Cleartext Traffic: A best practice is to always use HTTPS for secure communication, but in the case that you still prefer to use HTTP, there is an option to disable HTTPS and use only HTTP.

SAP-Client

Configuration Client & Default Logon Client: Client number of the SAP system

Language

Default Language: Neptune provides different options for setting the language in the login screen and applications. If "SAP User Default and/or Browser Default" is selected, Neptune will try to use the language set in the user’s browser for the login screen, and apply the language set in the user’s SU3 profile after login. If a default language is chosen, it will be used for the login screen, Launchpad, and applications. However, if the URL parameter 'sap-language' is detected, it will override any other language settings. More information can be found in the Language Documentation.
Fallback Language: Select a fallback language to be used if the user’s browser does not identify with any of the installed or chosen languages. Read more in the Language Documentation.
Allow User to choose SAP-Language: The user will be allowed to choose between languages that are installed on the SAP server.

ICF Subnode

To customize logon handling in Neptune mobile client, you can create a dedicated ICF subnode under the /neptune/ node using transaction SICF. For example, you can use the SDK ICF node from the template system.

/neptune/sdk

To handle mobile logon the /neptune/native ICF node, must be copied and pasted into your subnode.

/neptune/sdk/native

mobile client auth sdk

To allow public access you set password and username in your subnode, use a communication user.

mobile client auth username

Two Factor Authentication

Two-factor authentication is an optional security tool that requires users to authenticate with an additional key during the logon process. The key is typically a 6-digit code delivered to the user’s email address specified in the SAP User Master Record.

You can customize the function module that handles the delivery of the activation code using your own function module, based on the template provided by Neptune’s standard function module, /NEPTUNE/TWO_FACTOR_SEND.

Reauthentication

Enable: Enabling PIN Code allows users to sign in using a passcode instead of their SAP login credentials after the initial login to the SAP backend running Neptune. The user credentials are encrypted and stored locally on the device, so authentication is only required once. This is a more user-friendly option as users do not have to enter their SAP login credentials each time they use the application. To implement this, the NEPTUNE_LAUNCHPAD_PINCODE application can be used as a reference.
PIN Code Tries: You can set the number of login attempts a user has before their locally encrypted credentials are wiped and they are required to enter their SAP login credentials again.
PIN Code Length: The Pin code can consist of either 4, 6 or 8 digits.
Autolock after inactivity: Number of seconds to wait -with no user action- before the mobile app is automatically locked.
Use Complex pincode: If you want to increase security, you can enforce complex pin codes for your users. When this setting is enabled, pin codes cannot include the same number twice and numbers cannot be sequential.
Enable Fingerprint ID, Touch ID & Face ID: Allows the user use their fingerprint to unlock their app instead of the pin code. This also applies for Facial recognition as an authentication method for devices that support this.
Remember credentials: This setting allows reauthentication without any password protection. Removing this layer of security is ideal if the devices are enrolled in an MDM solution, and security is already handled (i.e. the user must authenticate before opening the Neptune app).

Microsoft Entra ID

The Microsoft Entra ID setup for a mobile client is pretty easy, just fill in the tenant identification. The hard part is to set up Microsoft Entra ID in your SAP system. Read here how to do that at Single sign on to Neptune by integrating Azure AD setup in SAP

SAP Enterprise Portal

Enterprise Portal system is the system that will issue an SSO2 token. A Single Sign-On Token is one of the authentication mechanisms the SAP ABAP web application server uses to grant a user access. It is a cookie that is transported together with the HTTP request made by hybrid applications on mobile devices.

Where set up, the Portal system is configured to be trusted by all other systems in a customer’s SAP system landscape. This is why a Portal SSO2 token will be accepted by all ABAP back-ends that run Neptune and hence don’t require re-authentication.

URL Logon: URL of the logon for example: https://hostname:port/irj/portal/ticketissuer
URL Logoff: URL of the logoff for example: https://<hostname>:<port>/irj/servlet/prt/portal/prtroot/com.sap.portal.navigation.masthead.LogOutComponent?logout_submit=true . Navigation to the logoff URL at runtime will perform a standard portal logoff which leads to removal of SSO2 cookies from the application’s browser session.
OTP Header: Header for One-Time-Password.
OTP Value: Value for One-Time-Password.

SMP/SCPMS

SAP Mobile Platform (SMP) is an application development, mobile application management and mobile device management, using the Afaria platform that accelerates the delivery of secure, scalable mobile applications.

Enable: For SMP/SCPms setup, you can use the connection URL of your Cloud or On-Premise versions. This connection URL should be entered in the URL field under the Connection tab.
SMP Application: The SMP Application is the name of an application that is set up on SAP Mobile Platform for the sake of authentication. Cookies returned by interacting with the SAP Mobile Platform at runtime will allow Neptune Applications to consume SMP’s RESTful layer for backend server interaction.
Enable Captcha: Enable Captcha to enforce security for your application in preventing Denial of Service (DOS) attacks. While onboarding, the server will send a CAPTCHA text that has to be keyed-in from the client and upon verification, only onboarding will be successful. If CAPTCHA text is not sent back from the client, the application connection will be marked as 'pending for validation' in the server.
Enable Principal Propagation: Enable Principal Propagation authentication is only applicable if you want to connect to your on-premise SAP system via the Cloud Connector. The connectivity tool provides a secure way of forwarding the identity of an on-demand user to the Cloud Connector, and from there to the back end of the relevant on-premise system. It uses Security Assertion Markup Language (SAML) tokens as the exchange format for the user information. User mapping takes place in the back end and, in this way, either the token is forwarded directly to the back end or an X.509 certificate is generated, which is then used in the backend.

ADFS

Active Directory Federation Services can also be used as an identity provider for Single Sign-on to your SAP system.

URL Logon: URL where authentication with ADFS is done.
URL Logoff: URL where logoff with ADFS is done.
Username Field: field of the HTML logon form for entering the username.
Password Field: field of the HTML logon form for entering the password.
Domain: Enter domain without slash.
Name: For use in multi ADFS setup. This name will be displayed in the users drop-down menu list to choose a domain and is only used as an identifier to set the corresponding domain from the Multi ADFS Setup table record. You can find more details on ADFS configuration in this article .

OKTA

To configure Neptune Authentication with OKTA, you need to set up a new Authentication Provider in Neptune Management Cockpit. In the Authentication Provider settings, you will need to provide the appropriate information, such as the OKTA domain, client ID, and client secret.

Once the Authentication Provider is set up, you can enable it for your Neptune applications. When users access the application, they will be redirected to the OKTA login page and after successful authentication, the user will be redirected back to the Neptune application with a SAML token. Neptune will use this token to authenticate the user and grant access to the application.

Note that you can also use this for other scenarios like OKTA → SAP BTP→ SAP On-Prem

URL Logon: Point this url to the app you created in OKTA. Will look like this:

https://<yourcompany>.okta.com/oktaapphash/sso/saml

Domain: Your OKTA domain: <yourcompany>.okta.com

Server-Side Assert

This sometimes needs to be checked if there are server side scripts involved. This solution will pop a hidden pane in the background and let the server scripts run as they would in a regular browser. Once the hidden browser accesses the ping application it will be closed as the user has access to the SAP system.

With server-side assertion debugging from unsecured Chrome with local file can be a little tricky.

First time you will get a popup blocker so allow that and refresh. Also, since the browser does not have the loadstop event you need to run this code in the console once you have the ping app in the popup:

if (AppCacheLogonOKTA.inRelog && AppCache.CurrentApp === AppCache.PasscodeApp) {
 AppCacheLogonOKTA.inRelog = false;
 AppCache.Update();
 } else if (AppCacheNav.getCurrentPage().sId === "AppCache_boxLogon") {
 AppCache.AfterLogon();
 }
sap.ui.core.BusyIndicator.hide();

For a quick guide on how to get started with OKTA check Using Okta as identity provider for mobile clients .

Form Based

This authentication method is a flexible way of using an Identity Provider (IDP). It can replace the ADFS/OKTA etc. and can be used for future IDP’s. This authentication method is only available for Mobile Launchpads. When the trust is configured correctly between the SAP system and the IDP, the IDP logon screen should be automatically loaded from the Neptune mobile logon application when “Form-based” option is enabled. Generated dynamic javascript based on the customized values in NAM is run during login, which will post credentials to the IDP. This approach is similar to the old Batch Input in SAP where a recording is used to define how a screen should be processed. The fields and the button to be pressed needs to be specified, so the values are mapped accordingly and the correct actions are being executed.

Certificate

It is possible to use certificate logon not only on desktop, but also for Mobile Clients on iOS and Android by enabling the authentication option in the Mobile Client in the Cockpit.

By enabling the Certificate authentication, the required plugins will be added to the config.xml according to chooseed platform(s).

Android

When starting the app and logging on for the first time, the user will be prompted to choose an installed certificate. This certificate will be used automatically by the app until the cache is cleared.

First time the end user presses “Log on” (after changing language for example) a certificate prompt is presented with all installed certificates, and also an option to install a new certificate:

<plugin name="cordova-client-cert-authentication" source="npm"/>

This plugin adds certificate-based authentication (SSO) to your cordova application. There is no extra coding or android knowledge required when using this plugin. It does not contain any JavaScript part since it just waits until the SSLSocket asks the client for a certificate and then shows the default client-cert dialog you would also get when visiting your web page using the android chrome browser.

Please refer to the plugin page for more details.

iOS

To use the iOS plugin, a .p12 certificate with no password should be copied to a file with the extension .myp12 which is handled by the certificate plugin for iOS. The .myp12 file can then be opened with/copied to the Neptune app that includes the plugin. If the .myp12 is distributed by for instance email, there will be an option for Open with <your_neptune_app>.

When opening the app you should then be automatically authenticated and can simply press Log on without any further prompts.

<plugin name="cordova-plugin-client-certificate-support" source="npm" />

Please also make sure to use this version of the plugin cordova-plugin-ios-xhr:

<plugin name="@brodybits/cordova-plugin-ios-xhr" source="npm" />

This is required when building a new iOS mobile that uses WKWebView.

It is a replacement for @globules-io/cordova-plugin-ios-xhr and @castana/cordova-plugin-ios-xhr.

Please refer to the plugin page for more details.

Pre-requisites:

SAP server needs to be configured to accept certificate logon
User mapping needs to be in place
X.509 certificate must be installed on the device
Single user scenario (not shared device)
Certificate on iOS cannot be password protected
Neptune DXP 5.3.2 or higher (both NEPTUNE_LAUNCHPAD_STANDARD and NEPTUNE_LAUNCHPAD_MOBILE are supported).

Details on basic certificate setup in SAP

Native

When enabling the option for Native logon the logon procedure will be performed in an InAppBrowser. The Identity Providers logon page that is configured for SAP logon will be presented, and after a successful logon the user is authenticated for the launchpad application. Limitations for Native authentication is that the pincode tool is not fully supported. Because credentials are entered in the logon page of the external IDP in an InAppBrowser pane, only the MYSAPSSO2 cookie is used for further communication. This means that password must be re-entered when the cookie is no longer valid (i.e. the cookie validity has expired, or the app has been terminated).

Logoff URL: Ensures that the session cookie is terminated when logging off in the launchpad application. Standard logoff url in SAP is <host:port>/sap/public/bc/icf/logoff.

Custom

In some rear cases there is a requirement to make some changes to either of the standard provided logon procedures. For this purpose we recommend using the Custom logon option instead of copying or enhancing the launchpad application. This way it will be unaffected by future upgrades.

Template code for the Logon/Logoff functions is generated when enabling Custom Authentication:

var AppCacheLogonCustom = {

// Login Handler
   Logon: function() {

         // Handle After Logon Successfull
         AppCache.AfterLogon();

       },

      // Logout Handler
     Logoff: function() {

         // Build Path to SAP Server
         var urlPath = "";
         if (AppCache.allowIcfNode) urlPath = "/" + AppCache.allowIcfNode.toLowerCase();

         // Clear Login Cookies from SAP
         var logoffUrl = AppCache.UrlBase + "/neptune" + urlPath + "/native/neptune_login_ping.html?sap-clearsso2";

         if (navigator.onLine && AppCache.isOffline === false) {
             $.ajax({
                 type: "POST",
                 url: logoffUrl,
                 success: function(data, status, request) {
                     AppCache.clearCookies();
                 },
                 error: function(result, status) {
                     AppCache.clearCookies();
                 }
             });
         } else {
             AppCache.clearCookies();
         }

     },


     // Relogin Handler
     Relogin: function() {

         // Handle After Relogin
         AppCache.Update();

     },

     // Init Handler for global ajax error
     Init: function() {

         $(document).ajaxError(function(event, request, settings) {

             sap.ui.core.BusyIndicator.hide();

             switch (request.status) {

                 case 401:
                     break;

                 case 200:
                     var LoginStatus = request.getResponseHeader("SAPLoginStatus");

                     switch (LoginStatus) {
                         case "Password":
                             AppCache.Logout();
                             break;
                         case "Logon":
                             AppCache.Logout();
                             break;
                     }
                     break;

                 default:
                     jQuery.sap.require("sap.m.MessageToast");
                     sap.m.MessageToast.show(request.status + " - " + request.statusText);
             }
         });
     }

 };