Skip to Content
Technical Articles

Auth0: Log in to BTP with your social accounts.

The recent acquisition of Okta (Auth0) caught my attention. Until last week, I didn’t know Auth0 beyond the libraries they provide for JWT. Upon further investigation, I was pleasantly surprised to discover that they are a company that was born in Argentina in 2013 and that their founders are passionate developers (When was the last time you saw a CEO of a $6.5B company pushing his codes to Github and blogging about his hobbyist Arduino projects? #respect).

Auth0 provides a solution to add authentication and authorisation to applications and I decided to explore their services. It was very fun to do so and I documented the steps because I found no other blogs talking about Auth0 integration with SAP BTP.

One of the features of Auth0 is that it supports the SAML standard which, in turn, is also supported by BTP. In this community, there are excellent blog posts on how to configure MS Active Directory as an IdP for BPT using SAML.  See these examples:

Author Post
Lucas Vaccaro how-to-integrate-azure-ad-with-sap-cloud-platform-cloud-foundry
Murali Shanmugham // Murali Shanmugham integrating-identity-authentication-service-azure-active-directory-in-sap-cloud-platform-proxy-conditional-authentication-scenarios
Denys van Kempen sap-business-technology-platform-security-hands-on-video-tutorials

The idea of this post is to explain in a concise way, how to use Auth0 for user authentication and management including social connectors to authenticate with third parties such as Github, Google, Microsoft, Salesforce and a long etc. The post is documenting the steps for the CF environment, but the process is “similarish” in Neo.

At the end of this post (which I will split into three parts), BTP will accept through Auth0:

  • Sign-up
  • Log in to CF apps/subs (Like SIS/CPI – BAS)
  • Social Account Integration
  • Multi-factor authentication / One Time Password (MFA / OTP)

TDLR: If you don’t want to read the whole post, this is the summary:

  • In Aut0
    • Create an account (Free tier available with some limitations)
    • Create an application
    • Configure the SAML2 Addon
    • Adjust the mapping of the claims:
      • first_name, last_name, mail and Groups (with capital G)
    • Enable user sources. In the example: Auth0 internal DB and GitHub.
    • Enable the “confetti” (Captcha, MFA, etc).
  • In BTP (CF)
    • Add Aut0 as IdP (Trust Configuration)
    • Map BTP Roles with data delivered in the assertion token.

 

 

Let’s get started.

 

1.- Create an app

Opening an account on Auth0 is very simple, so I will move straight on to creating an application. In this case, my application will be called “BTP-EU10-TRIAL”. I may be wrong, but I didn’t find any difference in choosing different types of application, so I chose “Native”.

Create%20App

 

2.- Configure URLs

In the “Settings” tab and under the “Application URIs” section, we configure the URIs that will be used for the authentication process (the URLs I document are based on a trial account, hence they will be different in a paid account).

We will pause the configuration of the application in Auth0, to get these URLs from BTP. The simplest way I found, was to download the SAML metadata directly from BTP and snoop on the default configuration.

BTP Cockpit -> Security -> Trust Configuration: Download SAML Metadata.

From this file I retrieve: the attribute “entityID” of the root element (xpath: /*/@entityID ) and the “Location” attribute of the AssertionConsumerService element.
( Xpath /*/*/*/*/*/@Location[contains(.,’SSO’)] )

 

Then I use these URLs in Auth0

 

 

3.- Enable the SAML addon.

In the “Addons” tab, we activate the plugin for SAML. The configuration requires knowledge about SAML, but you can use the configuration example below. The key is to understand that we need to configure a JSON document containing the rules with which the token and its claims will be created. At this point, it is possible to do a mapping between SAML attributes and user data. Nevertheless, we will not configure the mapping here, as we need some more advanced rules to assign roles to the users.

 

You can use this JSON as an example (replace and verify the data marked with XXXXX).

{
  "createUpnClaim": false,
  "passthroughClaimsWithNoMapping": false,
  "mapUnknownClaimsAsIs": true,
  "mapIdentities": false,
  "signatureAlgorithm": "rsa-sha256",
  "digestAlgorithm": "sha256",
  "lifetimeInSeconds": 36000,
  "destination": "https:// XXXXX.authentication. XXXXX.hana.ondemand.com/saml/SSO/alias/XXXXX ",
  "signResponse": false,
  "typedAttributes": true,
  "includeAttributeNameFormat": true,
  "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified",
  "logout": {
    "callback": "https:// XXXXX.authentication. XXXXX.hana.ondemand.com/saml/SingleLogout/alias/ XXXXX. ",
    "slo_enabled": true
  },
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ]
}

4.- Exporting the IdP Metadata.

Save and download the file with the IdP metadata from the “usage” tab.

 

5. Temporarily disable the Google user source

The reason is that to work correctly with SAML, it is necessary to create your -own- App in GCP. I will present something similar whit GitHub later in this post.

6. Create a SAML attribute mapping rule.

This step is necessary to associate data from the users created in Auth0, with the claims that BTP needs.
Although it is possible to send many attributes in the claim data, SAP documentation mentions that only a few fields are considered: first_name, last_name, mail and Groups. (Note that the G for groups is a capital G… for some reason 🤷‍♂️).

In the left menu, select “Rules” and create a rule of the type “SAML Attribute Mapping”. You can use the example below.

 

function mapSamlAttributes(user, context, callback) {
  context.samlConfiguration.mappings = {
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier":
      "email",
    "mail": "email",
    "first_name": "given_name",
    "last_name": "family_name",
    "Groups": `app_metadata.${context.clientName}.groups`
  };
  callback(null, user, context);
}

 

At this stage, the application should now be able to receive logins. Now, let’s configure BTP.

7.- BTP Trust Configuration

BTP Cockpit -> Security -> Trust Configuration -> New Trust Configuration. We upload the SAML metadata file generated in point 4. Here we adjust some minor details and… done!

 

8.- First Test

Let’s test our configuration, by self-enrolling a user and log in using Auth0. In the example, I am opening the SAP Integration Suite.

It works! The user has been self-registered and authenticated. In fact, the user is already accessing the Integration Suite. However, and as you probably know, authentication != authorisation. The user can log in but doesn’t have the rights to do anything in SIS because it has no associated roles yet. (Note: for this post, I haven’t disabled the self-enrollment option nor created a user acceptance flow. Both cases are very well documented on the Auth0 site).

 

9.- Assigning roles to the user

To understand one way to assign roles to the user, let’s take a look at the user created in Auth0.

 

In step 6, one of the rules programmed was to associate groups based on the groups we assign to the user in their profile, based on the “app_metadata” object. At the moment, this object is empty for the created user. We can assign the roles, following the example below.

{
  "BTP-EU10-TRIAL": {
    "groups": [
      "SIS_Admin",
      "BAS_Developer"
    ]
  }
}

Note that the name of the Auth0 application is a key to access the groups, the groups can have the name you deem convenient, but they must be associated with Roles collections in BTP (next step).

10.- Associate BTP Roles Collections with Auth0 groups.

In BTP, the association is done within the IdP configuration.

BTP Cockpit -> Security -> Trust Configuration : Select your new IdP -> Role Collection Mappings. In my example, I associate the Auth0 Groups “SIS_Admin” with Some SAP Integration Suite Roles and “BAS_Developer” with a BAS Role Collection.

 

Once we associate the Auth0 groups with the BTP roles collection, the user can be authenticated and authorised. It works like a charm. 🙂

In this second part of the post, I will add the option to log in to BTP with a social connector (GitHub) and I will enforce MFA.

 

11.- Enable GitHub Integration

In Github, you will first need to create an Oauth App. Account settings-> developer settings -> Oauth App.

Depending on the name and region you have chosen for your Auth0 tenant, you will have to adapt GitHub’s URLs. The format is this:

https://YOUR_TENANT.REGION.auth0.com
https://YOUR_TENANT.REGION.auth0.com/login/callback

With your client created, you can now finally configure Auth0.

 

Let’s test once more self-enrolling yet another user trying to log in to CPI.

 

Perfect!… Once again we have authenticated the user, but it has no role assigned to him. Let’s have a look at the created user:

Following the same approach of point 9, we manage to assign access to CPI:

 

It is worth mentioning that social connectors have a particularity. As the users’ data source can be different for the same email address, the internal id of the user in Auth0 will be different as well. The only thing that can link them is their email account. It can be a problem to have different userids, depending on the source of the data as in the end, the userids belong to actually the same person. To solve this, there is an Auth0 extension that links different emails to a single user. I won’t be explaining this, as I did not fine-tune the implementation and found some inconsistencies, but I want to make you aware of the feature.

 

12.- Multi-Factor Authentication – One-time password.

It can be annoying, as forces you to have an external app to authenticate and makes the practice of user sharing more difficult. But at the end of the day, MFA adds a lot of security. Infosec loves it. Enabling and forcing it in Auth0 is a matter of clicks.

Security -> MFA -> OTP -> Enable

The policy can be enforced.

Once enabled, the next login would ask to set up the OTP using any TOTP app that supports the RFC 6238. In the example, I use “Authy”.

 

Final words

I didn’t know Auth0 until a few days ago, but after exploring it, reading its documentation, seeing its community and feeling great admiration for its founders, I have come to respect and appreciate its proposal. Following the steps of this post should

It is true that SAP has a variety of products that perform similar tasks (Customer Data Cloud for example), other hyperscalers also have their own options. It’s not my intention to compare them or make a “VS”, but I consider it beneficial to be able to bring third-party tools that complement the SAP ecosystem with an open vision and a growing number of followers.

Following the instructions in this blog could take as little as an hour, I hope it can help you speed up the learning curve. However, devising and implementing a serious authentication strategy for BTP will undoubtedly be a much bigger challenge.

1 Comment
You must be Logged on to comment or reply to a post.
  • Thanks, Ariel Bravo Ayala for such a nice step-by-step blog. TBH, before reading the blog, I haven't even heard of the Auth0(just like you) but while implementing this in the trial account for BTP, I realized it is such a powerful tool to integrate/manage user authentication along with a social connection for SAP Application, most prominently SAP BTP applications.

    Keep sharing!

    BR
    Saurabh