Extending the SAP Cloud Platform SDK for iOS with Strong 2-Factor User Authentication and Digital Signatures by KOBIL
“We decided for German IT-security specialist KOBIL because they perfectly
meet our high expectations towards security, flexibility and usability.”
Sonja Vollrath, Head of ING-DiBa’s internet banking department
The SAP Cloud Platform SDK for iOS allows a very simple development for iOS apps accessing the SAP Cloud Platform (formerly known as “HANA Cloud Platform” – HCP), for example to consume a OData Service. By using the SDK assistant, only basic app development knowhow is required to build a functional iOS app, following Apple’s design guidelines for iOS. For example, you can create an app that authenticates to HCP and displays lists of OData structures without a single line of code to be programmed, just by letting the SDK assistant generate the appropriate app code for you. Of course, the generated code can be extended and modified depending on the specific requirements.
In mobile app scenarios, end user authentication is a crucial task, especially if the app needs to work on sensitive data outside the corporate network – such as financial-, employee- or healthcare data. In many cases, handling such data is regulated by laws and compliance rules, for example financial payment transactions which have to follow the PSD2 guidelines from the European Banking Authority (EBA). A usual requirement when handling sensitive data is a strong 2-factor-authentication (2FA), e.g. depending on the factor “knowledge” (something you know) and an independent factor “possession” (something you own). For example, a password or PIN code is “something you know”.
Let’s have a look at how the user authentication is done for iOS apps built on the SAP Cloud Platform SDK. Details can be found in the SDK document “22 – SAML and OAuth2 Authentication.pdf” which explains the SDK configuration when using user authentication with SAP ID Service or SAP CloudIdentity (SAML and/or OAuth authentication). The following two figures show how the integration is done, by extending the iOS “URLSession” class to support the SAML- or OAuth2 protocol implicitly. Such an extended class can be used to retrieve OData seamlessly from HCP without requiring the app developer to take care about username/password dialogs or implement identity provider protocols such as SAML (also known as “FORM-based authentication”) or OAuth2:
Figure: SAML authentication using SAP CloudIdentity in the SAP Cloud Platform SDK for iOS
Figure: Oauth2 authorization using SAP CloudIdentity in the SAP Cloud Platform SDK for iOS
In both cases, the iOS WebView object is used to retrieve the end user’s credentials, e.g. his or her SAP user ID and password that is implicitly used to obtain a SAML token or an Oauth2 token for future accesses.
Obviously, a username and a password are only one factor of type “knowledge”. But as these credentials can be used on many devices, and eventually also be stolen (by phishing using keyloggers or looking over the victim’s shoulder while entering them). So, there is no independent factor “possession” provided here and application scenarios requiring a strong 2-factor-authentication need some additional security layers to be applied. In other words, if an attacker runs the app on another mobile device and enters the same username and password there, the system cannot distinguish the real user from the attacker. Such “phishing” attacks are very common.
Typical 2-factor-authentication solutions come with a hardware OTP token or a software OTP Token app that generate “One-Time-Passwords” (OTP’s) which need to be entered along with username and password and which are valid only for a limited time. This introduces the “possession” factor, since only the owner of such an hardware token or such an OTP token app can log in. However, this has massive implications on the end user experience, e.g. carrying a hardware token along with the mobile phone or switching between the business app and the OTP token app. Furthermore, software-based OTP token apps are usually not very well protected against copying or hacking, so again the “possession” factor can be easily circumvented, resulting in a weak user authentication instead a strong 2-factor-authentication.
Figure: OTP Hardware Token (KOBIL SecOVID) and SAP Authenticator app (Software OTP)
This is now the point where KOBIL, an official member of the SAP PartnerEdge open ecosystem, extends the SAP Cloud Platform SDK for iOS with a strong 2-factor-authentication mechanism, e.g. by introducing a second and independent factor “possession” which binds the user’s digital identity to his or her individual mobile device. This avoids using the app on another device with the same user credentials, since it would not run on the second device without being properly activated there. From the usability perspective, the end user is faced only with the PIN / passcode / password entry he or she already knows, so there is no need to train him or her to a different handling or annoying users with handling OTP tokens or OTP apps. The KOBIL security SDK introduces the second factor “possession” silently in the background, withstanding even very skilled attacks.
Implementing KOBIL technology to apps using the SAP Cloud Platform SDK for iOS is quite simple, just by adding the KOBIL security SDK to an app project built with the SAP Cloud Platform SDK for iOS. The KOBIL security SDK establishes a second network connection to the KOBIL “Smart Security Management Server”, the so-called “Digitanium Channel”, through which a set of security parameters is checked online before cryptographically unlocking the end user’s digital identity on this particular mobile device. This also includes checking the so-called “device-binding parameter”, which is like a unique fingerprint for each mobile device. Only if this “device-binding parameter” matches the reference values, the digital identity is unlocked by the KOBIL security SDK and can be further used to authenticate (integrated with SAP CloudIdentity or SAP ID Service) or to generate digital signatures.