How to Guide

Integrate Microsoft Azure Active Directory to SAP Cloud Platform for SAP Cloud Platform Mobile Services

Introduction

The trust configuration in SAP Cloud Platform (SCP) allows one to configure an external / third party / on premise or in the cloud Identity Provider (IdP) as a trusted Identity Provider.  Indeed, one may even set these to default IdP should that be necessary.  This guide demonstrates the steps required to setup a Microsoft Azure Active Directory (MS AAD) instance to act as our default IdP.

The final goal is to use existing credentials to authenticate to different services built on SCP.

Resources used to showcase Microsoft AAD integration

• A trial SAP Cloud Platform account
  • Service SAP Cloud Platform Mobile Services enabled
• A trial Microsoft Azure account
  • MS Azure AD service should be enabled and an account should be defined in it to perform the test

General Architecture

Process overview

1. Configure the Local Service Provider in the SAP Cloud Platform
2. Create an Enterprise Application in Microsoft Azure with SAP Cloud Platform as a type
3. Configure the Single Sign-on settings of the newly created Azure Enterprise Application
4. Configure the Application Identity Provider in SAP Cloud Platform
5. Test the overall setup in accessing SAP Cloud Platform Mobile Services

SAP Cloud Platform Local Service Provider Configuration

The configuration of the trust between SCP and the existing AAD you would like to use takes place in the security area of your SCP instance.

If you look at the second tab in Trust you will notice they default SAP ID Service

Go to Security ► Trust.

Select the second tab “Application Identity Provider”.

The purpose of this section will be to change the configuration to another Application Identity Provider that points to our ADFS instance.

But before doing this we need to make some adjustments to the authorizations prior to the trust configuration.

Defining groups in SCP

In the SCP Cockpit, go to “Security” ► “Authorizations”

Go to the second tab, “Groups”

Create a new group called “Everyone”

Assign all the roles that are relevant using the Assign link above the grid bellow on the left-hand side.

We still need to be sure that this set of users (groups and users) within the group Everyone has the required permissions for SCPms.

In SCPms permissions cannot be assigned to users and groups directly.  A role needs to be defined and the relevant users and groups will get this specific role.  Then we can attribute to the role a set of permissions.

In SCP Cockpit, go to Services

Type in the search bar “development” to limit the amount of services displayed and select “development & Operations”.

At the bottom of the screen click on the link “Configure Development & Operations Cockpit”

Click on Roles in the left-hand side.

If not there yet, click on “New Role” at the bottom and type in “HanaMobileAdmin”

Then click on Assign on the lower right part of the screen to assign a group to the selected role above.

Select the group “Everyone”.

Now we have a role with users/groups associated to it but this role has no permissions yet!

Click on “destinations & Permissions” in the left-hand side.

Click on the Edit button at the bottom to assign the role you have created in the previous screen to the permission “HanaMobileAdmin”.  We have given the name of the permission to the role which could be a bit confusing but the principal to:

• link users and groups to a role
• link a role to permissions

Press the Save button to finish this step

Configuring the Local Service Provider

Go to Security ► Trust.

Select the first tab “Local Service Provider”.

Press Edit

Select Custom

A new page appears with some key information:

Local Provider Name: the current SCP instance is the local service provider.  In the context of the setup of a trust, it is important to name properly the different parties involved.

The signing key and certificate correspond to a public and private key (aka Asymmetric Keys, while one can be used to cipher data the other one can be used to decipher those data and the other way around).  Those two pieces of information are “key” in the setup of trust (aka SSL handshake).  While one will be used to sign the message, the other one will be required to verify the signed message.  In this context, the private key, the signing key, will be kept secret to the SCP instance and the other one, the public key, the certificate or the signing certificate, will be given to the other party to allow it to validate the message signed using the private key.

Press Save

Press OK.

The configuration of the Local Service Provider is done.

Getting the metadata file from the Local Service Provider

To establish the trust between the two parties we will need to exchange information between them.  This configuration is mostly done through the exchange of metadata files.

In the Local Service Provider tab, press on Get Metadata

The metadata file has been downloaded to your computer, most probably in the default location which is “C:\Users\<your_user_ID>\Downloads”.  The content of that metadata file is given here bellow.

This metadata file contains information that will be required for the configuration of Microsoft AAD.

Microsoft Azure Configuration

Go to portal.azure.com

In the left-hand side, click on “More services >”

Type “Enterprise” and click on “Enterprise Applications”

Click on “All applications”

The list of application that are currently defined are listed.

Creating a new Enterprise Application for SAP Cloud Platform

Click on the “New application” link at the top

Type “SAP Cloud” in the search field and select “SAP Cloud Platform” from the “ERP” category.

Type a name for your enterprise application such as “SCP” and press “Add”

The system is processing the request.  It can take a couple of seconds to come up.

Add users to the Enterprise Application

Go to “Users and groups” on the left or “Assign a user for testing” on the right.

Configure the new enterprise application

Go to “Single sign-on” on the left.

Select “SAML-based Sign-on”

Enable the checkbox “Make new certificate active”

Press the “Save” icon all the way at the top

Close the page using the small cross below the Identity icon in the upper right corner.

Getting the metadata file from AAD, the Identity Provider

Go back to the Enterprise Application you have just created.

Click on the SCP app

Then click on “Single sign-on”

Click on the “Metadata XML” link.

The file is downloaded and its name is the name you gave to your enterprise application .xml.

SAP Cloud Platform Application Identity Provider Configuration

Configuring the Application Identity Provider

As you can see in the screenshot bellow the SAP ID Service has disappeared and another one is available.  The one listed in the screenshot might not exist in your case, something is defined already at this stage in my case since I made multiple tests in the past and you cannot remove the latest entry, one entry should always be there…

Click on “Add Trusted Identity Provider”

The first field to fulfill ask for a metadata file.  Load the metadata file from the AAD you have downloaded earlier and majority of the fields will be populated automatically.

Some small adjustments should still need to be done.

Select “Assertion Consumer Service” for the “Assertion Consumer Service” field.

[Optional] Select “HTTP-POST” for the “Single Logout Binding”.

Select SHA-256 as a signature algorithm, SHA-1 has been cracked already.

Leave the remaining options as they are.

Go to the second tab “Attributes”

And defined the following assertion-based attributes:

Move to the next tab, “Groups”.

Here you will have to select a default group containing the user that will be granted access to the services inside SCP.  For our convenience and the sake of simplicity we will select a group containing all the users.  We have seen earlier in this tutorial where this group comes from.

Press Save to complete the configuration.

The configuration you have just done will delegate the user management for all the services inside the platform.  The access to the platform is still done using the {p/s/c/i}-user id and password that was provided by SAP.

Testing the setup

Go to SCPms from the SCP Services.

As you can see in the upper right corner, it is written prakalp@mic…  This user doesn’t exist in the SAP ID Service but do exists in the Microsoft AAD.  The screenshot bellow list the existing users in AAD

Acknowledgments

Special thanks to Prakalp Phadnis without whom this How to Guide wouldn’t have been put together.