Goal

This blog shows a possible approach of dealing with multiple LDAP servers through SAP Mobile Platform, i.e. stacking multiple LDAP Authentication Providers.

Note: the other common approach among the stacking one is the usage of an LDAP Load Balancer, but this approach is not documented in this blog.

Basics

SMP 3.0 OData Runtime uses the javax.security.auth package for authentication that lets the SMP administrators to assign an authentication method to an application without modifying the code of the app. In SMP it’s possible to assign multiple authentication methods (authentication providers) to an application via a security profile. SMP will go through in this stack of authentication providers according to their order, properties and the result of the recent authentication provider.

Stacking multiple LDAP Authentication Providers

The exact steps:

     I. Creating a Security Profile
          1.) Adding Authentication Provider(s) into the Security Profile
          2.) Mapping the existing physical roles of the users to SMP’s logical roles
     II. Defining the application in SMP
     III. Testing

I. Create a Security Profile

1. Open the SAP Management Cockpit.
2. Login with Admin privileges.
3. Go to Settings.
4. Choose Security Profiles.
5. Click on the “Create a new security profile” button.
6. Name it to for example “2LDAP“.

     1.) Add Authentication Provider(s) into the Security Profile

1. Click on the “Add item” button.
2. Choose the Directory Service (LDAP/AD).
3. Fill in the needed fields:
   • Set the Control Flag to sufficient, this means that if the authentication succeeds then the authentication process is stopped, and the control is given back to the app, but when it fails then the authentication continues and it’ll try to authenticate with the second authentication provider.
   • The values should be dictated by the company’s LDAP team, but here are a few highlights:
     • Set the provider URL to the URL of one of the LDAP providers.
     • Don’t forget to use different bind DNs and passwords for the different LDAP servers (assuming that one user is maintained in only one server).
     • When the Authentication Search Base and the Role Search Base has the same value then rather use the Default Search Base option at the Advanced tab.
     • For initial setup and troubleshooting, use the “Enable LDAP Connection Trace” option which will create .ber files in the <SMP_HOME>/Server/Work/tmp folder. This will help to identify the server where the user was authenticated. See examples at the Testing part of this blog.
4. Click Save.
5. Repeat the steps from the 7th until the 10th as many times as many LDAP Servers are needed to be used for Authentication via SMP. (Use the URL of another LDAP Server this time and another BindDN).
6. Click Save again and receive message: “Authentication provider updated successfully.”

     2.) Map the existing physical roles of the users to SMP’s logical roles

1. Choose the security profile what is just being created and choose Role mapping.
2. Choose the needed Logical Role and click Edit.
3. Check the needed Available Physical Roles to be Mapped Roles.
4. Click on the “Create a new logical role” button and enter the value dictated by the company’s LDAP team.
5. Assuming that the roles on the different LDAP servers don’t have the same name, repeat the 4th step for the other physical roles.
6. Check the just created physical roles too to be Mapped Roles.
7. Click Save.

II. Define the application in SMP.

This is a well documented part of SMP so let me just quickly go through the steps:

1. Open the SAP Management Cockpit.
2. Login with Admin privileges.
3. Go to Applications.
4. Click on Create Application (or on Import button if you have the exported version of the app from another system).
5. Fill in the needed fields and choose the Security profile created in the I. paragraph of this blog (what we called: 2LDAP).
   • Note: LDAP is a basic authentication form, therefore all of the available application types are supported with it.
6. Click Save.
7. Define the additional important properties of the app e.g. backend connection, push, offline etc.

III. Testing

How could we make sure that everything is working as expected?

1.) BER file examples

As mentioned above if we use the Enable LDAP Connection Trace option, then ber files are generated during the authentication. A BER file shows the authentication flow between the SMP Server and the LDAP Server.

When the authentication fails then similar entries are visible in the BER file 

-> LDAPServer1:389
 //<hexadecimalValues>  <BindDN> <BindPassword>
 1A 2B 3C 4D 5E 6F      ...CN=<CN>, OU=<OU>,
 7G 8H 9I 0J 1K 2L        DC=<DC>, <passwordAsPlaintext>

<- LDAPServer1:389
 //<hexadecimalValues>
 1A 2B 3C 4D 5E 6F      ...0
 7G 8H 9I 0J 1K 2L

-> LDAPServer1:389
 //<hexadecimalValues>  <BindDN> <BindPassword>
 1A 2B 3C 4D 5E 6F      ...CN=<CN>, OU=<OU>,
 7G 8H 9I 0J 1K 2L        DC=<DC>, <passwordAsPlaintext>

<- LDAPServer1:389
 //<hexadecimalValues>
 1A 2B 3C 4D 5E 6F      ...0
 7G 8H 9I 0J 1K 2L

Notice the followings:

• There are arrows (<- or ->) at the beginning of the sections, which shows the direction of the given message (from SMP to LDAP: ->, from LDAP to SMP: <-).
• SMP is sending the same message which indicates that the authentication failed on this LDAP Server.

When the authentication succeeds then similar entries are visible in the BER file

-> LDAPServer1:389
 //<hexadecimalValues>  <BindDN> <BindPassword>
 1A 2B 3C 4D 5E 6F      ...CN=<CN>, OU=<OU>,
 7G 8H 9I 0J 1K 2L        DC=<DC>, <passwordAsPlaintext>

<- LDAPServer1:389
 //<hexadecimalValues>
 1A 2B 3C 4D 5E 6F      ...0
 7G 8H 9I 0J 1K 2L

-> LDAPServer1:389
 //<hexadecimalValues>  <AuthentiactionSearchBase><AuthenticationFilterWithBindDN>
 1A 2B 3C 4D 5E 6F      ...OU=<OU>, DC=<DC>
 7G 8H 9I 0J 1K 2L        sAMAccuntName..<User>..objectclass..user

<- LDAPServer1:389
//<hexadecimalValues>  <BindDN>
 1A 2B 3C 4D 5E 6F      ...CN=<CN>, OU=<OU>,
 7G 8H 9I 0J 1K 2L        DC=<DC>

<- LDAPServer1:389
//<hexadecimalValues>  <BindDN>
1A 2B 3C 4D 5E 6F        ...0
7G 8H 9I 0J 1K 2L

-> LDAPServer1:389
//<hexadecimalValues>  <RoleSearchBase><OtherPropertiesForRoleComputations>
1A 2B 3C 4D 5E 6F        OU=<OU>, DC=<DC>, <RoleMembership>, <RoleFilter>
7G 8H 9I 0J 1K 2L

<- LDAPServer1:389
//<hexadecimalValues>  <RoleSearchBase><OtherPropertiesForRoleComputations>
1A 2B 3C 4D 5E 6F        <EveryRole>, <EveryMembership>
7G 8H 9I 0J 1K 2L

Notice the followings:

• SMP is narrowing down what it wants to know from the LDAP Server step-by-step i.e. it’s sending the properties that we configured.

2.) Debug logs

The first thing that we should check every time when an authentication issue occurs or when we would like to better understand the flow of something is the SMP Server log with the Security log component on Debug log level. To do this:

1. Open the SAP Management Cockpit.
2. Go to Logs.
3. Go to Log Settings.
4. Set the Security component to Debug Log Level.
5. Save it.
6. Note the time.
7. Reproduce the issue/ phenomenon.
8. Go to Logs.
9. Go to Log Files.
10. Click on the <hostname>-smp-server.log file from the SAP Mobile Platform Server Log section.
11. Open it.
12. Scroll to the timestamp, what was noted at the 6th step and see the flow of the happenings.

3.) CSI Tool

CSI or Common Security Infrastructure is used by SMP to be able to conform with Java JAAS i.e. be able to work with the available authentication providers.

The usage of CSI Tool is well documented in the following SAP Blog by Jyothi Krothapalli: Debugging Authentication Errors with CSI Tool