Skip to Content

This is part 3 of my blog series about cloud architecture on SAP Cloud Platform. You can find the overview page here.

In my previous blog about user management, you learned about the different identity providers and user types that are typically involved when it comes to productive SAP CP scenarios. After the theory from the last blog, I now want to explain how all this can be configured and used in practice with SAP CP.

First of all, I argue that there are three use cases when it comes to application users:

  • Internal: All users of your SAP CP application are internal users of your company/client.
  • External: All users of your SAP CP application are external users (not counting developers, support users, project leads). This scenario is typical if you develop an application for your own customers (which are most often not part of your company’s internal user management, e.g. an LDAP), your partners, or completely external individuals on the internet.
  • Hybrid: Users of your SAP CP application could either come from your internal company, or from your external customers, or partners, or completely external altogether.

For the internal use case, you most probably already have all users in some kind of corporate user store/ corporate identity provider. It could be a company’s LDAP, SAP User Management Engine, or a Microsoft Active Directory. In this case, your easiest and most structured approach would probably be to securely integrate this user management with your SAP CP Sub-Accounts so that internal users can access SAP CP applications with their normal users and passwords. I am sure that most internal end-users will expect this to work. Also, in my opinion, it results in a much cleaner architecture if you manage all your internal users in one central location and not in an internal system for internal user cases and in an external cloud identity provider for your cloud use cases.

In my SAP CP projects, I made particularly good experience integrating corporate user managements via SAML endpoints. Microsoft’s Active Directory Federation Services (ADFS), for example, allows you to expose your Active Directory users via a SAML 2.0 endpoint. Integrating such a SAML endpoint with SAP CP is straightforward and a very secure and standardized approach to allow your internal users to access your cloud applications. It’s also easy to not only verify users identities’ (authentication) with such a SAML endpoint but you can also publish user group information via SAML assertion attributes and therefore also conduct parts of the authorization process via SAML. I will write about the details of user groups, roles, and permissions in a later blog but in short: with SAML assertion attributes you can expose a user’s group membership with the SAML endpoint and reuse all your company’s group definitions from your central user management into the SAP CP. Very convenient…

For the external use case, I would recommend to use a SAML identity provider. SAP, for example, offers a SAML identity provider (SAP Cloud Platform Identity Authentication or in short, SCI). I would certainly recommend giving SCI a try for your projects as SCI can be tightly integrated with SAP CP. However, SCI is not part of SAP CP and in principle, every other SAML identity provider will also work. Managing external users in an identity provider that is not inside your corporate network has many advantages:

  • For projects that should be delivered within a short timeframe, integrating with SCI can be much faster than getting the AD-administrators to configure their ADFS correctly.
  • You do not have to expose your Active Directory “publicly” via ADFS. Although it is a common thing to do and from what I have seen, security colleagues were always fine with that, but it could be that your company does not want ADFS SAML endpoints that are accessible from the internet.
  • Especially for the external use case where you have users, who you most likely don’t want to maintain inside your corporate AD, an external SAML identity provider helps keeping your corporate identity management “clean”.

Now, most interesting, of course, is the hybrid scenario. Here, you have an application that is accessed by external users and internal users alike. Of course, you do not want to copy or replicate all internal users from your corporate identity provider to your SCI tenant (trust me, a single source of truth for your user information is a very convenient thing in contrast to constantly syncing different identity providers). On top of that, you probably don’t want external users in your corporate identity provider. So ultimately, you’ll want to maintain external users in SCI and your internal users in your corporate user management. In order to keep maintenance effort and cost as low as possible, you should integrate both identity providers to your application’s HCP Sub-Account. In the Cloud Cockpit under Security -> Trust, you can add multiple trusted identity providers easily. Of course, the SAML assertion attribute mappings will be different (we cover this in the next blogs), but you can reuse the same SAP CP user groups (Security -> Authorization) for all trusted identity providers. Once you added both identity providers to the Sub-Account, your external users could use SCI for authentication (and authorization) and your internal users could access the SAP CP application with their “normal” user names from the internal network.

The only small downside of this approach is the following: you’ll have to use an URL parameter in order to control which identity provider is used for the authentication. You can configure one identity provider as the default so if no parameter is specified, this identity provider is used. I typically set SCI as the default identity provider so that external customers can use the simpler URL without the parameter. Internal users will then have to access the application URL with the URL parameter “?saml2idp=<Name of the corporate identity provider>”. From my point of view (and my customers’ points of view until now), this was always an acceptable restriction.

Before we look at the final architecture recommendation, let’s go one step further in terms of controlling your two identity providers. Let’s assume an internal user wants to access a SAP CP application while he or she is on the move and not within the corporate network. Of course, the SAML authentication will redirect the user to the publicly available SAML endpoint for authentication which is exactly what you want. But an internal user who wants to access the same HCP application while sitting in the office (and therefore the internal network), will also be forwarded to the public ADFS endpoint. In case you do not want that, here is a neat trick: Just modify your internal DNS configuration so that the URL of the public ADFS endpoint is routed to the ADFS not via the internet but directly to the ADFS via the internal network. Obviously, with this setup, you do not leave your internal network for authentication which would be a bit odd if you are already inside the corporate network. Also, internal users can therefore use the same URL in every network.

So let’s look at my recommendation:

The external user (red) is authenticated against the SCI. Internal users who are in the office are authenticated against the internal endpoint of your ADFS so the authentication communication remains internal in the company. Internal users who are currently not inside the internal network are authenticated against the public ADFS endpoint without having to use a different URL.

A trusted identity provider is normally used for multiple applications at the same time. Ideally, you have as few different identity providers as possible. If you then have multiple SAP CP Sub-Accounts for multiple projects, of course, those Sub-Accounts will be connected to the same identity provider tenant. I would give you the following recommendations:

  • Because of the fact that the identity provider is used by multiple applications, it should not be managed by the development teams of the individual projects. You’ll need to involve the IT services of your company and let them manage the cloud identity providers. Just as you already do it with the corporate identity provider (you wouldn’t give edit permissions to your Active Directory to the SAP CP project team, so then don’t do it for the cloud identity provider either).
  • You can also receive a second SCI tenant from SAP for your non-productive landscape. It could be a good idea to maintain two identity providers to separate productive and non-productive use cases. You could then maybe also give more permissions to the project teams on the non-productive SCI tenant.

A possible landscape could look like this:

One last use case I have not told you about is that you could also add a SAML identity provider from a third party. So let’s assume you build an application for your customers and deploy it to SAP CP. But maybe, you do not want to manage the users yourselves or you want to give your customers the opportunity to manage users of the application by themselves. In these cases, you can simply integrate your customers or partners SAML identity provider with your SAP CP Sub-Account so that users who already have an account on those identity providers and who are already managed there can directly use your SAP CP application.

One last remark: There are other ways to integrate your internal user management with SAP CP. You can try to integrate the Active Directory directly via the Cloud Connector or also SCI can be connected via a reverse proxy to your corporate identity provider. Also, SCI features some methods like SPNEGO and other integrations so that you could also integrate your user management without a public SAML endpoint. In practice, however, I always struggled with the complexity of those approaches and as a public SAML endpoint is state-of-the-art in my mind (just take accounts.sap.com as an example), I would recommend this approach to you. Also, authentication and authorization are very critical steps and the more complex your approaches are, the more likely you create potential security issues… simplify!

I hope this blog helped you in understanding how to use the different identity providers in practice. In the next blogs, I will explain how roles, permissions, and groups work on SAP CP and how that influences your application from a software architecture perspective.

Stay tuned and let me know your thoughts on the recommendations for this article!

Cheers, Merry Christmas and a Happy New Year to all of you!

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Mike Doyle

    Thanks Jakob for sharing your experiences. Customers can get up and running quickly with HCP but the identity provider approach needs some careful thought, I think

    (0) 
    1. Jakob Moellers Post author

      Hi Mike,
      I think they can also get started with the combination HCP + SCI quickly as SCI is already setup by SAP and ready to be used once you receive your productive HCP Account.
      Nevertheless, of course you should put some thought into it before deciding to use SCI… which is not a “problem” of SCI but just a general question concerning your company’s cloud strategy. If you ONLY plan to have internal use cases and you have a working ADFS in place, I would recommend to use it and not import/synchronize to your SCI tenant.
      However, for a quick start, consider using SCI. You might find discussions with AD/ADFS departments quite time consuming and not every customer starts with a global HCP landscape strategy in mind but more with a few projects on their cloud journey… for this, SCI offers a really smooth start. The nice thing is you can switch identity providers quite easily at runtime and introduce/remove IdPs without changing the application coding. So there’s room for trying things and gaining experience.
      Best regards,
      Jakob

      (0) 
  2. Chandrababu Katta

    Hi Jakob,

    Nice explanation on all the things and approaches regarding Idps in HCP. I am following your blog series and looking forward to get the answer for my scenario which we are struggling to fix for our client.

    Here is the scenario: We are developing an Offline Mobile App to our client using HCP , Odata Provisioning, Hana Cloud Connector & Service calling from the Backend R3 system (I briefed here simply, the attachment gives you the clarity) and our client using Kerberos based authentication to access the R3 System (i.e he is using Windows AD users to access their SAP Systems). But where as coming to o like accessing this mobile application he needs a single sign-on approach (i.e the same windows user can be logged in to the HCP, HCPms and consume backend service from the R3 system).

    Can you please let us do you have any idea on how to configure this single sign-on approach (Or) do you have any plans to write regarding these approaches in coming blogs?

    Thanks,
    Chandrababu
     

    (0) 
    1. Jakob Moellers Post author

      Hi Chandrababu,
      thanks for your comment and explaining your scenario. I did not plan to cover this in the blog series as it’s a very specific topic and I currently do not have a system environment to really test this entirely.
      Does the link that Manju mentioned help for your scenario? I would also recommend reading through this related help page:
      https://help.hana.ondemand.com/help/frameset.htm?a4ee70f0274248f8bbc7594179ef948d.html
      Here, it’s explained how you can configure the trust so that the Cloud Connector trusts your on-demand applications from the cloud and then requests Kerberos tickets from the KDC. As you obtain all your user information from the same Active Directory, identity forwarding should be possible like this. Keep in mind that the trusted application in your Cloud Connector has to be your “Odata Provisioning” application as it’s the one that is communicating with the Cloud Connector if I understand your picture correctly (compare the link I just posted where this is explained as well).
      Let me know if this helps you with your scenario or if I did not get your question correctly.
      Best regards,
      Jakob

      (0) 
  3. Parag Jain

    Thank you for the wonderful blogs Jakob, these are very useful and document very rich experience.

    One comment on the landscape diagram, wherein Project A and Project B are connected to same SCI Tenant.
    Sometimes users in Project A shouldnt be able to access Project B assets. If they are part of same SCI tenant, then technically the would be able to open the assets / launchpad (can be blank if they dont have roles) across projects.

    To prevent this completely, we are using Risk based authentication concept of SCI. We have created “dummy” SCI user groups for each sub-account (Project A and Project B in this case) and assign this to the respective users besides the project based roles / groups. Now, user in project A will not be able to even open Project B assets / launchpad, etc.

    Hope the above helps.

    Regards,
    Parag.

    (0) 
    1. Jakob Moellers Post author

      Hi Parag,
      Thanks for your comment and reading the blog!
      I think I don’t understand your concept completely. Let me comment:
      – I completely agree, application users of project A should not be able to open anything from project B and vice versa per default
      – Using the same SCI Tenant in my opinion does not allow you to open applications from another HCP account: In the application descriptors of your applications, you should always check which roles give you access to certain parts of your application and also to your application as a whole. If you as an application user only have roles from project B, then opening an application from project A should not be possible at all if the application descriptors and roles are configured correctly.
      I think your “dummy SCI user groups” are therefore the same as if you declare in the application descriptor that access to the application (root-path) is not allowed without at least one of the project roles/groups. I therefore do not see how risk based authentication helps you in this context… or did I not get you correctly? Maybe you can just explain it again 🙂
      Thanks and best regards,
      Jakob 

      (0) 
  4. Manju Venkatesha

    @Chandrababu Katta.
    if I understand your requirement correctly, you want to enable SSO “Principal propagation” to backend using  Kerberos  token. Since your using the cloud connector which enables you to propagate users authenticated in SAP HANA Cloud Platform via Kerberos against back-end systems.

    Please refer below link for further details on Cloud Connector configuration.
    https://help.hana.ondemand.com/help/frameset.htm?f2339d896587464ab703564fd687dfde.html

    Regards
    Manju

    (0) 
  5. Simen Huuse

    Thank you for your insights, Jacob.

    Do you have any thoughts on how to use an ABAP system as identity provider for HCP? So far, I have found the HCP Provisioning Service and the Single Sign-on using NetWeaver Java. I was hoping there was a way of setting up an ABAP system as trusted identity provider directly, without the Provisioning Service and definitely without the NetWeaver Java Application server. 🙂

     

    Cheers,

    Simen

    (0) 
    1. Jakob Moellers Post author

      Hi Simen,

      sadly I am not aware of a method to use an ABAP system as identity provider for HCP without additional implementation/services.

      Kind regards,

      Jakob

       

      (1) 
  6. Pranav Gupta

    Hi Jakob,

    Thanks a lot for the insights, very helpful indeed.

    A pretty elementary question from my end for usecases where we decide to use our internal identity provider – as I understand the on trying to add the identity provider from the cockpit, we should also provide the “Single Sign-On URL“. For internal IdP, this would refer to a internal hostname that is ideally not accessible from the internet. In such a scenario, how would calls from the internet route calls to this custom Identity provider ?

     

    Regards,

    Pranav

    (0) 

Leave a Reply