Hello and welcome to the SAP HANA Academy.
The topic of this video tutorial series is SAP HANA as a Service and in this video we
will take a look at Authentication and Single Sign-On, a security topic.
This video has been recorded in December 2018.
For earlier or later releases, please check the playlist on the SAP HANA Academy.
Hi, I am Denys van Kempen.
When we connect to a database, HANA needs to know who we are.
Needs to know who we are to figure out what we are allowed to do in the database.
Just select * from dummy?
Or can we create a new user, make a backup, stop the database?
Those are object and system privileges and falls under the header authorization.
In this video, we are only concerned with authentication.
Are you who you say you are?
Now the easiest, most basic way to find out is by using a username and password.
Basic authentication, we are all too familiar with this
And if we open Manage users, here in the User & Role Management section on the System Overview
page, and click the plus and select Create User, we can then configure authentication
in this section here.
We have three options;
Password, SAML, and JWT.
As we are supposed to pronounce JWT which stands for JSON Web Tokens, JSON being JavaScript
Object Notation.
SAML and JOT is basically the same idea.
SAML has the ML (markup language) as in XML and HTML, and SA stands for security assertion.
Both are open standards, SAML is the older one of the two.
The RFC for JWT is from May 2015.
SAML goes back to the early 2000s, to give you a rough idea.
We are not going to go into the technical details here —you can look it up on Wikipedia,
if you want— but the main use case for both is to enable single sign-on (SSO) over the
internet, could be for web applications but could also be for ODBC/JDBC clients.
Basically, we can tell HANA that to authenticate this particular user, do not check your own
credential store but trust - that’s an important word here - this identity provider.
IdP.
Here, just for demo purposes, we have SSOCircle as SAML Identity, for example, and you would
configure this using Manage SAML Identify Providers.
This would bring us to the SAML Provider app.
And here we associate the identity provider with a certificate, so we know (we as in HANA)
that we can trust this provider.
The certificate comes from the Certificate Store and the certificate is placed into the
SAML collection and if we select Show PEM Representation, we can see the certificate
of the provider, which makes this all possible.
So, you will need to set this all up, including all the user accounts on the provider side
but once this is done, you can easily navigate from one application to the next without having
to specify your username and password each time.
It would be passed along in the URL.
Also, when you update your password this will be in a single location and you do not have
to go into all those HANA systems to update the password, or maintain a list of different
passwords for different databases, even worse.
SAML/JWT are often used together with LDAP systems, like Microsoft Active Directory,
for example.
Now, if we briefly switch to an on-premise system, to compare.
For authentication, we have username/password, we have Kerberos (mostly used in the combination
with Windows domains), we have SAP Logon and Assertion Tickets, typically for Netweaver
environments (ABAP), we have SAML, we have JWT, but also X509 certificates.
So, a few more options on-premise.
OK —Back to HANA as a service.
User Management - Couple of remarks.
Note that a user has a validity period and this is checked when we log on.
We can disable ODBC/JDBC access, so this will turn our user into a web user only.
We can remove the PUBLIC role, this corresponds to creating a restrictive user.
Without the PUBLIC role you cannot create objects in your own schema.
In fact, you don’t have a schema to start with and this is for application users.
For local authentication, username/password, we have a password policy.
You configure this here using the Authentication app.
We are connect to cockpit with the SYSTEM superuser.
Not a best practise.
SAP recommends to create separate accounts for system administration purposes based on
the least principle privilege, so, ideally you would have an administrator to create
user accounts, another one to manage tables, another one for backups, and so on.
Of course, depending on the user role, you probably would bundle a number of privileges.
However, you should avoid creating another super user like SYSTEM who can do anything
as this introduces a considerable security risk.
In the Password Policy and Blacklist app you can edit the parameters.
Speaks for itself and blacklists serve to get rid of silly passwords like Password1,
as a string (so password123, won’t work either) and whether this should be case sensitive
or not.
OK —That’s it.
Authentication and single sign-on using SAML and JWT for the SAP Cloud Platform, SAP HANA
Service for Cloud Foundry.
Thanks for watching.
You can find more video tutorials on our YouTube channel.
If you would like to be informed about new video tutorials, please subscribe to our channel.
You can connect with us on LinkedIn or follow us on Twitter, as well for updates, and if
you are watching this video on YouTube, do not hesitate to leave your comments to the
video page and, if you like, give us your vote on this video.
Thank you for watching the SAP HANA Academy