Skip to Content
Author's profile photo Nabi Zamani

Feature Request: Automatic User Creation on ABAP Backend in SAP Cloud Platform environments

Single Sign On (SSO) can be important for a good user experience. But how can SSO work if the authenticated user does not yet exist in the backend’s user store? SAP Netweaver ABAP has been offering a feature for quite a long time now that might not be known by everyone: Automatic User Account Creation and Update using SAML 2.0 in AS ABAP. Additional to the documentation you find also some blogs, one of my favorite blog is from December 2012: Automatic User Account Creation in AS ABAP Using SAML 2.0. This feature was introduced back then because obviously such a feature was certainly important. However, when this feature was implemented SAP was far away from having the SAP Cloud Platform that we don’t want to miss today. Just as this feature was important back then I believe such a feature becomes even more important in the context of the SAP Cloud Platform (SAPCP). In case you have an On-Premise NW ABAP it might be crucial that your automatic user creation on ABAP side keeps working if you move your (UI5) frontend from ABAP to SAPCP. Unfortunately, the automatic user creation feature mentioned above does not work in a cloud context today. In this blog I would like to share some thoughts on why such a feature keeps being relevant in the context of SAPCP. After having talked to quite a few people I hope to cause some awareness among the responsible people at SAP by writing this blog.


1. Typical SAP Cloud Platform + Portal Service + SAP Cloud Connector + On-Premise ABAP Setup

Let’s start with some basics. Thanks to SAP Cloud Connector it’s quite easy to use your existing ABAP backend in the cloud. The idea is to create a Fiori Launchpad (FLP) in the SAP Cloud Platform Portal Service of your SAP Cloud Platform’s account. After this you configure your FLP (Apps, Catalogs, Groups, Roles). Your apps will most probably communicate to the ABAP backend using OData via Destinations configured in your SAPCP account. Requests going through the destinations will then be piped through the SAP Cloud Connector (SCC) which in turn manages the calls to the real ABAP OData “Endpoint”. In a typical scenario you want to make sure that only authenticated users can access your apps in the FLP. Very often you simply delegate the authentication process via SAML 2.0 to an Identity Provider (IdP), i.e. by using SAP Cloud Platform Identity Authentication service (formerly known as SAP Cloud Identity) – in short Identity Authentication. This is how things work (simplified):

  • User call the app in the browser
  • Browser gets redirected to SAP Cloud Platform Identity Authentication
  • User authenticates there
  • Browser gets redirected back to app (details skipped on purpose)
  • App calls an OData service implemented on ABAP backend via SCC
  • SCC handles Principal Propagation to ABAP backend
  • ABAP checks the is the user calling calling the services really exists
  • OData service gets executed
  • Response is returned back the whole path up to the caller (our app)



It’s important to know that SCC does not sent the so called SAML 2.0 assertion to the ABAP backend (at least as far as I know). In other words: the connection from SCC to ABAP is not SAML 2.0 based. Instead it’s based on either x.509 Certificates or Kerberos (or “None”). For more details read this and how to set up a trust. If your configuration is correct, then principal propagation should work like a charm: “Forwarding the logged on identity in the cloud to the internal system, which means logging on with a user that matches this identity without the need of providing the password”. It’s also important to note that users must be available in the local user store of your ABAP backend (basically in SU01). Otherwise the OData requests will fail with an HTTP 401 response asking the user for credentials via Basic Authentication.


2. A sample scenario for automatic user creation incl. “On-The-Fly” user creation

Now let’s add some requirements and hints to the basic scenario from above:

  • Apps shall be accessible for anyone authenticated by our IdP, which is SAP Cloud Platform Identity Authentication
  • We have to differ between
    • Accessible in terms of displaying the apps in FLP as tiles and then the apps itself
    • Accessible in terms of calling the OData services implemented on ABAP backend
  • All users really means all users, i.e. D/C/I/S/P Users
  • SAP Cloud Platform Identity Authentication contains millions of users, let’s assume 10 million (this is not the correct number)

As you can guess the big question is: How do we get all the users available in SAP Cloud Platform Identity Authentication propagated into our ABAP backend (SU01)? If this is not possible, then we might have found a K.O. criteria for migrating our UIs into the SAPCP (assuming automatic user creation is needed!). “On-The-Fly” in this context means creating the user when needed instead of creating users upfront. Some people might prefer to call this “On-Demand” user creation instead of “On-The-Fly” user creation.

We have to answer this question because only then all SAPCP (via Identity Authentication) authenticated users are really able to access our OData services! With this we also get into discussions about privacy and SAP user licenses on ABAP side.

For simplicity we will neglect the SAP Cloud Platform Identity Provisioning (more also on the sap help sites), which allows you to manage identities centrally by granting or revoking the appropriate user privileges. By they way, here is a nice blog that you might be interested in: Identity and Access Management across SAP and Google.


3. Solving this with the old automatic user creation and update using SAML 2.0 in AS ABAP

Fortunately, in the “old” world we might have solved this requirement above by using the Automatic User Account Creation and Update using SAML 2.0 in AS ABAP. For this to work we would have to configure a few things and there are also some hard requirements to make this work (see link for details). In the end it comes to the implementation of a BADI on ABAP side, which has 2 methods:



In the implementation we can then decide whether to create the user or not according to our own business rules. And finally, we can also update a user, i.e. if the email, firs name, last name, etc. have changed.


4. What we expected to work out of the box suddenly does not work anymore

When moving our UI to the frontend we expect that the automatic user creation keeps working. However, after having tried this out and after having talked to plenty of people it’s clear that it does not work! The feature was implemented in a time without SAPCP in mind – well, maybe because it wasn’t there yet. This is basically what happens if you try things out in the cloud context:



  1. User tries to access an app on SAPCP/FLP via browser
  2. User gets redirected to SAP Cloud Platform Identity Authentication because the user is not authenticated
  3. There the user has to authenticate and afterwards the user’s browser gets redirected to the app on SAPCP/FLP again (simplified flow…)
  4. This time the user is authenticated and therefore the app shows up in the browser. Next, the app tries to call an OData service on our on-premise ABAP server.
  5. Behind the scenes the request goes through the SCC. So it get’s to SCC and SCC takes care of the so called principal propagation. In our scenario we have configured to use (short living) X.509 certificates. Thanks to this the user should not have to re-authenticate again because the ABAP server uses the certificate to logon the user that is currently calling the OData service – that’s the idea.
  6. However, in case the already via SAML 2.0 (SAP Cloud Platform Identity Authentication) authenticated user does not exist in the on-premise ABAP system (in SU01 tables…) the ABAP server will deny access even though the SCC has sent a valid certificate! That’s because the user does simply not exist in the ABAP “User Store”.
  7. As a result the ABAP server responds with an HTTP 401 error and asks the caller for credentials via basic authentication (with the HTTP Header “WWW-Authenticate: Basic”)
  8. The SCC returns the response to the user’s browser which in turn shows a basic authentication dialog.


Learning: Our SAML Automatic User Creation does not kick in. This is because between SCC and ABAP server there is absolutely no SAML (assertion) “data“ transferred (just to give you one reason).


5. Some ideas of fixing the user propagation issue (without hacks!)


I believe such a feature is quite important – especially for cloud apps for which it is not clear who will access the apps at what time. There are several option for implementation, here are some of them:


5.1 Sync User Creation via IdM/IdP


  1. User tries to access an app on SAPCP/FLP via browser
  2. User gets redirected to SAP Cloud Platform Identity Authentication because the user is not authenticated
  3. There the user has to authenticate
  4. After successful authentication the IdP/IdM creates a user on the ABAP server synchronously or if the user already exists it gets updated on the ABAP server
  5. Now the user’s browser gets redirected to the app on SAPCP/FLP again (simplified flow…)
  6. This time the user is authenticated and therefore the app shows up in the browser. Next, the app tries to call an OData service on our on-premise ABAP server.
  7. Behind the scenes the request goes through the SCC. So it get’s to SCC and SCC takes care of the so called principal propagation via X.509 certificates (or Kerberos)
  8. On-premise ABAP system finds out the user really exists in its local user store (SU01) and allows the call – that’s what we wanted to achieve!
  9. ABAP server returns the response to SCC
  10. The SCC returns the response to the user’s browser. This time no basic authentication dialog. That was the goal – SSO worked!


This option has some important disadvantages (without going into details): IdP/IdM must support this, synchronous request makes the IdP/IdM authentication take a little longer,…


5.2 Async User Creation via IdM/IdP


With this option the user is added to the ABAP server asynchronously. This means the user propagation/creation is detached from the IdP/IdM authentication of a certain user (see previous option). That also means all users are basically “replicated” from the IdP/IdM to the ABAP server whenever they are created in the IdP/IdM, i.e. in our case we would have an initial load of 10 million users to the ABAP server. After the initial load only deltas could be replicated (= synced). This approach means you would also have to think about user licenses on the ABAP server. It also means that you basically have a huge amount of users in the local user store of the ABAP server while most probably only a fraction of them will ever need to access your applications. Furthermore, this approach might lead to bas performance taking into account that the IdP (in our case the “global” Identity Authentication) might have to replicate to many ABAP servers. Also, what do all the 10 million user say if their data is replicated somewhere without being asked (privacy!)? We could even continue the list of (heavy) disadvantages of this approach.


5.3 On-The-Fly user creation via SAP Cloud Connector

This is my favorite approach and I hope something similar to this will be available soon 🙂



  1. User tries to access an app on SAPCP/FLP via browser
  2. User gets redirected to SAP Cloud Platform Identity Authentication because the user is not authenticated
  3. There the user has to authenticate and afterwards the user’s browser gets redirected to the app on SAPCP/FLP again (simplified flow…)
  4. This time the user is authenticated and therefore the app shows up in the browser. Next, the app tries to call an OData service on our on-premise ABAP server.
  5. Behind the scenes the request goes through the SCC. So it get’s to SCC and SCC takes care of the so called principal propagation via X.509 certificates (or Kerberos)
  6. On-premise ABAP system finds out the user doe NOT exist in its local user store (SU01) and and denies access with an HTTP 401 response to SCC which includes the header “WWW-Authenticate: Basic”
  7. This way the SCC detects that the user is not available on the ABAP server yet and therefore SCC now calls an API on the ABAP server that creates/updates the already authenticated user (it should forward the SAML data to the API)
  8. SCC check the response of the API call. If the call is successful it means the user was created on ABAP
  9. Now the SCC replays the initial OData call to the ABAP server
  10. This time the user exists in the local user store of the ABAP server because it was just created (creation was triggered in step 7 by SCC). Thus, the ABAP server “allows” the OData call and returns the response to SCC, and SCC in turn returns the response all the way up to the caller/browser.


So in this scenario the user creation happens On-The-Fly as soon as SCC detects that the user is not yet in the local user store of the ABAP server. I hope the idea is clear, but there are a few things that need to be clarified. Of course, it needs to be clarified how the mentioned API looks like. I would suggest an RFC CREATE_OR_UPDATE_USER with certain importing parameters for the SAML 2.0 data, i.e. userId. Email, first name, last name,… SCC could be configured to call that RFC with a certain technical user having the authorization on ABAP side to create/update users. The business logic inside the RFC depends on me as a developer. So developers would write code that create/updates the user. We could either assign default roles or any roles based on some business logic, i.e. C-Users could have more authorizations than P-Users.


5.4 Sync On-The-Fly user creation via Authentication Service, Identity Provisioning Service, and Portal Service (feature request)

The Authentication Service is responsible for authenticating the user. The Identity Provisioning Service allows to “sync” user identities from a source system to a target systems (simplified explanation). The Portal Service allows you to create your Fiori Launchpad. Doesn’t it seem obvious that these three services should work hand in hand to achieve what we want?

If a user is successfully authenticated (Authentication Service) the user gets redirected to the Fiori Launchpad (Portal Service). The Portal Service should now check if the authenticated user’s identity needs to be propagated to the ABAP user store (the tables behind transaction code SU01 in NW ABAP), maybe based on some additional rules or configuration. If the answer is yes, then the Portal Service triggers the Provisioning Service with the current user’s identity data so that the Provisioning Service creates the user on the ABAP backend on-the-fly. After this step the Provisioning Service could keep track of changes related to the synced user so that the changes can be reflected on the ABAP system as well. It’s worth discussing if the Portal Service should be involved here, i.e. maybe the Authentication Service could talk to the Provisioning Service directly. From an architectural point of view I’d say the Portal Service should not be involved in order to be more independent and more flexible for other services than the Portal Service.

This way we can even make sure sure that the user is always created on ABAP side before the FLP is displayed. That’s important because the FLP could have dynamic app tiles which call the backend as soon as the FLP gets displayed.

There is one more important challenge: What about asking users to accept the Terms of Use before they access our FLP? Well, part of this is handled somewhat by the “global” Authentication Service, i.e. if SAP’s Terms of Use change the users are automatically asked to confirm. Having some custom terms of use would be great here. In fact, this is something the Authentication Service supports today.


6. Conclusion

Currently, there is no smart way of having “on-the-fly” / “On-Demand” user creation on an on-premise ABAP system in the context of SAP Cloud Platform. I have listed some ideas that show how such a feature could work technically – but nothing more than ideas. However, the details as well as advantages/disadvantages still need to be defined and clarified among architects. I did not discuss all the details, advantages, disadvantages, etc. to keep this blog simple (or at least to avoid making it too complex).

What do you think? Does that make sense? We currently have the need of such a feature, something that is not uncommon in non-SAP environment. In fact I have made use of such an on-the-fly user creation feature in typical Java EE environments. I’d be happy to get some feedback!!! Also, feel free to correct me in case you have better ideas or if there is something you don’t agree with.

Cheers, Nabi

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mike Doyle
      Mike Doyle


      I think you’re right Nabi that SAP need to put some focus on this area. In my opinion authentication is currently the biggest source of friction in the migration to SAP Cloud Platform.

      I’m not quite sold on your suggestion being the solution though. If we step back then our problem is that the Netweaver stack isn’t ready to delegate user profiles to the IdP. I imagine that it would be a lot of work to get ECC or S/4 HANA allowing access to a user who isn’t in the user master. We certainly wouldn’t want every last authority check requiring a call to the IdP. Therefore there must be a least a ‘mini’ user master record, including a user ID and a handful of composite roles, perhaps.

      I’m not convinced that replicating all of the users is out of the question. In terms of licensing can’t we rely on providing SAP with reports showing which users were active? In terms of performance would this really be a big deal on a HANA DB?

      In terms of privacy, won’t some of these users’ data be in the system already? Otherwise why wouldn’t we just use a system-user in order to connect to the back-end system (and not create one account per IdP user)? We could create a basic-auth destination with a ‘hard-coded’ user ID for this (although we would need to control access to this destination).

      Your auto-created user accounts would have to be short lived, otherwise changes made in the IdP would need to be replicated into the back-end user store. If we are going to do that then we might as well just replicate all of the users.

      To summarise I think you have some good points but you just need to convince me that the alternatives (replicating all users or using a system user) aren't tenable.

      Author's profile photo Nabi Zamani
      Nabi Zamani
      Blog Post Author


      Since the day I wrote this feature request I have received about a dozen contact requests from SAP customers who asked me things like “How did you solve it?”, “Is there any progress?”, “Is this really/still not possible?”, etc. Some even approached me on conferences and asked me about this topic. So we’re not the only ones longing for more attention on this topic… Maybe I thought writing this “Feature Request” on my birthday would start at least some serious discussion in order to support certain scenarios. Having that said, I agree with you that this topic is important for any cloud transition/migration. Correct, we need what you called a “mini user master record” created in SU01.

      Replicating all the users is not really a solution. Let me try to convince you somehow. Firstly, let’s assume you have a web app including ABAP server powered by HANA (of course). Now you want to replicate all users from Facebook, Twitter, LinkedIn. You would end up with let’s say 3 billion user records during the initial load. Would you really want to do that upfront? I’m pretty sure Facebook, Twitter, and LinkedIn would not let you do that, also because of privacy. That’s why we have OAuth, right? After the initial load of 3 billion records, we would need a mechanism to receive delta updates. The HANA DB etc. is not the issues here. The issue is that there is a lot of I/O, meaning bytes over the wire, and there is some logic needed on both sides. Still not convinced? Turn around and think from the point of view of Facebook, Twitter, LinkedIn: If they offer you such a full blown replication feature, they will most probably offer it for others as well. Now think about all the systems worldwide that would also use such a replication. That suddenly increases the overhead a lot, right? I still believe the full replication is neither viable nor really feasible.

      Now let’s go back to our “SAP” Scenario. What I expect is that all users who can authenticate with the SAP Authentication service (and there are a lot) must be able to access my SAP Systems. If other SAP devs have the same requirement then in the end we’re suddenly talking about a huge overhead for initial load + syncing. Also, syncing millions of millions of records seems to be a bad idea if not every user will try to access your SAP ABAP servers… In terms of licensing we could have reports. But why not keeping it old fashioned and simple and run without reports (SAP customers + admins like to have control over the licenses)?

      My preferred solution is something I call a “hack” because it needs custom code:

      • Create an FLP Plugin for your SAPCP powered FLP
      • Implements a custom (Java) service called by your FLP plugin (i.e. some kind of “createdOrUpdateCurrentUserOnAbap”).
      • Implement an RFC on ABAP which userId, email, etc. as importing parameters and created or updates SU01 (i.e.CREATE_OR_UPDATE_SU01_USER)
      • When users access the FLP then the SAPCP service connects to the RFC (via destination + with a technical user) in order to create/update the user on ABAP

      There are some other details/improvements not mentioned. Anyway, this works somewhat, but it’s not perfect because it has drawbacks:

      • You cannot be sure when the FLP plugin gets loaded – no configuration possible!
      • You cannot even configure some kind of an upfront service which is called before the rest of the FLP procedures take action.
      • Conclusion
        • If someone opens an app directly for the first time (i.e. via bookmark, link in email form friend,…) then the app might call an data service before the RFC was called
        • Users gets an error
        • User has to reload and then everything will be fine (assuming the RFC call made it)

      What do you think?