Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
NabiZamani
Contributor
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:

  • IF_SAML20_USER_CREATE_UPDATE~CREATE_USER_TO_FEDERATE

  • IF_SAML20_USER_CREATE_UPDATE~UPDATE_FEDERATED_USER


 

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
2 Comments
Labels in this area