We continue our journey into SAP security topics. The following is the third part of a series exploring the HANA SQL Command Network Protocol. If you missed them, it’s recommended to read the first and second articles: Protocol Basics and Authentication and Password-based Authentication and TLS.
As detailed in the previous articles, the HANA SQL Command Network Protocol supports a variety of authentication mechanisms. In the early posts, we listed the supported authentication methods, and reviewed with some detail the password-based ones. This time, we are going to focus on the mechanisms available to federate the authentication process, and integrate SAP HANA with external identity providers through the use of different federation and Single Sign-On (SSO) technologies.
Federated Authentication in HANA SQL interface
The benefits of integrating SAP HANA instances with federated protocols can be important for different reasons according to each organization’s needs. Just to name a few gains, it can help provide Single Sign-On experiences to end-users, reduce the amount of user authentication sources and thus scale down the “identity sprawl”, support the implementation of stronger authentication methods with the use of MFA, risk-based and adaptive authentication workflows, as well as provide a central place for access monitoring. For SAP HANA instances, access to the database is generally going to be considered sensitive and it’s important to keep adequate control of the accounts and users reaching the data.
When SAP HANA is integrated with an identity provider, validation of the user identity is performed by the external party and a claim or assertion is transferred to the HANA instance for it to finally grant access to the user. The format of the claim and the exchange mechanism depend on each of the protocols and federation mechanism which we are going to review in this article.
It is important to mention that SAP HANA, when considered as an application server, can provide authentication and authorization capabilities and act as an Identity Provider with its User Account and Authentication Service (UAA) component. In this article we are not going to cover this scenario and instead focus on the authentication to the HANA instances itself through the SQL interfaces and specifically via the SQL Command Network Protocol.
For the sake of brevity, we are going to assume certain familiarity with the main federation technologies involved. However, links are provided on each section when background knowledge is required to understand the integration scenarios.
SAML-based Authentication
We will begin with the use of Security Assertion Markup Language (SAML) in the HANA SQL Command Network Protocol. SAML is a well-known and widely supported XML-based standard for exchanging authentication and authorization information between different parties. In the scenario of authenticating users to access a HANA Database, the authentication of the user is performed by an external component, the Identity Provider (IdP), and the SAP HANA instance will act as a Service Provider (SP). The exchange of information between the parties is performed by means of SAML Assertions that are signed by the IdP and contains the necessary information about the user for the SP to grant access after validating it.
The integration scheme supported for the HANA SQL Command Network Protocol is one where the client is in charge of obtaining the SAML Assertion directly from the IdP. The SAP HANA instance is not involved in that process, and instead just receives a signed SAML Assertion, or a SAML Response containing an unencrypted but signed SAML Assertion. A trust relationship is established between the HANA instance and the IdP, by means of importing the X.509 certificate used as the IdP’s signing certificate. Details about how this configuration is done can be found in the official documentation, and involves creating a “SAML Provider”, importing the corresponding “Certificate” into a “Certificate Collection” (or directly into a PSE at the file-system level), and enabling the SAML method for the desired users.
From a protocol perspective, once the client obtains a signed SAML Assertion from the trusted IdP, the XML is provided as-is as part of the AUTHENTICATION packet during the initial handshake.
The following is an example traffic capture visualized with our Open Source plugin for Wireshark:
SAML Authentication in Wireshark
When integrated with SAML, two different types of user mapping are supported: the external identity of the user is defined in the HANA instance, or the mapping is performed by the external Identity Provider. With these methods it is possible then to have an account defined in HANA with a different username than the one found at the IdP level. Note that the username field is left empty in the authentication request packet, for the mapping mechanism to determine what is the actual identifier to use for the account.
Finally, as in any other SAML-based scenario where assertions are only signed but not encrypted, it’s quite important to take into account that assertions should have a proper valid time frame established by the IdP, in order to prevent replay attacks. If the communication channel is not secured using TLS as covered in our previous article, nothing prevents an attacker who manages to access the traffic between the client and a HANA instance to grab a SAML Assertion and replay it in a new session to connect on behalf of the victim user.
Using SAP’s Logon and Assertion Tickets
The second method we are going to cover is SAP’s custom Logon and Assertion tickets. Logon and Assertion tickets are proprietary mechanisms developed by SAP, and primarily used in the Netweaver Application Servers to implement and enable SSO access between SAP systems. Generally speaking, Logon tickets are used to enable SSO access for end users, while Assertion tickets are short-lived and used in system-to-system communications and for system or service users.
In either case, a SAP system, for example a SAP Portal or SAP Web Application Server, can be configured as a Logon ticket issuer, and the HANA instance can be configured to accept them. Tickets are digitally signed, thus the signing certificate needs to be imported into and configured in the HANA database through the Trust Store. In this scenario the client is in charge as well of obtaining the ticket and providing it to the HANA service at authentication time.
From a protocol point of view, the ticket is included as the payload of the AUTHENTICATION packet during the initial handshake. Same concerns apply here as with SAML Assertions: tickets are digitally signed and include a timestamp, but to avoid replay attacks expiration times should be short and the use of TLS is encouraged in any case to provide confidentiality to the entire communication.
Authenticating with JWTs
Another scenario available to implement federated authentication in HANA is with the use of JWTs (JSON Web Tokens). JWT is a standard and compact way to represent claims about different entities, and which can be exchanged between parties. The specifications have been standardized as IETF’s RFC 7519. The integration with a HANA instance follows the pattern of the previously discussed protocols, where the client is responsible for obtaining a signed JWT from a trusted IdP, and HANA validates it at authentication time.
The implementation of JWT supports the use of the RS256 signature algorithm, and the claims validated are “iss” (issuer), “user_name” (user name), “nbf” (not before) and “exp” (expiration time). Additional claims are ignored. The trust relationship is established in a similar way to the other federated authentication methods, by importing the signing certificate and creating a JWT provider entity.
Looking at the packet level, this method is easy to implement as JWTs are provided also as-is during the authentication handshake. The following is an example piece of code to illustrate the usage of our Open Source library pysap to authenticate to a HANA instance using an already signed JWT (in this case, in the HDB/jwt.txt file):
In [1]: from pysap.SAPHDB import *In [2]: with open("HDB/jwt.txt", "r") as jwt_fd:...: auth_method = SAPHDBAuthJWTMethod("username", jwt_fd.read())...:In [3]: hdb = SAPHDBConnection("hxehost", 39013, auth_method=auth_method)In [4]: hdb.connect_authenticate()
Kerberos-based Authentication
Finally, another integration that can be made is through Kerberos. SAP HANA can be configured to authenticate database users via the Kerberos protocol with either a Microsoft’s Active Directory or a MIT Kerberos deployment. This federation integration allows also for seamless authentication scenarios where the user won’t be prompted for credentials if, for example, it’s logged in with its domain account at an AD domain-joined machine.
In this scenario, the trust relationship is established between the HANA instance and the Kerberos’ Key Distribution Center (KDC) component by means of adding a so called keytab. This keytab is no more than a collection of keys and tickets that is stored in a custom format and allows for decryption of a received Kerberos token for validation. The Kerberos authentication is implemented through the GSS API and the SPNEGO protocols, as in other SAP components.
The overall flow is no different than for any other Kerberos-based authentication. In the general case, it can be simplified as follows, assuming the user is already authenticated to it’s domain:
- The client initializes a connection with the HANA SQL Command Network Protocol service and sends an AUTHENTICATE message containing the type of GSS mechanism to use (in this case the Kerberos OID) and the user’s UPN (User Principal Name).
- The HANA service answers with an AUTHENTICATION reply, confirming the type of GSS mechanism to use and providing the SPN (Service Principal Name) the client should use when requesting the Kerberos service ticket. For the HANA SQL Command Network Protocol, SPNs have the form HDB/<FQDN>.
- The client application sends an TGS-REQ message to the Kerberos’ KDC service, which indeed contains an AP-REQ message requesting a service ticket for the SPN obtained from the HANA service.
- The Kerberos’ KDC replies to the client with a TGS-REP message, and including the service ticket granted to access the requested SPN.
- The client sends then a new AUTHENTICATE message containing an SPNEGO encoded AP-REQ request, which includes the service ticket obtained from the KDC.
- The HANA service replies with an AUTHENTICATION reply, which confirms the client that the ticket was properly validated, and the user was authenticated. If mutual authentication was requested, the message will contain an AP-REP message, that the client can use to validate the server’s authenticity.
- The flow continues from here in a similar way than for other federated authentication methods, with the client sending a CONNECT message type and the server finishing the handshake and replying with the established session.
The official help contains some of the configuration steps, while SAP Note 1837331 contains a detailed walkthrough of the setup process.
We’ve added to our Wireshark plugin the capabilities to dissect the Kerberos traffic. When provided with the corresponding Keytab, it is also possible to decrypt tickets and obtain the full details of them, as can be observed in the following screenshot:
Kerberos decrypted traffic in Wireshark
Finally, it’s important to make sure the service account in use is not configured for unconstrained delegation, as this can open certain man-in-the-middle as well as authentication relay attack vectors. SAP’s official documentation also recommends the use of TLS between the client and the HANA database, as a mechanism to avoid replay attacks. While this is not exactly the case, as the Kerberos protocol have built-in anti-replay mechanisms and it’s supposed secure even in hostile environments, TLS is still recommended to protect the remaining session’s traffic and specially the data accessed from the database.
Extending Session’s Lifetime with Session Cookies
As an additional note, we wanted to touch on the concept of Session Cookies, which all the different methods reviewed implement. Upon a successful authentication, and according to the documentation with the goal of reducing the number of round trips with the server in the case of connection interruptions or similar issues, the HANA service will reply with an established Session Cookie. Session Cookies are 64-bytes length tokens that can be used to extend a session’s lifetime. It is possible to authenticate with a HANA instance just by providing such a Session Cookie in the AUTHENTICATE message, with no need to perform any additional handshake and regardless of the original authentication method.
The default validity time is 180 minutes, and controlled with the “session_cookie_validity_time” configuration parameter. In the case of Kerberos, it’s possible to disable the use of Session Cookies with the “session_cookie_for_kerberos” parameter.
A hashed version (using the SHA-256 algorithm) of the current valid Session Cookies can be found in the database, as well as included in some of the standard logs. The following SQL statement can be used to query for the currently available Session Cookies:
SELECT * FROM "SYS"."P_SESSION_COOKIES_"
USER_ID;COOKIE;CLIENT_HOST;CLIENT_PID;CREATE_TIME;LAST_CONNECT_TIME;SESSION_END_TIME;OID
165,042;88268f57424f7d159b2e7126f22c00d4616b35d0de53817fcf8523b81a800577;ubuntu;0;Aug 24, 2020 11:17:51.248 PM;?;Aug 24, 2020 11:42:59.239 PM;36
165,042;f3c07e5e75f46edd6aed2aaf9cd2d882e7708352e73e910f012aa44bf63f1a24;ubuntu;0;Aug 24, 2020 11:19:21.463 PM;?;Aug 24, 2020 11:42:59.24 PM;37
165,042;a475c27d54391012fcc0ce95d671915c3b1ba759f96e36ba2b1d95e446d1c46e;ubuntu;0;Aug 24, 2020 11:22:29.224 PM;?;Aug 24, 2020 11:42:59.241 PM;38
165,042;2293aea4b277b263f64b7494561fa73c2e65f8e1c6df577620d00d7f8352678b;ubuntu;0;Aug 24, 2020 11:27:59.978 PM;?;Aug 24, 2020 11:42:59.242 PM;39
165,042;d8c328777df0803ae1ae608ef4bafa007ebe867eae875e4fbf53f79927fab1ec;ubuntu;0;Aug 24, 2020 11:28:47.628 PM;?;Aug 24, 2020 11:42:59.243 PM;40
165,042;c2153b0f771f2c9fab2c11816d88cb4130ba13da64b6bf03965f28d40317e457;ubuntu;0;Aug 24, 2020 11:29:26.821 PM;?;Aug 24, 2020 11:42:59.254 PM;41
165,042;a857c5f070a68c093b52599cf399624406169704d423681c3414d0150e80d53b;ubuntu;0;Aug 24, 2020 11:29:42.419 PM;?;Aug 24, 2020 11:42:59.263 PM;42
165,042;0dbce9b7949076fd6c2fc2384d24b4e8aee8edec20761a0a912e772dd5c59c04;ubuntu;0;Aug 24, 2020 11:32:13.119 PM;?;Aug 24, 2020 11:42:59.264 PM;43
165,042;621d38329c3aeb79087109e4f37b06a456b284fa7636bccb4b7b10f416c501ae;ubuntu;0;Aug 24, 2020 11:33:06.186 PM;?;Aug 24, 2020 11:42:59.274 PM;44
165,042;73f866300e075071a6feda7fc54f52decc6f9234584c77df22d097c77b33cee0;ubuntu;0;Aug 24, 2020 11:33:29.628 PM;?;Aug 24, 2020 11:42:59.275 PM;45
From a threat model perspective, it is important to take into account that Session Cookies should be treated as sensitive, since they replace the need for any additional authentication during the permitted time. An attacker in possession of a Session Cookie can impersonate the affected user without too much trouble. In this context then, protection of the traffic with TLS should be considered a requirement more than a recommendation in any production environment.
Final Thoughts
Through the series of articles about SAP’s HANA SQL Command Network Protocol we’ve provided a technical overview and reviewed at a high-level the general and federated authentication mechanisms. At the same time we’ve introduced and highlighted some of the functionality recently added to both our Open Source packet crafting library pysap, as well as the dissection plugin for Wireshark. We encourage practitioners and security researchers to leverage them to navigate through this unexplored protocol in search for new mechanisms to protect SAP deployments, as well as integrate them with access management solutions. We hope to continue sharing more insight about our SAP security findings in future posts.
Feel free to reach me on Twitter at @martingalloar or email our Innovation Labs using labs@secureauth.com. We welcome any feedback or comment about the tools and its uses!
Read the complete posts in this series:
