In this blog we will look at the Server side security aspect of SAP HANA Cloud Integration

Server Side Security Concepts

In order for a TLS/SSL communication to happen it is mandatory the service provider (server) is able to support communication over HTTPS (usually achieved using some type of cryptographic library). Server is able to provide a certificate that can be trusted by the client. Server also tells the client for a particular service if it supports basic authentication, certificate based authentication or both(where first a valid certificate is requested and if a valid client certificate cannot be found then server switched to alternated method of authentication which is basically basic authentication).

An additional concept that we should keep in mind is usually a server is never exposed to outside world directly rather it is always behind a firewall (which usually acts a reverse proxy and/or load balancer). For the outside world they are always sending the request to the firewall which in turn passes it to the required server. SAP Web Dispatcher or Apache are common examples for software based reverse proxy implementation, but there are hardware based firewall also available like Blue Coat.

So for SSL handshake to happen the client must trust the certificate presented by the Firewall. In case of client cert based authentication server (firewall) presents a list of issuers it trusts and client must present a certificate issued by one of these issuers.

Note: The communication between firewall and the actual server can be simply pass through, over plain HTTP or over HTTPS. But this is beyond the context of this document.

HCI Server Side Authentication

Now with this basic understanding let’s now shift our focus to HCI. HCI acts as a service provider when it is receiving request from a consumer system, example SAP Cloud for Customer or SAP business suite systems (CRM or ERP).

Every HCI tenant is behind a F5 load balancer (firewall) and consumer system interact with the F5 load balancer. So as a thumb rule for SSL handshake to complete the client must trust the certificate provided by the F5 load balancer, which has been discussed in the last blog.

Each individual service in HCI can be configured to use either certificate based authentication or basic authentication. This is done in the properties of a sender system of the corresponding iFlow.

6-2.PNG

Client Authentication is a 2 step process in HCI

  1. Authentication – This is achieved using a valid SCN user in case of Basic authentication (as the default UME for HCI is SAP ID service) or a client certificate issued by an issuer which the F5 load balancer trusts
  2. Authorization: The SCN user must be assigned the role ESBMessaging.send on the HCI tenant on which the service is running and for certificate based communication the client cert should be assigned to the Sender system of the corresponding iFlow artifact as shown in the picture above.


In the last part of this blog series we will talk about monitoring and some common HCI error handling strategies. Watch out for this series and happy learning!!!

To report this post you need to login first.

4 Comments

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

  1. Vinay Avva

    Hi Abinash Nanda,

    Thanks for the information. It was helpful. I have a quick question, kindly can you provide me the list of Roles we need to have as HCI developer on the HCI Tenants. We were able to develop and deploy iFlow, but we are not able to execute or download the SOAP WSDL.  Tenant is throwing unauthorized .

    Thanks,

    Vinay

    (0) 
    1. Abinash Nanda Post author

      Hello Vinay,

      The only role required to view the WSDL is ESBMessaging.send. But please remember you can view the WSDL using your SCN user id only if the iFlow supports basic authentication.


      To view the WSDL you need to use the following URL format


      https://<service path>?wsdl

      Best regards, Abinash

      (0) 

Leave a Reply