Appendix D:  Security

This appendix goes over some topics that should be considered for secure Kapsel apps.

HTTPS
Whitelist Connections
Password Policy
Using a Technical User to Connect to a Backend OData Source
Cross-Site Request Forgery (CSRF)
Sharing Credentials between Applications
Accessing the SMP 3.0 Server From Outside a Corporate Firewall or on a Cellular Network
Using the X.509 Certificate Provider to Register using a Client Certificate
Things to Consider Before Release
SiteMinder

The following are some additional links on security in general for Android and iOS.
Android Security Tips
iOS Advanced App Tricks > Protecting Data Using On-Disk Encryption
iOS Security

HTTPS

Hypertext Text Transfer Protocol Secure (HTTPS) can be used to communicate between the mobile app and the SMP 3.0 server and between the SMP 3.0 server and the OData endpoint rather than HTTP.  HTTPS provides a reasonable guarantee that one is communicating with precisely the web site that one intended to communicate with (as opposed to an imposter), as well as ensuring that the contents of communications between the user and site cannot be read or forged by any third party.

The video SSL Certificate Explained may be useful if you are not very familiar with SSL and HTTPS.

The SMP 3.0 server uses port 8080 by default for HTTP and port 8081 for HTTPS.  In addition, port 8082 is used for mutual authentication (clientAuth="true") and port 8083 is used for the management cockpit.  As of SP04, these ports have a specific name (see the smpConnectorName tag below) and the port is configurable in the Management Cockpit under Settings > Connectors.  For additional details on how the ports are configured see the file

C:\SAP\MobilePlatform3\Server\config_master\org.eclipse.gemini.web.tomcat\default-server.xml<Connector port="8080" protocol="HTTP/1.1" maxThreads="250" connectionTimeout="20000"        enableLookups="false" acceptCount="100" redirectPort="8081" server="SAP" /><Connector protocol="com.sap.mobile.platform.coyote.http11.SapHttp11Protocol"       port="8081" maxThreads="200"        scheme="https" secure="true" SSLEnabled="true"       ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA"        keyAlias="smp_crt"       clientAuth="false" sslProtocol="TLS" sslEnabledProtocols="TLSv1" /><Connector protocol="com.sap.mobile.platform.coyote.http11.SapHttp11Protocol"       port="8083" maxThreads="200"       scheme="https" secure="true" SSLEnabled="true"       ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA"       keyAlias="smp_crt"       clientAuth="false" sslProtocol="TLS" sslEnabledProtocols="TLSv1" smpServiceType="admin" compression="on" compressionMinSize="2048"        compressableMimeType="text/html,text/xml,application/javascript,text/json,text/plain,application/json" /><Connector protocol="com.sap.mobile.platform.coyote.http11.SapHttp11Protocol"       port="8082" maxThreads="200"       scheme="https" secure="true" SSLEnabled="true"       ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA"       keyAlias="smp_crt" clientAuth="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1" /><Connector smpConnectorName="mutualSSL" protocol="com.sap.mobile.platform.coyote.http11.SapHttp11Protocol"           port="8082" maxThreads="200"           scheme="https" secure="true" SSLEnabled="true"        ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA"           keyAlias="serverkey" clientAuth="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1"/>

The above xml file shows a new entry added to support HTTPS on port 443 using a certificate with an alias of serverkey and a smpConnectorName of customSSLConnector.
Note that the SMP 3.0 server requires a restart after making changes to the default-server.xml file.
Also note that the alias of the certificate used by the SMP 3.0 server for connections to 8081, 8082 and 8083 (Management Cockpit) is smp_crt.

A new certificate can be created in the SMP 3.0 keystore (C:\SAP\MobilePlatform3\Server\configuration\smp_keystore.jks) using the Java KeyTool command as shown below.

keytool -genkeypair -alias serverkey -dname cn=YKFN00528072A.amer.global.corp.sap,c=CA -keystore smp_keystore.jks -storepass changeit -keyalg RSA -validity 360 -keysize 2048

Note that the storepass parameter takes the password entered for the SMP 3.0 keystore which is set during the installation of the SMP 3.0 server.
The common name must be the fully qualified domain name of the machine that the SMP 3.0 server is running on.  This must match the name entered into the browser to access the site.  For example the site must be accessed using https://YKFN00528072A.amer.global.corp.sap and not https://localhost or https://ip_number.
Note that SMP 3.0 server must be restarted after making changes to the smp_keystore.jks file.

It is possible to use self-signed certificates in a desktop browser.  The browser will however not be able to verify the certificate as it was not signed by a certificate authority that the browser trusts and will indicate this as shown below.


The self-signed certificate can be imported into the browser's certificate authority’s store.
To do so, click on Details > Copy To File > Next > Base-64 encoded X.509 > C:\temp\serverkey.
Then click on Settings > type in cert in the Search settings > Manage certificates > Trusted Root Certification Authorities > Import > c:\temp\serverkey.cer.
At this point the self-signed certificate used by the SMP 3.0 server to identify itself and encrypt communication using SSL will now appear as a Trusted Root Certificate Authority as shown here. 


Once the certificate is installed into the Trusted Root Certification Authorities store and the page is next opened in Chrome (after all instances of Chrome have been shut down), there will no longer be a certificate error (Notice the https and lock icon in the address bar is green) as shown below.

Note that the default port number for HTTPS communication is 443 which is why 443 is not shown in the browser's URL.

The same process can be used to install the certificate used by the Management Cockpit so that when opening the Management Cockpit the user is not presented with a warning screen.


A better solution is to replace the self-signed smp_crt certificate with a certificate that has been signed by your company's certificate authority or one of the standard certificate authorities.

When a certificate is signed by a Certificate Authority (CA) that is known to the browser, it is not necessary to manually install the certificate.  The browser contains the CA in its trusted root certificate authorities and will trust certificates that have been signed by that CA.  Here we can see that the certificate used by the Netweaver Gateway demo system was signed by Starfield Secure Certification Authority.


It is possible to view the trusted certificate authorities available to a browser such as Chrome by choosing Settings > Show Advanced Settings > HTTPS/SSL > Manage Certificates


The SMP 3.0 server stores its certificates into the file named C:\SAP\MobilePlatform3\Server\configuration\smp_keystore.jks.  One tool which provides a graphical view of the contents of keystores is KeyStore Explorer.


In the image above, we can see that the previously created key with an alias of serverkey is a self-signed certificate as the issuer is the same as the subject.  Two other certificates of interest are smp_crt which is the default self-signed certificate used by the SMP 3.0 server and the sapgatewaycert used by the SAP Gateway demo OData source.  The sapgatewaycert was installed even though the certificate is signed by a certificate authority because the certificate authority Starfield Secure Certification Authority is not included in smp_keystore.jks.  Alternatively, we could have installed the Starfield Secure Certification Authority certificates into smp_keystore.jks.

Unlike a desktop browser such as Chrome, it is not possible to install a self-signed certificate into the device's trusted credentials store to establish an HTTPS connection between the SMP 3.0 server and a mobile device or simulator in a Cordova app.  A certificate signed by a certificate authority is required.  It is possible to create your own certificate authority using Open SSL and use that certificate authority to sign the server certificate.  The AuthProxy sample demonstrates how to sign a client certificate using a certificate authority created using Open SSL.  Another approach is to use an SSL provider such as VeriSign and request them to sign the certificate.  The below steps will demonstrate how to use the SAP Test Server Certificate Authority to sign the server certificate. 

SAP provides SAP Trust Center Services where one can either purchase a SSL server certificate or can try a test server certificate which is valid for eight weeks.

• Download the SAP SSL Test Server CA Certificate from SAP Trust Center Service - Root Certificates.
  
  The file is named getCert.cer by default.  Rename it to SAPServerCA.cer.
  Import it into the smp_keystore.jks store.

  keytool -importcert -alias sapserverca -file SAPServerCA.cer -keystore smp_keystore.jks -storepass changeit

  Generate a certificate signing request (CSR).

  keytool -certreq -keyalg RSA -alias serverkey -file server.csr -keystore smp_keystore.jks -storepass changeit

  Open the webpage SSL Test Server Certificates and click on the Test it Now button.
  Open server.csr and copy the contents to the form, select other web server and click continue.
  Copy the resultant string and place it in a file named server.rsp.
  The below command will import the signed certificate into the keystore.

  keytool -importcert -alias serverkey -file server.rsp -keystore smp_keystore.jks -storepass changeit

  At this point the certificate serverkey is now signed by the SAP SSL Test Server Certificate Authority as shown below.
  
  
  
• A certificate in a keystore can also be viewed using the following command.

  keytool -list -v -keystore smp_keystore.jks -alias serverkey -storepass changeit

• The SMP 3.0 server needs to be restarted after making changes to the smp_keystore.jks.
  
  
• SAPServerCA.cer should be added to the device's trust store so that the mobile device or emulator trusts the server certificate.
  
  For Android

  adb push SAPServerCA.cer /mnt/sdcard/
  adb shell
  cd /mnt/sdcard
  ls
  exit

  Install SAPServerCA.cer to the Android trusted credential store via

  Settings -> Personal -> Security -> Install from SD card (requires Android 4.0+)

  Note, that in the Android 4.4 emulator, the SAPServerCA.cer file did not appear in the list of available certificates to install.  A workaround is to rename the file to SAPServerCA.crt, copy it to C:\SAP\MobilePlatform3\Server\webapps\sapui5, and open the emulator's browser to http://machine_name:8080/sapui5/SAPServerCA.crt.
  
  Note, on Android 4.4, a warning message is shown after a trusted credentials such as SAPServerCA is installed.  For further details see Network may be monitored.
  
  For iOS
  When using the iOS 7.0 emulator, the SAPServerCA.cer certificate can be installed by simply dragging and dropping it onto the emulator.
  
  When using an iOS device the SAPServerCA.cer certificate can be installed into the device's trusted store by sending it via an e-mail, opening the device browser to a webpage that contains a link to the certificate, or by using the iPhone Configuration Utility.  The certificate can be viewed and uninstalled under

  Settings -> General -> Profiles

Once a certificate that has not been self-signed is used, the secure toggle can be selected on the Registration screen.  This toggle can be set to true and the HTTPS port set via the Logon plugin's context (see the index.html from the logon demo) as shown below.

// Optional initial connection context    var context = {        "serverHost": "YKFN00528072A.amer.global.corp.sap", //Place your SMP 3.0 server name here        "https": "true",        "serverPort": "443",        ...    }

In summary, when an HTTPS connection is established between a client and the server, the client verifies that the server certificate is signed by a certificate authority that the client trusts, that the certificate is not expired and the connection is coming from the host described in the server certificate.

For additional details on certificates see
www.sslshopper.com/ssl-faq.html
Common Keytool Commands
Changing Installed Certificates Used for HTTPS Listeners

Whitelist Connections

Cordova apps provide a setting in config.xml that lists what URLs can be accessed by the application.  By default the setting is set to *.  Change this to be the address of your SMP server to restrict network access to the URL specified.
On Android modify

LogonDemo\platforms\android\res\xml\config.xml

On iOS modify

LogonDemo\platforms\ios\LogonDemo\config.xml

<access origin="http://server1.mycompany.com" />

Note, the URL should be in lowercase.  Here is an example that demonstrates the error shown when trying to access a URL that has not been whitelisted. 

For additional details see Domain Whitelist Guide

Note that the whitelist is case sensitive.  CB-5395

Password Policy

Before a Kapsel app can be opened that includes the Logon plugin, the unlock screen appears.

The rules defining how often the password must be changed, the length of the password, if the password must include digits, upper and lower case letters etc. can be specified.

Note, if the app does not require an unlock screen, the button disable passcode can be pressed.

This requires that the option Default password allowed checkbox on the Client Password Policy screen be checked.

Using a Technical User to Connect to a Backend OData Source

In the sample Logon Demo the user id and password for the backend OData source must be entered by the user.  Another approach is to specify the user name and password in the Management Cockpit.  This is known as using a technical user since each instance of the mobile application will use the same credentials to access the backend OData source.  This would typically be used in cases where the mobile application is not making updates to the data or perhaps for a demo application.  When multiple users are making changes to the backend data, normally, each user would do so using their unique credentials.  The following steps will demonstrate how to modify the Logon Demo to use a technical user.

• Create a new connection to the backend OData source named Technical by choosing Applications >  com.mycompany.logon > Back End > Back-end Connections > New.  Notice that the username and password is provided in this dialog.
  The endpoint is

  https://sapes1.sapdevcenter.com/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT

  
  
  
• Create a new security profile named PreConfiguredUser by choosing Settings > Security Profiles > New and then add a System Login (Admin Only) authentication provider.
  
  
  
• Change the security profile for the Logon Demo to use the newly created PreConfiguredUser authentication profile under Applications > com.mycompany.logon > Authentication > Existing Profile > PreConfigured User
  
  
  
• Modify index.html and change context setting to use the specified user name and password.  Then change the following line in the read method

  sUrl = applicationContext.applicationEndpointURL + "/CarrierCollection?$format=json";

  to

  epURL = applicationContext.applicationEndpointURL;
  epURL = epURL.substring(0, epURL.length - 1);  //value on Android has a trailing / that iOS does not have in version 3.0 and SP01. 
  sUrl = epURL.substring(0, epURL.lastIndexOf("/"));
  sUrl = sUrl + "/Technical" + "/CarrierCollection?$format=json";

  Comment out the line used to provide the user id and password as those values are now supplied via the connection named Technical in the Management Cockpit.

  //oHeaders['Authorization'] = "Basic " + btoa(applicationContext.registrationContext.user + ":" + applicationContext.registrationContext.password);

• Deploy and run the app and press the Unregister button followed by the Register button.
  
  
  
  Note that when registering for the application, a user name and password is provided that the SMP 3.0 server authenticates and then when the data is requested from the OData source, the SMP 3.0 server provides the technical user id and password.
  
  Note using the same technique, one application can use multiple connections.

Cross-Site Request Forgery (CSRF)

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated.  See Cross-Site Request Forgery (CSRF) for additional details.

The SAP Netweaver Gateway system protects against CSRF attacks by requiring that all modifying requests include an X-CSRF-Token in the header of the request.  The value of this is returned from a GET request.  See Cross-Site Request Forgery Protection for additional details.  The included  index.html demonstrates how to perform create, update and delete operations that make use of the CSRF header.  To use this provide the user id and password for the OData source on line 6, place a copy of datajs-1.1.2.min.js into the same folder as the HTML file and deploy the Kapsel app.  Notice below that the carrier ID AA has been deleted and the currency for AC has been changed to USD. 

Sharing Credentials between Applications

If multiple applications on a device connect to the same SAP Mobile Platform server and use the same user name and password or certificate, those can be shared between apps so that they only need to be entered once.  The shared credentials are managed by an application called Client Hub which integrates with the Logon plugin.  The Client Hub is provided as an Android and iOS project that can be built and installed on a mobile device or simulator.  It is part of the mobile SDK native SDK.

C:\SAP\MobileSDK3\ClientHub

  For additional details see Client Hub.

Note the applications that are sharing credentials can be either native mobile applications or Kapsel applications.

The Client Hub project and the Kapsel projects must be signed by the same certificate.  For more information on Android application signing see Signing Your Applications.

Perform the following steps to share credentials between two Kapsel apps.

• Deploy the ClientHub project to a device or emulator.  When it starts provide a single sign-on password. 
  
  
  
• Open the LogonDemo project which was described in the section named Logon.
  
  
• Note, if deploying to an iOS device the clienthubEntitlements keychain group must be added to the entitlements section as well as the bundle identifier.
  Note the bundle identifier can also be represented as $(CFBundleIdentifier). 
  Xcode 4.6
  
  
  Xcode 5
  
  
  
• On Android, add a folder and file named LogonDemo/res/raw/clienthub.properties.  The contents should include

  Host=10.7.171.208
  Port=8080
  HTTPS=false
  SecurityConfiguration=Config123
  UserCreationPolicy=automatic
  FarmID=0

• Note that on Android the FarmID field must be provided even though it is not being used in this example.
  
  
• On iOS, right click on the project and choose New File > iOS > Resource > Property List and name the file clienthub.  Right-click on the file and choose Open As > Source Code.  The contents should include

  <?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>Host</key>
      <string>10.7.171.208</string>
      <key>Port</key>
      <string>8080</string>
      <key>HTTPS</key>
      <false/>
      <key>SecurityConfiguration</key>
      <string>Config456</string>
      <key>UserCreationPolicy</key>
      <string>automatic</string>
  </dict>
  </plist>

• The value of SecurityConfiguration must be the same across apps that wish to share credentials on the device.
  
  
• Remove the app from the device or simulator.  Deploy and run the app LogonDemo.  When it starts the single sign-on password for the client hub screen is requested.
  
  
  Notice that the registration screen is not shown.  When using the Client Hub, the connection details for the SMP 3.0 server (host, port etc.) must be statically supplied in the plist or properties file.
  
  
• Create a second Kapsel project with a name of LogonDemo2 and an application id of com.mycompany.logon2.  Follow the steps in the section named Logon.
  
  
• Follow the steps shown in Configuring a Kapsel App in the Management Cockpitto create an Application with the application id of

  com.mycompany.logon2

• Create the clienthub file as described previously.
  
  
• Deploy and run Logon2.  When it starts, the single sign-on password screen is presented.
  
  
  Notice that the screen asking for a username and password was not shown as the username and password are provided from the Client Hub app.
  
  If Logon Demo 2 is closed and reopened, it is only the app's passcode screen that is shown.
  
  
  
  
• Note that on iOS, it is necessary to press the reset button in the Client Hub before removing the Client Hub application.
  
  

Accessing the SMP 3.0 Server From Outside a Corporate Firewall or from a Cellular Network

Support for the Relay Server was added as part of the SMP 3.0 SP03 release.  SAP provides a publicly hosted relay server that can be used in development to enable a server such as the SMP 3.0 server to be available to devices outside of a corporate firewall or on a different network.  In a production environment it is recommended that you install the relay server into your own environment.
The relay server works by establishing a persistent connection between the rsoe.exe (outbound enabler) which typically runs on the same machine as the SMP 3.0 server and a relay server (which is publically reachable).  The publicly hosted relay server is running at http://relayserver.sybase.com.
The complete documentation is available at Relay Server.

The relay server is part of the SAP Sybase SQL Anywhere product.  If you do not already have a copy of it, a trial version can be downloaded from SAP Sybase SQL Anywhere 16 Developer Edition.  During the install, ensure the option Relay Server is checked.

The following steps demonstrate how to use the publicly hosted relay server to enable a Kapsel app to be able to connect to an SMP 3.0 server running behind a corporate firewall or on a different network.  Before following the below steps, make sure that the server connections in the SMP 3.0 server are using test data only or have sufficient security setup.

• Register with the Hosted Relay Service.
  Click on Manage Account and choose Add New Mobilink Farm.
  Enter rsFarm for the farm name and rsoeSMP for the server 1 name.  Click on Create Farm.
  Click on Configuration Instructions and scroll down to MobiLink 12.0.x.  Create a file named C:\Kapsel_Projects\rsoeSMP.config with the contents copied from the MobiLink 12.0.x section.  Here is what my settings look like.

  -f dan123.rsFarm
  -id rsoeSMP
  -t xxxxxxxxxxxxxxxxxxxxxxxxxxx
  -cr "host=relayserver.sybase.com;https=1;port=443;proxy_host=proxy;proxy_port=8080;url_suffix=/ias_relay_server/server/rs_server.dll"
  -cs "host=localhost;port=8080" 
  -v 2
  -o c:\temp\rsoe_smp.log

  The outbound enabler options are documented here.  Note the settings for proxy_host and proxy_port.  If your network does not use a proxy server, remove these values.
  
  
• Locate the outbound enabler (rsoe.exe).  It should be located at C:\Program Files\SQL Anywhere 16\Bin64 and start it from a command window.

  rsoe @c:\Kapsel_Projects\rsoeSMP.config

  
  
  
• Open a browser and verify that the SAPUI5 page can be accessed through the relay server.

  http://relayserver.sybase.com/ias_relay_server/client/rs_client.dll/dan123.rsFarm/sapui5/

  
  Note, the value dan123.rsFarm will need to be replaced with your subscription ID and farm name.  At this point the relay server is allowing access to the SMP 3.0 server running on your laptop from any machine or device that can reach the public URL relayserver.sybase.com.
  
  
• Finally modify the sample from the Logon section named register3.html to use the relay server.  This will enable the Kapsel app to register against a SMP 3.0 server that is on a private network from another network.
  In register3.html, change the context to use the relay server.  The changed context is shown below.  Note, the farmId dan123.rsFarm will need to be modified to match the subscription ID provided when registering with the hosted relay server.

  var context = {        "serverHost": "relayserver.sybase.com", //Place your SMP 3.0 server name here        "https": "false",        "serverPort": "80",        "user": "i82xxx",   //Place your user name for the OData Endpoint here        "password": "xxx",  //Place your password for the OData Endpoint here                              //once set can be changed by calling sap.Logon.changePassword()        "communicatorId": "REST",        "passcode": "password",  //note hardcoding passwords and unlock passcodes are strictly for ease of use during development                                 //once set can be changed by calling sap.Logon.managePasscode()        "unlockPasscode": "password",        "passcode_CONFIRM":"password",        "farmId" : "dan123.rsFarm",        "resourcePath" : "ias_relay_server/client/rs_client.dll"
  };

Using the X.509 Certificate Provider to Register using a Client Certificate

Client certificates can be used by applications to uniquely identify a user to the SMP 3.0 server or to an OData backend.  Client certificates can be passed to the Logon Plugin either by SAP Afaria or via the new X.509 Certificate Provider Interface.  The AuthProxy plugin can access a certificate directly via its CertificateFromFile or CertificateFromStore classes.  The Authproxy plugin can also access a certificate from the Logon plugin via the class CertificateFromLogonManager but the Logon plugin cannot access a certificate from the AuthProxy plugin.

The X.509 Certificate Provider is an interface that can be used to integrate third-party certificate providers with the Logon plugin.  For additional details see Using the X.509 Certificate Provider Interface to Integrate with Third-Party Certificate Providers and https://github.com/SAP/mobilesdk-certificateprovider.
The following steps demonstrate how to use this interface to allow the Logon plugin to access a client certificate that is stored on an Android device or emulator.  It is intended that this same technique can be used to allow the Logon plugin to work with third-party software that will provide the certificate to the device rather than simply accessing a certificate that is already on the device.  This example uses the Logon sample that contains the file register3.html.

• Add the AuthProxy plugin to the project.  This will be used to demonstrate how a request can be made to an OData provider that requires the client to authenticate itself with a client certificate.

  cordova -d plugin add com.sap.mp.cordova.plugins.authproxy

• Add the sample implementation of the X.509 certificate provider to the project.  The source to two required Java files can be copied from CustomCertificateProvider.java and  CustomKeyManager.java
  In the file CustomCertificateProvider.java, modify the initial value of _alias to match the name of the client certificate and change the line settings.put("filepath", "user1.p12"); to match the name of the client certificate.
  
  
• Add the below bolded lines to the AndroidManifest.xml file to indicate the class name the logon plugin should load which implements the X.509 certificate provider API and the read permission so that a client certificate can be read from the SD card.

  <application android:hardwareAccelerated="true" android:icon="@drawable/icon" android:label="@string/app_name"><meta-data android:name="certFromFileProvider" android:value="com.example.certificatefromfileprovider.CustomCertificateProvider" />...<uses-sdk android:minSdkVersion="10" android:targetSdkVersion="19" /><uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

• Modify register3.html to instruct the Logon plugin to use the X.509 Certificate Provider API.  Change the line

  sap.Logon.init(logonSuccessCallback, logonErrorCallback, appId, context);
  to
  sap.Logon.init(logonSuccessCallback, logonErrorCallback, appId, context, null, "certFromFileProvider");  
  //null indicates to use the default view provider, "certFromFileProvider" is the name of the class to load

• Copy the file x509ProviderUI.view.js to C:\Kapsel_Projects\LogonDemo\plugins\com.sap.mp.cordova.plugins.logon\www\common\assets\ui\resources\x509ProviderUI.view.js
  Copy the file i18n.provider.properties to C:\Kapsel_Projects\LogonDemo\plugins\com.sap.mp.cordova.plugins.logon\www\common\assets\i18n\i18n.provider.properties
  
  
• Modify register3.html to use the AuthProxy plugin.
  Add the following line to the start of the init method

  //Integrate datajs with HTTPS proxy
  OData.defaultHttpClient = sap.AuthProxy.generateODataHttpClient();

  Add the following two bolded lines to the read method.

  clientCert = new sap.AuthProxy.CertificateFromLogonManager("com.mycompany.logon");            
  var request = {    headers : oHeaders,    certificateSource : clientCert,    requestUri : sUrl,    method : "GET"
  };

  Note, the read call will not succeed since the OData provider is not configured to accept an X.509 client certificate.  Also note that the certificate alias property of the endpoint in the management cockpit would need to be configured to provide the client certificate used to connect from the OData provider to the back-end OData provider.
  
  
• The X.509 Certicate provider requires the use of the ClientHub.  The ClientHub app needs to be installed on the device or emulator.  For additional instructions see Sharing Credentials between Applications. Create a folder and file named LogonDemo/res/raw/clienthub.properties.  The contents should include

  Host=HOST_NAME_OF_SMP_SERVER
  Port=8082
  HTTPS=true
  SecurityConfiguration=Config123
  UserCreationPolicy=certificate
  FarmID=0

  Note that the Host value must be the host name and not an IP address to pass the host validator check when the SMP 3.0 server certificate is validated.
  Note also that this example requires that the SMP 3.0 server has been configured to use port 8082 for mutual authentication.  See the AuthProxy plugin section for additional details.
  
  
• Ensure that the public key of the certificate authority used to sign the SMP 3.0 server's certificate for port 8082 is installed onto the Android device or emulator and that the client certificate has been uploaded to the device.  This is covered in the AuthProxy section of the guide.
  
  
• Copy the files to the platform directory by running

  cordova -d prepare

• Use the Android IDE to deploy and run the ClientHub and LogonDemo projects. 
  

Things to Consider Before Release

Consider minifying or even obfuscating your code if you wish to make it harder for someone to examine your code.

Ensure that the app cannot be debugged.  See the debugging section for additional details.

Remove any hardcoded passwords.  Many of the samples have these set in the context variable so they do not need to be entered for ease of use during development.

Ensure that the log level is set appropriately and that the log commands that are left are intended to be in the production code.  Review the log output to ensure that nothing is being logged that should not.

Review the client password policy and ensure that it is set appropriately.

Consider adding a Mobile Device Management solution such as SAP Afaria to enforce a lock screen, a password policy, to enable remote wipes of a device and to prevent devices from being rooted or jail broken.

SiteMinder

SiteMinder is a commonly used access management solution that can be used with the SMP 3.0 platform.  The following links provide additional details.
CA SiteMinder
Single Sign-on Integration with SiteMinder
How-To: Set up SUP with SiteMinder

Back to Getting Started With Kapsel