Skip to Content
Author's profile photo Nikola Simeonov

On-Premise User Connector for SAP Cloud Applications

SAP Cloud Platform provides basic authentication and authorization services to applications running on the platform. For more information, see Securing Applications. In terms of authentication, the primary mechanism supported in SAP Cloud Platform is Security Assertion Markup Language (SAML) 2.0. If you use SAML 2.0, SAP Cloud Platform acts as a service provider (SP), and an external system acts as an identity provider (IDP). By default, any application running on SAP Cloud Platform can use SAP ID service as an identity provider. This means that any user registered in SAP Community Network (SCN) can be authenticated by SAP ID service and use the application. This can be very convenient for applications that target the SCN members. However, for applications targeting corporate business users which do not have SCN accounts, this will require creation of user accounts in SCN.

Alternatively, companies can use an IDP located in their corporate network. SAP provides its own IDP. For more information about the SAP IDP, see SAP Single Sign-On. This IDP can have direct access to the users’ identity information. The limitation in this case is that users can authenticate with the on-premise IDP when they are in the corporate network only.


SAP Cloud Platform provides a user management API (UM API) to applications since they need to access user identity information. At the moment, the application can access identity information about the currently logged-in user only. However, most business applications require searching of users by different criteria and the retrieval of user details.

Thus we have the following new requirements:

  • Users should be able to authenticate outside the corporate network.
  • Applications should be able to search for users and retrieve their details.

To satisfy these requirements, an on-premise user connector can be used. For the applications, the use of this connector is transparent. They use the same UM API to check credentials, to search for users, or to retrieve user details. The calls to the UM API lead to requests to an on-premise SAP Single Sign-On (SSO) system. These requests are sent through a secure tunnel established using SAP Cloud connector.


The authorization model in SAP Cloud Platform is based on the Java EE authorization model. The developers of Web and EJB modules can define roles in their deployment descriptors. The authorization checks can be declarative (defined in the deployment descriptor) or programmatic (implemented in the application code). The SAP Cloud Platform allows assignment of roles to individual users or to groups of users. When the on-premise user connector is used, the groups maintained in the on-premise system are automatically propagated to SAP Cloud Platform. The group information can be used to simplify the role assignment process. Application roles can be assigned to a group and then all group members have the same access rights for an application. This also allows control of user permissions directly from the on-premise system by changing the group membership.


In this example, a sample leave request application is running in SAP Cloud Platform. The application is accessed both from inside and from outside the corporate network using a desktop or a mobile client. In the SAP SSO system, each user is a member of one of the following groups: Employees, Managers, Partners, or Auditors. While the members of the groups Employees and Managers are internal, the members of the groups Partners and Auditors are external.  Only internal members are authorized to use the leave request application.


Michael is an employee and would like to request leave. He is not in the office and has no access to the corporate network. One possibility for him is to request his leave using his mobile device. When he accesses the leave request application and enters his corporate username and password, SAP Cloud Platform validates the credentials against the SAP SSO system. After successful authentication, he can request his leave.

The manager Denise is also out of the office, but she receives notifications about submitted leave requests on her mobile device. Denise has a corporate mobile device with a client certificate installed on it. This certificate is issued by the on-premise SAP SSO system, and is mapped to her user in this system. After she receives Michael’s request, Denise accesses the leave request application using her client certificate to authenticate. SAP Cloud Platform validates the certificate against the on-premise SAP SSO system and authenticates her. Denise is recognized as a manager based on her group assignment in the on-premise system. She wants to check which employees from her team are on vacation that day. To allow her to do so, the leave request application searches for employees from her team by using the UM API. This results in a call to the SAP SSO system where the information about the organizational structure is available. Denise finds that there are sufficient employees for the day and approves the request. Finally, Michael is notified about his manager’s approval.

To test this scenario, you can install the Android 4 application (.apk file) and the respective certificate (.p12 file) from the following page:

Assigned tags

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

      Great blog and awsome feature in Neo and the cloud connector.

      I assume that customers can use any Identity provider that is SAML-2.0 compliant (e.g. ADFS from Microsoft) ?

      Of course i know that it works best with SAP NW SSO and NW IDM 😉

      Author's profile photo Richard Hirsch
      Richard Hirsch


      I was going to ask the same question - I'd be interested to know if and how other IdPs can be accessed via the Cloud Connector. I assume it isn't SAML based, because SAML usage doesn't require the Cloud Connector.

      This results in a call to SAP NW SSO system where the information about the organizational structure is available.

      This sounds pretty proprietary....

      Author's profile photo Dimitar Mihaylov
      Dimitar Mihaylov

      The call from NW Cloud to the NW SSO system is based on the SCIM 1.1 protocol. Theoretically, if a 3rd party IDP supports this protocol it can be used. However we haven't tested with any other IDPs and that's why we do not yet 'advertise' this functionality to be used with non-SAP IDPs. For the moment for this specific scenario we officially support only the SAP IDP 🙂 .

      However any IDP can be used for the scenario on the first picture.



      Author's profile photo Richard Hirsch
      Richard Hirsch

      Thanks for the clarification.

      Interesting that Netweaver SSO is using SCIM since SCIM is usually assocaited with the cloud rather than on-premise IAM environments.

      Regardless -- good to know that you guys are using standards. I assume that if the customer IdP was cloud-based, you would find more possible partners.


      Author's profile photo Dimitar Mihaylov
      Dimitar Mihaylov

      Depends how you read the SCIM standard. The scenario document describes a set of flows between a Cloud Service Provider (CSP) and an Enterprise Cloud Subscriber (ECS). For example in the "SSO Pull" scenario ( the CSP retrieves identity data from the ECS.

      My understanding is that the ECS is (or at least might be) the on-premise IAM environment of a company. In our case SAP NW Cloud = CSP and SAP NW SSO / IDM = ECS.


      Author's profile photo Former Member
      Former Member

      Are there plans in the near future to extend the API to also gain access to role/group information. Right now the API only provides user information, which is ok for applications not having access control scenarios. But in enterprise applications it's a common requirement to also implement access restriction in the business layer and not only on the application container level.

      Another more simple use case is, that you want to send emails to a group of users.

      Therefore a mature API needs to include access to all users for a given group or all groups for a given user.

      Author's profile photo Dimitar Mihaylov
      Dimitar Mihaylov

      Hi Andreas,

      There are already two ways to check role assignments in the business layer:

      - if you have access to the HttpServletRequest then you can sinply call request.isUserInRole("role"). This is standard Servlet API.

      - if you do not have access to the request object then you can use the UM API of NW Cloud userProvider =; user = userProvider.getCurrentUser();

      if (user.hasRole("role")) {



      Regarding the group membership - there is such API however it is not yet public - e.g. user.getGroups(); //  returns Set<String>

      We are currently discussing if we should open this API to the application developers.

      Regarding the request to get all users from a group - this is not yet available and if we implement it then it will be very specific to the on-premise user connector because in the other cases we do not have this information. However the UM API is a generic one and it is important to have strong arguments if we decide to extend the API in such way.

      We will consider this request for our future planning. If you would like you can contact me per email to discuss it further, especially if you have a concrete user case that you want to implement.



      Author's profile photo Former Member
      Former Member

      Hi Dimitar,

      Is it possible to get list of users that has specific role assigned to them?

      Is there some API to get a list of Members of account from cloud platform and then filter out ones with the assigned role for application access?!



      Author's profile photo Charles Xu
      Charles Xu

      Does this connector work well with OAuth on the HCP? Is the connector available in XS stack?

      My JEE use case:

      OAuthAuthorization authAuthorization = OAuthAuthorization.getOAuthAuthorizationService();

      authAuthorization.isAuthorized(request, "myscope");

      // then call connector here