Skip to Content

Part 1

Configuring the SAP Mobile Platform Mobile Services to connect to an instance of the Secure Login Server and retrieve a user certificate

 

 


Background & Introduction

This how to guide was the result of a discussion between us on the Mobile side and the guys over in the Secure Login Server (SLS) team on how to bring our common customers who both want to go mobile as well as remain as secure as possible. Since we have had the possibility to integrate the SLS into our platform for a few versions now, we thought it might make a great series to document how we can take this scenario from the theory to the real world.

 

In this how to guide, I will take you through all the steps necessary to successfully configure the SAP Cloud Platform Mobile Services to request a short-lived certificate from an SLS instance. If you are looking for a more theoretical view on this integration scenario, then please have a look at the corresponding blog here.

 

As with every technical scenario, there are some prerequisites that need to be met. Let us have a look at these next.


Prerequisites

This guide leans towards the Mobile part of the story. Therefore, it requires but does not describe how to setup an SLS instance. We were fortunate enough to have been given a fully configured instance by the SLS team. With that in mind, the following components are a must to execute this guide.

  • An account on the SAP Cloud Platform (trial accounts can also be used).
  • An instance of the SAP Cloud Connector (running).
  • An instance of the SAP Secure Login Server.
  • A REST client (I am using HTTP Requester which is an addon / extension to Mozilla Firefox).
  • A data source (in this guide the role of the data source is a cameo, but once we get past the setup, having somewhere to pick up meaningful data from will become important).

 

That said, there is one more thing I want to get out of the way at the very beginning. In my case, I am working within the confines of the extended SAP corporate network. Therefore, all the FQDN’s, the ports, the URL’s and so on are unmodified.


The Cloud Connector

 

The SAP Cloud Connector an agent installed within your corporate landscape that enables a secure connection to your cloud applications. In our case, it is the glue that holds this scenario together. So naturally, I recommend starting at this end of the stick.

Assuming your Cloud Connector is working as it should (if not have a look at this great blog on how to set up a Cloud Connector), begin by linking your Cloud platform account to your Cloud Connector.

 

Once a Cloud Platform account is linked to the Cloud Connector, one must expose specific services to the outside (and potentially unsafe) world. This is done by first adding an entry in the Access Control tab and then by specifying which resources in the targeted backend system are to be accessed. Essentially like a whitelist.

NOTE: When describing the actions to be executed on each screen, I choose to type the descriptive text before the screenshot.

 

  • Click on ‘Cloud to On-Premise’.
  • Click on Access Control.
  • Click on the ‘Plus’ sign.

 

  • From the dropdown choose ‘Other System’.
  • Click ‘Next’.

 

  • From the dropdown choose ‘HTTPS’.
  • Click ‘Next’.

 

  • Enter the FQDN of your SLS in the ‘Internal Host’ field.
  • Enter the HTTPS port your SLS responds to in the ‘Internal Port’ field.

 

Here we will map the internal FQDN with that which is to be exposed outside the corporate network. As I have already explained earlier, since my landscape is wholly within the SAP network, I am simply keeping the same naming & ports as in the previous window.

 

  • Fill in the FQDN of your SLS server in the ‘Virtual Host’ field.
  • Fill in the HTTPS port of your SLS server in the ‘Virtual Port’ field.
  • Press ‘Next’.

 

  • Leave the default value (None) in this window.

 

  • A description should you choose to enter one can be maintained here.
  • Press ‘Next’.

 

  • Press ‘Finish’.

 

Now we need to identify which resources should be allowed over this connection. You will notice that the status indicator does not turn green until appropriate resources are configured.

 

  • Click on the ‘Plus’ sign to add a new Access Policy.

 

  • In our case, we are simply granting access to all the services under the root (/). The description is optional.

 

  • Your final configuration should look similar to the screenshot above. I only say similar because you may have chosen to make the access control settings more granular.

 

Now we are ready to move on to the configuration on the SAP Cloud Platform Mobile Services side of things. However, before we go there, let me take the time to emphasize the following.

 

  • You must have an instance of the SLs set up and have access to the connection details in order to be able to execute the next steps successfully.
  • You must have a user in the SLS or it’s corresponding AD.

The SAP Cloud Platform Mobile Services

 

This is what the landing page of your cloud Platform account should look like. Do note that the UI may be subject to change.

The SAP Cloud Platform hosts the service we are interested in namely, the Development & Operations (also known as Mobile Services) Essentially Mobile Services is the umbrella that encompasses the Enterprise Mobility service offerings. This, as with all the services are found under the Services tab.

In the search field, type in ‘Development & Operations’. That should show you the service and it should be in the ‘Enabled’ mode. If not, Click on the service and then the ‘Enable’ button. The instantiation may take a few minutes.

Once the service is enabled, click on the  ‘Development & Operations’  tile.

 

 

  • Click on the ‘Go to Service’ link.

 

  • Click close unless you want to look through the new features.

 

  • Now that we are logged in to the service, click on the Connections link.

 

  • Press the ‘New Connections’ icon at the bottom of the page.

 

  • In the following screen,
    1. Enter a name for your connection.
    2. The URL to your SLS. Note that only HTTP is allowed not HTTPS if the proxy type is On-Premise.
    3. In the SSO Mechanism section,
      1. Press the ‘New’ button
      2. Choose No Authentication from the drop down.
    4. Finally, press ‘Save’.

 

  • A new Connection with the name you specified is visible in the list.

 

  • Now Click on ‘Settings’.

 

 

  • In ‘Settings’, click on the ‘Secure Login Server’ tile.

 

  • Click on the ‘New’ icon to create a new SLS Profile.

 

  • In my case, the Profile Name was provided by the SLs team. You must make sure you
    1. Have a profile set up in the SLS instance you are using.
    2. Use the exact same name in this setting.
  • Click the ‘Add’ button to retrieve the connection you wish to use.
    1. You may recognize the SLS connection previously created.
    2. That is the one we wish to reuse.

 

 

  • The result should be an entry in the Secure Login Server page as shown above.

  • Now we are ready to create an Application.
    1. Click on ‘Applications’.

 

  • In the ‘Information’ page (opens by default)
    1. Enter a unique application id for example, ‘com.sap.sls.demo’.
    2. Choose the application type ‘Hybrid’ from the drop down.
    3. Choose the ‘Certificate’, Security Configuration also from the drop down.
    4. Tick the ‘Enable Secure Login Server’ checkbox.
    5. Ensure that the SLS Profile created earlier is auto populated.
      1. If you have multiple SLS Profiles configured, you may use the drop down to choose from a list.

 

  • On the Backend page (click on the text ‘Backend’)
    1. Maintain a URL that points to the datasource you have chosen.
      1. Here I am simply pointing to the Northwind OData service.
    2. Choose a suitable SSO Mechanism.
      1. Since the Northwind service does not require authentication, I will leave it at ‘No Authentication’.
    3. Finally, click on ‘Save’.

 

That is it. You have now configured the SAP Cloud Platform Mobile Services to request a shortlived certificate within the context of a specific application.

 

Now let us execute the necessary calls to the SLS to acquire such a certificate.

 


Requesting a certificate from the SLS

 

Before starting on the next leg of our SLS journey, a note of caution.

When using a rest client to make the calls, I experienced a lot of erratic behavior and random errors. This was mainly due to my not taking the necessary precautions, so to save you a few agonizing moments, I have listed out my do’s below.

DO’s

  • If you are using a browser based REST client like I was (HttpRequester for Firefox)
    1. Clear your COOKIES.
  • Use a simple text file to note down the two most significant URL’s we will use.
    1. When working in the REST client, make sure to copy the URL from the text file to the URL field in the REST client.
      1. In my case, the client added some parameters to the URL which I did not notice because of the layout I was working in.
      2. This caused me tremendous headache and most importantly made me look like a fool in front of the others!
  • Use a simple text file to note down the keytool commands.

 

The All Important base URL

You will obviously acknowledge the fact that your base URL’s will be different to mine. If nothing else, then at least for the simple reason that your account will be different to mine. Using trial accounts will impact the URLS as well. So how do you find the right URL to use?

In Mobile Services (Development & Operations), Go to Applications, Click on the settings gear, click on the ‘Overview’ tab.

The Information tab contains all the details related to your application including the URL’s you can use.

You can safely use everything between HTTPS & ondemand.com as the basis of your URL.

 

 

NOTE: If you notice the difference between the URLs listed here and the one I used in the calls I made below, the reasoning is as follows.

  • The screenshot above was taken while I was finalizing the how-to guide and after the configuration was done.
  • During this time the service got patched and some new functionality was implemented.

 

Finally, if you are going to be working with REST or similar services, it may be worth your while to get deeper insight into how Postman can help make your testing process more robust and effective.

 

  • Send a POST request to the ‘doLogin’ URL.
    1. Doing this will return a SALT value, which we will use in our subsequent calls.
    2. https://mobile-a85868901.hana.ondemand.com/mobileservices/security/sls/com.sap.sls.demo/doLogin
      1. The taxonomy of this URL is as follows:
        1. HTTPS
        2. The SAP Cloud Platform account URL (make sure you get this from the application and not from the platform. Typically, you want to avoid the URL that may have ‘dispatcher’ in it).
        3. /mobileservices/security/sls/
        4. The app name (in our case, ‘com.sap.sls.demo’)
        5. And finally, the action, ‘doLogin’.
      2. Your URL will differ from the one used above.

 

 

  • We get a 200 response and the SALT value we wanted.

 

 

  • Build a new request with the following data
    1. POST
    2. Content-Type: application/x-www-form-urlencoded
    3. Parameters
      1. j_username=username
      2. j_password=password
  • j_salt=the_salt_value_from_the_previous_call

 

  • Submitting this request should return a 200 response.
    1. Make a special note of the following
      1. Authentication Process Complete &
      2. ACM OK must be present in the response. Else the process has not executed successfully.

 

  • Now that we have a successful authentication to the SLS it is time to
    1. Create a certificate.
      1. keytool -genkey -dname cn=KI045009,OU=SCPms_SLS_DEMO,o=SAP,c=DE -alias SCPms_SLS_DEMO -keyalg RSA -keysize 2048 -keystore SCPms_SLS_DEMO.jks -storepass abcd1234 -keypass abcd123

    1. Create a Certificate Signing Request.
      1. keytool -certreq -keyalg RSA -alias SCPms_SLS_DEMO -file certreq.p10 -keystore SCPms_SLS_DEMO.jks -storepass abcd1234

 

 

  • Check that the response is 200 and contains a certificate within it.

  • Mark the entire certificate and copy it into a text file.

  • Make sure to add the Beginning and the End of the response to the new text file.

 

  • Save this text file as a response.
    1. CertKey_SLS.rsp

 

  • Import the RSP file into the keystore we created earlier.
    1. keytool -importcert -alias SCPms_SLS_DEMO -file CertKey_SLS.rsp -keystore SCPms_SLS_DEMO.jks -storepass abcd1234

 

  • Should you see a warning,
    1. Press ‘y’
    2. Then press ‘Enter’.
    3. The response should be installed in the keystore.

 

  • Finally, let us create a P12 file which contains all our assets.

 

 

 

Congratulations.  You now have a short lived certtificate from your SLS instance. The screenshot below shows all the files we created and used during this process.

 


Verifying all the work

 

Here are some simple steps to verify the results of our efforts. I am using an opensource tool called XCA. However there are a number of perfectly viable alternatives including using the command line should you prefer that option.

 

 

  • Having installed XCA
    1. Click on ‘File’
      1. New Database.
      2. Give it a name
        1. Press ‘Save’.

 

  • Provide a password to protect the database.

 

  • In the ‘Certificates’ tab,
    1. Click on the ‘Import PKCS#12’ button.
    2. Choose the file we created previously using the command line interface.
      1. If you do not see the file you may have to
        1. Either browse to the location you stored it at.
        2. OR change the file type to p12.

 

  • Click ‘Import All’.
    1. If you are prompted for a password, provide the password used when creating the P12.

 

Now you should be able to see the contents of the P12, including the short lived user certificate.

 


Next up

In part 2 of this guide we will look at how to take this integration to the next step by adding an App on a device which will use the certificate from SLS to authenticate against the various components.

 

Until then, Take care & Have fun!

 


 

Key Contributors

Nothing happens in a vacuum and I’d like to thank those who persevered with me on this topic.

Stephan Andre.

Christian Cohrs.

Michael van Cutsem.

 


 

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply