| Author | Post |
| lucasvaccaro | how-to-integrate-azure-ad-with-sap-cloud-platform-cloud-foundry |
| murali.shanmugham // muralidaran.shanmugham2 | integrating-identity-authentication-service-azure-active-directory-in-sap-cloud-platform-proxy-condi... |
| denys.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 user management in BTP, using social connectors to authenticate users using third parties Identity providers 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". Different grant types are recommended based on the application type. For this example, we can use a "Regular Web App".
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.
 | |
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
Auth0 enables users to single sign-on for applications running on various platforms, like SAP's BTP, with various identity providers; add few lines of JavaScript to power their applications; customize various stages of the authentication and authorization pipeline, and connect their applications and APIs to their database of users and passwords. I hope this blog helps a bit explaining one use case where Auth0 fits in the SAP ecosystem.
Edit: 31/08/2021 A few months after writing this article I applied and became a collaborator at Auth0 as I really liked their values. This post reflects the understanding I had then about the platform. Opinions are my own.
- SAP Managed Tags:
2 Comments
