Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Mobile Single Sign On from iOS 7 to SAP NetWeaver

zubev
Employee
Employee
‎09-18-2013 6:30 PM

Update: Meanwhile SAP has delivered its SAP Authenticator app that should be evaluated for mobile single-sign-on. See Simple and Secure Mobile Single Sign-On with SAP Authenticator

With the release of iOS 7 Apple enhanced its operating system with several security features. One of them is the so called enterprise single sign-on, which makes it possible to login once and access backend systems from various apps without the need to store any credentials on the device. In the following blog post, I would explain how that new feature can be used to achieve Single Sign On to a SAP NetWeaver system. In the example below a SAP NetWeaver Gateway system would be used, although any HTTP-based API or UI can be accessed, including web dynpro and web gui.

Here are some screenshots on what you might expect as a final result (click on the images to get a larger image):

When you start an app that would try to connect to a SAP NetWeaver Gateway system, iOS would detect that authentication is required and would show a popup asking you to enter your credentials:

The next time an app (either the same or another one) wants to connect to a configured system (either the same SAP NetWeaver Gateway system or another one configured), iOS would reuse the authentication information and would not show a popup anymore:

but it would still authenticate to the backend system and the app would receive a positive response:

The credentials would not be shared neither with the mobile app, nor with SAP NetWeaver Gateway. Instead iOS would "exchange" them for a ticket that would be used for the authentication in the SAP NetWeaver Gateway System. As long as the ticket is not expired (usually 8 hours), SSO would work. Afterwards, the user would be asked to enter his credentials again.

Technically this is based on Kerberos. In order Kerberos to work, one needs three things:

  • a client - this is the iOS device
  • an authentication server - in most enterprises this already exists, e.g. the domain controller in a Windows environment. iOS would access it in order to get a server ticket for the server an app wants to connect to
  • a service server - this is the server a mobile app connects to, e.g. SAP NetWeaver Gateway. iOS would send the server ticket it obtained from the authentication server in order to authenticate. SPNEGO is used to send that ticket to the server.

All of those need to be configured, so that Kerberos could work

Configuration on the iOS Device

iOS provides the means to control which apps would be able to connect to which servers. This is done with configuration profiles and with iOS 7 a new SSO payload type has been introduced. Here is a sample configuration profile that needs to be installed on the device:



<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple/DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

  <key>PayloadContent</key>

  <array>

    <dict>

      <key>PayloadDisplayName</key>

      <string>SSO Settings</string>

      <key>PayloadType</key>

      <string>com.apple.sso</string>

      <key>PayloadVersion</key>

      <integer>1</integer>

      <key>PayloadUUID</key>

      <string>d3fe4709-0cc6-4f51-afed-839c6ab1451c</string>

      <key>PayloadIdentifier</key>

      <string>com.sap.example.sso</string>

      <key>Name</key>

      <string>username@EXAMPLE.COM</string>

      <key>Kerberos</key>

      <dict>

        <key>PrincipalName</key>

        <string>username</string>

        <key>Realm</key>

        <string>EXAMPLE.COM</string>

        <key>URLPrefixMatches</key>

        <array>

          <string>https://example.com/</string>

          <string>https://example.com:443/</string>

        </array>

        <key>AppIdentifierMatches</key>

        <array>

          <string>com.apple.mobilesafari</string>

          <string>com.sap.*</string>

        </array>

      </dict>

    </dict>

  </array>

  <key>PayloadOrganization</key>

  <string>SAP</string>

  <key>PayloadDisplayName</key>

  <string>SSO for SAP</string>

  <key>PayloadVersion</key>

  <integer>1</integer>

  <key>PayloadUUID</key>

  <string>f4544183-fc96-495f-a384-435cdb66e5b9</string>

  <key>PayloadIdentifier</key>

  <string>com.sap.example.sso.profile</string>

  <key>PayloadDescription</key>

  <string>SSO Configuration profile</string>

  <key>PayloadType</key>

  <string>Configuration</string>

</dict>

</plist>

The configuration profile can be installed by any means iOS supports, but usually that would be done via an MDM solution or pulled by the user from an HTTP server:

The most important attributes in the configuration profile are:

  • PrincipalName - this contains the username. It is an optional value and if it is missing the user would be asked to enter the username upon installation.
  • Realm - this is the Kerberos realm name. The realm must be accessible by the device - via connecting the device to the corporate network, VPN or using per app VPN (another new feature in iOS 7).
  • URLPrefixMatches - this is a list of URL prefixes, where Kerberos would work. If an app tries to connect to a URL that matches some of those URL prefixes, Kerberos would be activated. Otherwise it will not be and a standard HTTP call will be made. Here you need to list all valid prefixes explicitly, e.g. https://*.example.com/ would not work.
  • AppIdentifierMatches - those are the app identifiers of the apps that should be granted access to Kerberos. You need to explicitly mention the allowed app IDs, but you can use wildcards at the end, e.g. com.sap.*

The sample configuration profile above activates Kerberos for Safari as well as any app developed by SAP. Activation for Safari makes it possible to access even web gui or web dynpro via Kerberos. Of course, that can be disabled on SAP AS ABAP.

Configuration on the Authentication Server

iOS uses DNS to discover the Kerberos services, therefore they shall be registered within the DNS server that the iOS device uses (directly or via VPN). In order to test if that has been set up correctly, you might connect with a laptop to the same network the iPad/iPhone connects to and execute


nslookup -querytype=SRV _kerberos._tcp.EXAMPLE.COM


where EXAMPLE.COM should be replaced with your realm name. If you get an error (e.g. that the domain does not exist), then DNS is not configured correctly and you should contact your network administrators to change that.

In Windows environment, the domain controller advertises its Kerberos services automatically. Thus one just needs to make sure the iOS device is connected to the same DNS server (by modifying the Wi-Fi or VPN settings). In case of issues one might follow http://support.microsoft.com/kb/816587 or http://technet.microsoft.com/en-us/library/dd378871.aspx.

Configuration on the Service Server

SAP NetWeaver needs to be configured to use SPNEGO/Kerberos and to trust tickets issued by the Authentication Server the iOS devices use. For that you would need:

  • a supported version of SAP NetWeaver Application Server - see SAP Note 1798979 for details
  • a license for the product SAP NetWeaver Single Sign-On 2.0 (or higher)
  • several configuration steps - more details on configuring Kerberos on SAP AS ABAP you can get by watching the videos here
  • depending on the SAP AS ABAP and SAP NetWeaver SSO versions that you have, you might need to apply SAP Note 1902749 or 1902750 in order for Kerberos from iOS to work correctly
91 Comments
Labels in this area
Popular Blog Posts