- SAP Managed Tags:
Applies to SAP Cloud Platform Neo
The Challenge
For the longest of times I have ignored Basic Authentication as an option to authenticate users in an Enterprise Environment. you know the standard arguments,
"Who would ever want to use Basic Authentication in these days?"
"Surely, Everyone knows better than to use Basic!!"
...and so on. So I went on and on about Certificates and OAuth and SAML and what not, but just the other day, Hemal (a colleague) dropped a nice little bomb on my desk.
Here is a customer he says, who are huge in the US and they want to use Basic Authentication and no, we are not allowed to talk about certs or other mechanisms until this is handled!! I was aghast. However, this was also an opportunity to look into one of the lesser known authentication mechanisms, so I thought, lets make the best of it and write a how to guide to boot.
The customer has an Active Directory (AD) on-premise and want to use that as the Identity Provider (IdP). They also want to delegate the evaluation of the authentication challenge to this IdP, even from the cloud. They are building a Mobile Application that will talk to the SAP Cloud Platform Mobile Services. Eventually they see themselves leveraging SCIM to Azure AD.
The Tools
In order to reproduce this scenario we need;
- An Active Directory (AD) instance.
- A tenant in the SAP Cloud Platform with Mobile Services enabled.
- An instance of the SAP Cloud Connector (SCC).
The Steps
There are a few steps to execute;
- Configure Local User Store on the SCC.
- Create a destination on the SAP Cloud Platform tenant.
- Create an app that uses the said destination.
- Test the configuration
Simple isn't it?
1. Configure Local User Store on the Cloud Connector
The obvious need is to have connected the SCC to your SAP Cloud Platform tenant.
Once you have confirmed that you are connected to the tenant in question, we can start configuring the User Store in SCC.
It is here that we will tell the SCC where to find the users and how it is to connect to the AD.
The actual configuration screen looks like this;
| Property | Description | Comments |
| Host Name | FQDN of the AD | |
| Port | This value can be 389 for LDAP connections and 636 for LDAPS. | Global Catalogs have different ports but we are not getting into that discussion here. |
| Secure | Choose this box if you are using LDAPS | |
| User Name | This is the fully qualified username that is permitted to traverse the directory and make lookups to find the users (that shall be authenticated) | |
| Password | The password of the user above. | |
| User Path | The path to the users. | In our case, I have simply used the folder, 'Users' to create both the admin user and the user I am using for the lookup. |
| Group Path | The path to the Groups the users might belong to. | The same as above. |
This is perhaps the simplest part. We will simply use basic authentication as the authentication mechanism in the mobile app (in the Mobile Services Admin Cockpit) and at the subaccount level.
In your Cloud Platform Tenant
Create a destination with the following attributes
- Name: onpremiseumconnector
- Type : HTTP
- Desc : SCIM to LDAP
- Loc Id: <the location ID you used in the Cloud Connector>
- URL : http://scc.scim:80/scim/v1
- Proxy : OnPremise
- Auth : NoAuth
In your Mobile Services Cockpit
Under the Security Tab in your Mobile Services cockpit, choose the SCP based SCIM option and
create a destination similar to the one we created earlier.
NOTE: Location ID shall be entered if the cloud connector has been configured with one (yes I am repeating this because I spent half a day trying to debug a missing Location ID!!).
In your Mobile Services Application
- Within the Security feature of the application you have created (in this case SCIM test),
choose
- Basic from the Security Configuration dropdown.
On the Active Directory
- From the previous step you will remember that the User Path and the Group Path was set to
the root. In the screenshot above, it becomes obvious as to why we did so.
- Our ‘end user’ is located in Users which is directly underneath the domain.
No additional or specific configuration is necessary on the AD for this simple scenario.
Verifying the Config
Right, we are done with the boring stuff, now lets get authenticating against our AD. For the
purposes of this example, I am using the user ‘adtest’.
In order to simulate an application making a call to the Mobile Services, we are going to use a rest client. Here, I am using a browser plugin, but you are welcome to use whatever tool you are
comfortable in.
Before, we start, let us first ensure that there are no registrations for the user in question. In our case, I have deleted all the registrations (since it is a test app there are no consequences).
We are going to use the Registration endpoint to make a call on behalf of the ADTEST user.
We are making a POST call with Authentication = Basic
And for the Body We choose Type RAW AND place a pair of curly brackets.
Finally press Send and we should get a …….
WHAT! An error??
Of course an error. There is one dependency I have not mentioned so far (because I forgot about
it!!). Namely, the Identity Provider (or IdP).
During our configuration, we did everything except point the SCP tenant to the on-premise AD which is to be used as our Identity Provider. Now, I will not go into how to do that (as it is not the scope of this document [but you can find a nice description here]), but suffice to say that once we have
changed this configuration to point to the correct IdP, thus,
We repeat the rest call (AFTER having cleaned the cache of course), and get….
SUCCESS!!
And in the Mobile Services cockpit..
And that is how we can set up basic authentication using SCIM and LDAP with an on-premise Active Directory.
