openSAP

SAP HANA Cloud Platform Essentials

Week 2 Unit 1
00:00:11

Hi. Welcome to Week 2, Unit 1 of the openSAP course SAP HANA Cloud Platform
Essentials.This week, we will give you a broad overview of security on SAP HANA Cloud
Platform,

00:00:23

for which I have a colleague of mine with me.In this unit, we will get an introduction to the
security concept used with the SAP HANA Cloud Platform.
Hello, Im Martin Raepple and I'm a product owner for SAP HANA Cloud Platform security.In
the following units, we will cover the key security concepts of the platform.
These topics cover authentication and single sign-on, authorization management, protection
of Web APIs in your applications, and last but not least identity propagation,
which is also an important topic for more complex cloud scenarios.Let's get started with
authentication and single sign-on.
It may be surprising to you but an application running on HANA Cloud Platform does not
have a user store with the application. So there is no local database to the application
on HANA Cloud Platform that can hold any of your user data.User records, for example, that
you want to use to authenticate your end users
to the application on HANA Cloud Platform.So the question is where are users stored, if not
with the application on HANA Cloud Platform?
A key concept in HANA Cloud Platform is that authentication of users and, along with the
authentication, also the identity management of users records is always delegated
to a central system, which we refer to in HANA Cloud Platform as an identity provider or, in
short, IdP.
An identity provider is typically a system that is specifically designed for exactly that purpose
of managing users and keeping user data secure at a central place.
And that user data consists at least of a unique identifier of the user.It also contains a secret
credential that the users can use to present to the
identity provider to prove that they are who they claim to be and can authenticate against
the identity provider.But an identity provider may also manage other user and identityrelated information,

00:00:33
00:00:44
00:00:54
00:01:03
00:01:15
00:01:24
00:01:34
00:01:45
00:01:53
00:02:05
00:02:15

00:02:28
00:02:38

00:02:51
00:03:01
00:03:12
00:03:24
00:03:34

such as user attributes, for example, a first name, a last name, an e-mail address, group
memberships, organizational data, and address information.
An identity provider is always used in HANA Cloud Platform to manage the user accounts of
your users that you intend to authenticate against your applications running on HANA Cloud
Platform.
In order to delegate the authentication identity management to an identity provider, it's
important that we can rely on common technology standards that allow
the HANA Cloud Platform to integrate with an identity provider of your choice.Fortunately,
we can rely on a number of standards here. And one of the most important
standards in this space is the Security Assertion Markup Language or in short,
SAML.SAML is a key technology for SAP HANA Cloud Platform and it's supported
by a wide range of identity providers.And as an administrator on the HANA Cloud Platform,
you have a broad choice
of identity providers from which you can choose in order to authenticate your users.If you
are, for example, a single developer who owns a trial account on the HANA Cloud Platform
trial landscape,

00:03:49
00:04:04

00:04:19
00:04:29
00:04:39
00:04:48
00:05:00

by default your account can integrate with the SAP ID service.The SAP ID service is SAP's
public identity provider run by SAP in SAP's data center,
which contains all the users, for example, that authenticate against the Community
Network.I'm pretty sure that if you are an individual developer, who has already worked with
SAP,
you most likely already have an account in this SAP ID service and it's the same account
that you also use when you log onto the SAP Community Network.
Or as customers typically also get a user managed by this SAP ID service in order to
access the Service Marketplace. So the SAP ID service is really a
very key and central system for SAP, not only for HANA Cloud Platform, because it also
manages users for many of SAP's other public websites,
solutions, and services, such as SCN or the Service Marketplace.And as a developer of the
SAP HANA Cloud platform, and if you already have a trial account,
you can basically set up the authentication or delegate the authentication to the SAP ID
service with almost no effort and free of charge. So you don't have to pay anything to make
use of

00:05:13

this SAP ID service. However, it comes with a number of limitations, for example,
registration of users to this ID service is free to anyone who wants to register with this
service.

00:05:24

So you, as an administrator, cannot control and say I don't want this user to register but only
this user. So, it's a user base that is not under your control.
It's a user base that is under SAP's control and it's a user base that allows public
registration.If you want to be in more control of the user base, basically in full control of who
can register

00:05:35

00:05:50

to your user base and who can log onto your applications, but still want to keep the identity
provider managed by SAP and in the cloud, then the second option listed here on this slide

00:06:02

is probably what you are looking for. It's SAP Cloud Identity.SAP Cloud Identity is a service
offered as part of the HANA Cloud Platform
and it basically gives you an identity provider on demand.But this identity provider and the
underlying user base is under your full control.
It's charged per logon request but you are in full control of the identity lifecycle of the users
that are stored and managed by this system.
In addition, you can also customize the system, for example, the look and feel of the login
screen. You can display your own corporate logo, for example.
And many other settings are possible with this Cloud Identity service.And we also have
many scenarios where our customers, for example, want to make use
of an existing identity provider they already run and operate, for example, in their corporate
network.This is the third option on this slide, which I always call "bring your own identity
provider".

00:06:12
00:06:21
00:06:31
00:06:42
00:06:53

00:07:04
00:07:17
00:07:29

00:07:41
00:07:54
00:08:06

If you already have, for example, a Microsoft- based infrastructure in your corporate
network, and typically you then have Active Directory, for example, as a user store
for your employee user data. Then on top of Active Directory, you have a wide choice of
SAML 2.0-compliant identity providers that can play this role
of an identity provider running in your corporate network, which can also be easily
integrated as an identity provider for your cloud-based applications on HANA Cloud
Platform.
From a platform perspective, our intention is to give you as a customer, you as a developer
the widest possible choice you can have to select from different identity providers.
Again, the main prerequisite for all of the three choices listed here is that the identity
provider is compliant with the SAML 2.0 standard, which allows the platform to integrate
with the identity provider on a standardized protocol.Now, typically after authenticating a
user in an application, you want to know

00:08:18

what the user is allowed to do in your application. This is typically referred to as

authorization.After authentication comes authorization. And I think the most common
concept for authorization

00:08:30

in IT is that you manage roles and assign users to roles known by your application.On
HANA Cloud Platform, applications typically define their roles themselves during the design

00:08:43

development phase of the application. As an example, a Java application running on HANA

Cloud Platform defines its roles as part of the web.xml file. That's the deployment descriptor
of your Java application.

00:08:56

And this deployment descriptor defines the set of roles that your applications know and
need to in order to authorize users. And the assignment of these users can be done in the
SAP HANA Cloud cockpit,

00:09:11

where those roles appear and you can then manage the assignment of users, identified by a
unique identifier such as an e-mail address, for example,
to those roles known and defined by your HANA Cloud Platform applications.However, this
static assignment of users to roles only scales to a certain level.
Imagine you have maybe hundreds, or maybe even thousands of users you need to assign
to single roles, then certainly this model doesn't scale anymore.
This is where a third entity, shown here on this slide, comes into play. These are
groups.Groups on HANA Cloud Platform can contain one or many roles
coming from one or many applications on the HANA Cloud Platform.And users can be also
assigned statically. So a user XYZ assigned to a group ABC.
But the assignment of a user to a group can also happen via a so-called federated attribute
of the user.So on the HANA Cloud Platform, you can specify a mapping rule
that says every user, no matter which ID that user has, who belongs to a certain
department, for example, should belong to a specific group
you manage on HANA Cloud Platform.And by federating or providing this information from
the identity provider about
the user's department in this example to the HANA Cloud Platform, you can mass assign
potentially hundreds or even thousands of users with this one, single configuration to a
group, which may contain one or many roles.So via these group entities, you can mass
assign users and therefore
this model scales much better in case you have a larger number of users to assign a certain
role.In this course, we will only cover the assignment of users to roles.
Groups will be covered in a later course.In the cloud, you may also be aware that
applications heavily rely on APIs.
Actually, the most prominent examples of large- scale cloud solutions and applications,
especially those in social networks, for example, heavily rely on the fact that
applications can integrate with these cloud solutions or cloud applications through the use of
APIs.
The most prominent examples are native mobile applications that typically make use of
cloud services that expose their services as APIs.
Typically, used with an HTTP protocol.And those native applications then make use of these
APIs in an authorized manner.
Martin, we have now seen that SAML was the tool or the standard of choice for handling
such authentication in a Web browser. How is this for APIs?
APIs actually are not protected using SAML because SAML was designed only for browserbased solutions where the browser is used to access a user interface that comes with the
application in the cloud

00:09:21
00:09:34
00:09:44
00:09:56
00:10:07
00:10:20
00:10:30
00:10:38
00:10:48
00:10:57
00:11:13
00:11:27
00:11:41
00:11:51
00:12:04
00:12:16
00:12:29

00:12:46
00:12:56

and to authenticate the user using a Web browser.For native mobile applications, for
example, or desktop or even server applications that integrate
with an API without going through a UI interface, SAML is not the right choice.This is where
the HANA Cloud Platform makes use of another important standard, which is called

00:13:06
00:13:16
00:13:28
00:13:39
00:13:48
00:13:58
00:14:09
00:14:19
00:14:32
00:14:42
00:14:56
00:15:06

00:15:23
00:15:36
00:15:51

00:16:04
00:16:17
00:16:30
00:16:41
00:16:51
00:17:04
00:17:14
00:17:23

the Open Authorization Framework, or in short, OAuth 2.0.In the course of this week, we will
also take a closer look at OAuth
as a very important standard, which covers those API scenarios quite nicely.And last but not
least, I mentioned in the introduction that we also want to take a look at
identity propagation scenarios. So when is identity propagation needed? Imagine you have
a regular Web application deployed on HANA Cloud Platform
that comes with a UI. So it's a regular Web application and you authenticate your
users.However, that application also relies on services that, for example,
hold data that should be called by that application in the back end.And that back-end
service providing, for example, an API to
your Web application may reside on HANA Cloud Platform as another application or
component deployed on the HANA Cloud Platform. It may be another cloud-based service
running outside HANA Cloud Platform in another cloud platform.For example, a
SuccessFactors-based application.
Or, and very likely, it may also be a service that is deployed in your corporate network.As a
back-end system, for example, coming from an SAP or even from a non-SAP product.
In all of these cases, your application that handles the initial login of the user (here shown
on this slide as the blue guy)
needs to make a call to this back-end service and, with this call, needs to propagate the
logged-in user to the application or to the service being called.
And in all of these scenarios, the HANA Cloud Platform has to make sure that the
established login context by the blue guy who authenticated, for example, with
one of the identity providers of your choice, is securely propagated with the call so that, for
example, another service deployed on HANA Cloud Platform that gets called by your Web
application
can be sure that the user who is passed with this call is the authenticated user by the initial
login and can therefore execute and return data for that authenticated user.
So HANA Cloud Platform makes sure that this initial login gets securely propagated to one
of these destinations or service endpoints that are shown here on this overview slide.
In the course of this week, we will take a closer look at one particular identity propagation
scenario where your Web application is running on HANA Cloud Platform as an HTML5based application.
And that HTML5-based application will call a back-end service deployed on HANA XS that
should return data for the logged-in user in the HTML5 application
using an OData and JSON service.So with that I would like to give you a short overview, an
outlook about what's coming next in the next units.
In Unit 2, we will take a closer look at HTML5- based applications and how to secure them.
So we will take a look at how to authenticate users using the SAML standard.
How to manage permissions and roles for those types of applications.And as you know
HANA Cloud Platform is a multi-runtime platform
it supports in total three different programming models and runtimes.So in Unit 3, we will
basically take a look at the same topics but in the context of Java-based applications.
In Unit 4, as I mentioned, we will also take a look at Web APIs.How to protect Web APIs in
your HANA Cloud Platform applications and how to make use
of the OAuth standard in those scenarios.In Units 5 and 6, we'll combine a more complex
scenario,
which is all about the identity propagation of the scenario that I mentioned in the last slide all
about HANA Cloud Platform and an HTML5 application that needs to propagate the user

00:17:34

to an XS-based service.And with that, I'm finished with the overview.

00:17:43

Thanks a lot Martin for this introduction to security on the SAP HANA Cloud Platform.That's
all for this unit. Thanks a lot and see you all in the next unit. Bye bye.

Week 2 Unit 2
00:00:11

Hi. Welcome to Week 2, Unit 2 of the openSAP course SAP HANA Cloud Platform
Essentials.In this unit, we will get started with securing HTML5 apps on SAP HANA Cloud
Platform.

00:00:25

Thank you Sven and welcome from my side.Let's get started with this very interesting topic
of looking at HTML5 applications.
And as you may already know, an HTML5 application consists of many artefacts such as
stylesheets, HTML files, certainly JavaScript files.
But probably the most important configuration file of the HTML5 application is the so-called
neo-app.json file.You can think, for those who are more experienced Java developers,
think of this neo-app.json file as the deployment descriptor for your HTML5 application on
HANA Cloud Platform. The format of this file is defined by the HTML5 programming model
on HANA Cloud Platform.

00:00:37
00:00:50
00:01:03

00:01:19

And from a security perspective, this file takes a very important role in your application
development cycle because it defines the authentication method used to protect your
application against unauthorized access.

00:01:37

By default, an HTML5 application is a public application, so every user can, without any
further authentication, access your HTML5 application.
However, if you want to protect your application, you can make use of the so-called
authentication method switch in that deployment descriptor that's shown on this slide
and set it from "none", which means no authentication, to "saml".And as you already
learned in the first unit of this week, saml is our core technology standard
to integrate with an identity provider of your choice.So the same is true also for an HTML5
application running on HANA Cloud Platform
which can make use of a saml-based identity provider to authenticate the users that need to
log into your application on HANA Cloud Platform.
Along with this very core security setting of the authentication method, you can also define,
for example, the page that should be presented to users when they log out,
with the logout page element here.You can define security constraints, which play an
important role in the next topic of this unit.
So Martin, we have now covered authentication of the user.What else do we have to do to
really make our apps secure?
So, as we also mentioned in the first unit of this week, we need to make sure that after
authentication of the user,
your application needs to decide what this authenticated user is allowed to do.So this is all
about again authorization.
So we need to find a way to authorize your users by assigning your users to roles in your
HTML5-based application.
So, the way to give permissions to users is by defining a so-called security constraint in your
neo-app.json file
and that security constraint can define a
so-called permission.And a permission can be thought of like a permission you give to a
specific user
in order to allow that user to do something or to access, for example, specific data in your
HTML5 application.
And typically, along with a permission, you also define a path.So, a path in your HTML5
application that can only be accessed by users
that have this permission that you define in that security constraint.So in this example, as
shown here, only those users who have the permission accessProjectData
can invoke, or can open code under the /protected/ path in your HTML5 application.So,
along with public resources, such as a landing page, an index page

00:01:48
00:02:00
00:02:13
00:02:24
00:02:35
00:02:45
00:02:56
00:03:04
00:03:15
00:03:23
00:03:32
00:03:44

00:03:55
00:04:03
00:04:21
00:04:32

00:04:48
00:04:59
00:05:11
00:05:17
00:05:28
00:05:36
00:05:49
00:05:57
00:06:08

00:06:26
00:06:36
00:06:49
00:06:59
00:07:11
00:07:21
00:07:33
00:07:42

of your HTML5-based application, you may also have those protected resources defined by
security constraints in your HTML5 application.
And to assign a user to a permission, you first have to define a so-called role in your
HTML5-based application.
A role is not defined in the neo-app.json file.A role is defined in the cloud cockpit.
And in the demo that we will do in a second, I will show you how to define such a role and
assign a permission, this accessProjectData permission, for example,
to that role to which you also assign users.And by assigning a user to role that is assigned
to a permission,
you specify that those users can access that protected path in your HANA Cloud Platform
HTML5 application.OK, so we have now covered the theory, I think,
and we also have in the additional material of this unit a sample application.So could you
show us what we can do with this application?
Sure. So I have now already logged in here in my HANA Cloud Platform trial account.And in
that trial account, I have also deployed this sample application,
that project management application that already runs here and is deployed to my trial
account.So, in order to access the Web IDE so that we can have a closer look at this
HTML5 application,
I need to open the Web IDE and that can be done via the Subscriptions menu here.And
here you see an entry for Web IDE.
And clicking on Web IDE, you basically get here on the top of this page the link to open the
Web I have already done that on another tab, so this is the Web IDE.
And as you can see, in the Web IDE, I have my xproject HTML5 application.And the
structure of this application is quite simple.
It has a number of public resources.So, resources that can be retrieved by a user without
any further authentication.
And it has resources under a protected path that should only be accessible by users who
have, first of all, successfully authenticated,
and are assigned to the correct permission via a role that we will specify in a few
seconds.OK Martin, so the users now have their sample application,
but could you also show us how they can get the sample application into the Web IDE?
Right, so this sample application will be provided as additional material to this unit,
and you can simply import it when you click on Workspace, right-click and Import -> From
File System.So that is how you can import this sample application later on from the
additional material of this unit.

00:07:58

OK, so let's take a look at this important file, this neo-app.json file that controls access to
our application.So, first of all, as I mentioned in the slides, you have to specify a security
constraint.

00:08:11

This is done here. And similar to the slides, it shows that we have defined a permission in
that security constraint,
which we call accessProjectData.And only users who obtain that permission are allowed to
access our protected path,
which we also call protected in our HTML5 application.So only users with that permission
should get access to all the resources underneath this path.
You may have also noticed that the authentication method in my neo-app.json file is set to
"none" here although I said before that if you want to protect your HTML5 application,
and want to require authentication, you have to set "saml".So this is a little specific rule here
that applies.
So in case you want to protect, in general, all resources of your HTML5 application and
want to require authentication of users to all of the resources,
then you have to specify "saml" here.But in our case, we have a public landing page, this
index page,

00:08:19
00:08:29
00:08:41
00:08:53
00:09:00
00:09:11

00:09:17

and also some other public resources like the stylesheets here, for example, or some
images, that should also be accessible by basically any user who accesses this application.

00:09:27

On this landing page, we have a login button.And only if you click on the login button are
you redirected to the protected path
and that should then require authentication.In such a scenario, you have to apply "none" as
the authentication method.
OK, so did I understand it correctly, that by applying "none", I can also define some
resources that are available publicly,
and then for the security constraints, only some other resources are then protected?
Exactly
OK
So, as a rule, if you have such a scenario where you have public and protected resources,
the authentication method needs to be set to "none".
OK, so let's take a look at the application, how it works.So, we have, as I said, deployed it
here in my trial account.
So under HTML5 Applications, you see it is deployed here.But right now, I have not yet
specified which users should be assigned to the accessProjectData permission.
And as you can see here, it is already listed here as an assignable application
permission.But right now, the assigned role is everyone, so basically there is no protection
at the moment,

00:09:36
00:09:44
00:09:53

00:09:59
00:10:09
00:10:20
00:10:36

00:10:48

only for specific users in a specific role.And this is what we are going to change now.

00:10:54

So we are now defining a specific role, and let's call this role "ProjectMember".And this can
be done in the same menu here, so if you click on Roles for your HTML5 application,
this screen allows you to define custom roles for your application.So let's click on New Role
and specify a role name "ProjectMember".
And save that.And now I can assign my user to this role and in order to assign a user to a
role,
you have to specify the unique ID, the user ID of your user.And as the identity provider in
this scenario, we are going to use the SAP ID service,
so my user is my D-user, so my user has a D number.In your case, most likely, your user ID
will start with a P.
So you get this information from the SAP ID service when you register your user.Or if you
have already done so, you can just go to accounts.sap.com.
This opens your profile and there you can see your unique ID that you have to specify here
on this screen.So, I will now enter my unique user ID.
Click on Assign. So now my user is assigned to that ProjectMember role.What's missing is
still the link between this newly defined role
and the HTML5 permission defined by my xproject HTML5 application.Again, this is done on
the main application screen here.
So, in the application permissions, my accessProjectData is listed.And if I click on Edit, I
should now see in this dropdown box, my newly created ProjectMember role.
And by assigning the ProjectMember role to the accessProjectData permission and saving
that, I basically say that only users who are assigned to the ProjectMember role
will obtain the permission accessProjectData, and, therefore, only those users really get
access to the protected parts of my HTML5 application.
OK, but the index file, everyone can see that, right? Right. The index file will be accessible
to everyone without any authentication,
and let's check how this works.OK, so this is the URL of my HTML5-based application.

00:11:07
00:11:22
00:11:32
00:11:41
00:11:51
00:11:59
00:12:18
00:12:29
00:12:41
00:12:58
00:13:12
00:13:21
00:13:29
00:13:35
00:13:45

So, I will now open this application URL in a private window.So, and as you can see, this is
this landing page,
and up to now, I wasn't asked by an identity provider to provide any credentials.OK, so this
is the index page.

00:13:51
00:14:01
00:14:13
00:14:19
00:14:28
00:14:35
00:14:42
00:14:55
00:15:12
00:15:19
00:15:30
00:15:46
00:15:55
00:16:06
00:16:18
00:16:25
00:16:34

This is the index page, that's the publicly accessible index page without any further
authentication requirements. But as soon as I click on Login,
this will link me, as you can see maybe in the lower left corner here of this window, this link
goes to a resource under the protected path.
And as we defined in our neo-app.json file, this should now require the user to log in.Let's
see what happens.
If I click on Login, I get redirected to the identity provider and I see a Log On screen, where I
need to enter my credentials.
And this Log On screen is presented by the SAP ID service, SAP's public SAML 2.0compliant identity provider
that is, for example, also used when you log into the community network or to any of the
other SAP websites.
So, let me enter my credentials here.And click on Log On.
Now I'm authenticated and redirected back to the application.And in a second we should
see a protected page with the projects of my company.
I was successfully authenticated, I was successfully authorized, because otherwise I
wouldn't have seen this page.
What's missing here, as we all see, is that currently there's no data shown for projects that I
am a member of and that I should be able to see here as an overview.
This will be done in another unit in this week, in units 5 and 6 where we will call from this
HTML5 application a data service running on an XS-based system,
and where we propagate this currently logged-in user to the XS system in order to retrieve
the data from XS and show the project data on this screen.
But for now, we basically have covered the key scenarios here to authenticate users in
HTML5 applications and to authorize them
using the neo-app.json descriptor and defining permissions and roles.And with that, I am
done for this unit.
OK, thanks a lot Martin.So we covered how we can secure HTML5 apps on SAP HANA
Cloud Platform.
And we have covered most of what we need here.And we will also use this sample
application later on in this week.
So that's all for this unit.Thanks a lot and see you in the next unit.
Bye bye.

Week 2 Unit 3
00:00:12

Hi. Welcome to Week 2, Unit 3 of the openSAP course SAP HANA Cloud Platform
Essentials.In this unit, we will get started with securing Java apps on SAP HANA Cloud
Platform.

00:00:25

Hello and welcome from my side.Today, we want to take a look at Java applications and
how to protect them.
And, I hope this doesn't come as a surprise, on the HANA Cloud Platform, you make use of
the standard mechanisms for Java applications to protect them.
And, as an experienced Java developer, you are probably aware that the key configuration
file for protecting your Java-based applications is the web.xml file.
This web.xml file, for example, defines the login configuration and authentication method for
your applications on HANA Cloud Platform.
So, for HTML5 apps, in the previous unit we have seen SAML as the authentication
standard.What options do we have here for Java apps?
Java apps have a little broader set of options to protect or to authenticate the users.For
Java, you have the choice between basic authentication,
meaning you require a user name and password that is opened by a popup in the user's
Web browser.And the user can enter their SAP ID service user name and password to
authenticate

00:00:34
00:00:43
00:00:57
00:01:05
00:01:15
00:01:27

00:01:41
00:01:48
00:02:00
00:02:12

00:02:25
00:02:37
00:02:47
00:03:00
00:03:16
00:03:26
00:03:41
00:03:50
00:04:02
00:04:17
00:04:29
00:04:39

against your application on HANA Cloud Platform.You can also configure client certificatebased authentication.
So for those scenarios where your users are equipped with an X.509 client certificate that
may be stored, for example, on their desktop PC, they can make use of this
client certificate to authenticate against your application on the HANA Cloud Platform.And
last but not least, for Java-based applications you can certainly also make use
of a SAML tool-compliant identity provider to delegate the authentication to the central
identity provider and provide single sign-on and identity federation through this identity
provider.
Depending on your choice of authentication method, you have to specify a specific
description in the authentication method
in your web.xml file. So for user name and password-based authentication using basic
authentication descriptor or the name in the authentication method is basic,
for client certificates it's cert, and for SAML 2.0 it's form.So all of these three are
standardized authentication methods by the Java EE specification.
Basically on HCP, we translate form into SAML because basically, as a user, it feels like a
form that is opened by the identity provider to provide the credentials.
And again, typically after authenticating the user, your Java-based applications want to
know what that user is allowed to do and this is all about authorization.
OK, so what do we have to do here to finish the security of our app? Similar to HTML5
applications, you also have to specify roles that your users can belong to
and those roles can be checked by your application in order to authorize the user for certain
activities or actions, or access to data.
And again those roles are specified in the web.xml file of your Java-based HCP application
with the <security-role> XML element, as shown here on this slide.
As the developer of the Java application on HCP, you specify those roles in the web.xml
file.You then deploy your Java application on HCP
and the roles that you specified appear in the cloud cockpit and can be assigned there to
users of your application.So this is a bit different compared to the HTML5 apps, right?
Right. In HTML5 applications, the neo-app.json descriptor defined permissions. Those
permissions were assigned to roles that you specified
after deployment of the application in the cloud cockpit. And then you assigned users to
those roles.For Java-based applications, the users are directly assigned to those roles and

00:04:51
00:05:05
00:05:17
00:05:34
00:05:50
00:05:58
00:06:14
00:06:26
00:06:34
00:06:45
00:07:03

00:07:14
00:07:27
00:07:38

those roles can be checked in your application, for example, programmatically by using the
IsUserInRole API that Java provides as a standard.
Let's take a look at how this works in practice.First of all, let's go to the cloud cockpit and
see where we have already deployed this application.
This Java application will be used as an example. And as you can see, it is already up and
running and I will show you in a second what the web.xml for this application looks like.
Furthermore, it defines a set of roles: an employee role.And we will later on assign a user to
that role. So let's switch to Eclipse.
The code for this application will be provided as additional material.Right.
You can import it using the import function in Eclipse. So just right-click on Import Import
and then, under General, you find Existing Projects into Workspace.
Just use this wizard to point to the ZIP file that will be provided as additional material and
contains all the code for this sample application.
And then you basically end up with a configuration like this.You see the structure of this
Java-based application.
And again, similar to the scenario with HTML5, we have a public index page that is
accessible without any further authentication.
But access to a servlet in this case that will show data of the authenticated user that should
be protected and this is exactly what we specified here in this web.xml file.
So first of all, we specified the authentication method and login configuration using
FORM.Again, FORM is translated into SAML-based authentication on HANA Cloud
Platform.
So any user who needs to authenticate against this application will be redirected to the
identity provider of your choice and needs to provide credentials to the identity provider.
And again, we will make use of the SAP ID service in this scenario.Next, we have defined a
security constraint here in the Web application, in the web.xml file,
which defines a protected area and everything protected underneath will require
authentication of the user.And in addition to that, will also require the user to be in the
employee role.

00:07:55

This employee role is specified here in the <security-role> element.And the protected path
contains a servlet a HelloEmployee servlet that shows data of the user currently logged in.

00:08:10

If the user is not authorized to access this protected resource in this case, a simple servlet
that shows the data of the user,
we defined an error page, also compliant with the Java standard, which will redirect to a
page that says that you are not authorized to do so.
OK. So if we now have this app, we can deploy it like we saw last week, in the Java unit
there, onto a server, to the SAP HANA Cloud Platform.
Right.Could you show us how this then works on the SAP HANA Cloud Platform?

00:08:23
00:08:32
00:08:43
00:08:48
00:09:01
00:09:11
00:09:20
00:09:30
00:09:41
00:09:51

OK. Sure. So let me switch back to my cockpit.Again, as we already saw, the application
defined in the security role the employee role.
And this appears here as type "predefined".For those of you who watched the second unit
of this week
very closely may have seen that the role that we specified for our HTML5 application was of
type "custom".
This is because we specified this role basically after we deployed the application and
defined that role in the cloud cockpit. Here, the role is of type "predefined" because it is
already specified by the application and deployed with the application.So this is why the
type is here different for a role that is specified in the web.xml file.
But, in the end, all roles are treated the same. So it doesn't matter actually if it's a custom
role, which you have specified after deployment of the application,
or if it is a role that is already specified by the application in the web.xml file.They are all
treated the same so you can assign a user to that role. And let's do this right now.

00:10:02
00:10:15
00:10:27
00:10:41
00:10:50
00:10:57

00:11:08
00:11:17
00:11:27
00:11:42
00:11:56
00:12:10
00:12:26
00:12:36
00:12:48

00:13:01
00:13:14
00:13:29
00:13:42
00:13:59
00:14:09
00:14:18
00:14:29

I'm now assigning my user again to this employee role.And if I go back to the application's
overview and
open the application's root URL in a private window, I first of all reach that public landing
page, right?
So that's the index page of my application. It doesn't require any authentication at the
moment.But as soon as I try to access the protected area of my Java application,
I should now again be redirected to the identity provider.In my case, for my trial account,
again it's the SAP ID service,
which should ask me for login credentials.And as you can see, I am redirected again to that
login page.
And that's the same page as for the HTML5 app because we used the same identity
provider.Exactly. So we haven't changed anything in the identity provider configuration for
my trial account.
So it uses the so-called default configuration for the trial account, which by default uses the
SAP ID service
the free-of-charge identity provider from SAP.And again, I can log in with my D user.
And click on Log On and then hopefully see my user data, right, which says basically my
user ID is this and I have accessed the protected resource.
We may now even add a few more user data to this servlet.Let me do this just by changing
the code of this servlet.
As you can see, right now it only prints out the user ID.But since we have an authenticated
user now, we can also retrieve additional data.
And I've already prepared a few lines of code, which we can just import here.So we just
have to fix some class imports by using Source, Organize Imports.
Save that and just redeploy. And then we will see what changes.Basically this class is part
of the HANA Cloud Platform Java SDK.
So it allows you to access the user object of the authenticated user.And access additional
attributes of the user, for example, a first name and the user's last name.
Those come from the identity provider, when the user was successfully authenticated, and
can be accessed in your application.So if we now redeploy our app, we should see this
additional information.
Right. So let's do this. As you can see, in my server adapter here, it says Republish.So let's
just update the application with these few lines of code here that have changed.
It's now synchronized, which means the update has happened.So let's go back to the cloud
cockpit and see what has happened. Maybe I'll close that private window.
And reopen it. Let's if there's now more information showing up about the user.OK, again
we are at the public landing page. Let's click on protected.
Again, I will log on with my D user.OK. As you can see, now my first and last name are
shown, and also my e-mail address.
And again, all this information is provided by the identity provider in the SAML response
sent back to HANA Cloud Platform. Alright.
OK. Then Martin thanks a lot for the information provided in this unit.And we have now
gotten a really good overview of how we can secure Java apps
on SAP HANA Cloud platform. We covered authentication and then also authorization.And
we have also seen a demo of this.
So that's all for this unit. Thanks a lot and see you in the next unit. Bye bye.

Week 2 Unit 4
00:00:12

Hi. Welcome to Week 2, Unit 4 of the openSAP course SAP HANA Cloud Platform
Essentials.In this unit, we will get started with securing Web APIs on SAP HANA Cloud
Platform.

00:00:24

Thank you Sven. So this week will be quite exciting because in this unit we will explore a
new technology on SAP HANA Cloud Platform which we have not
covered so far in the other units, and this is all about OAuth.OAuth stands for the Open
Authorization protocol and is the de facto standard for protecting cloud-based APIs.
In this unit, we will explore a scenario where we protect a Java application on HANA Cloud
Platform that exposes a RESTful API
to clients, such as a native mobile client application. And in order to protect this API,
we make use of the OAuth standard.So previously we used the SAML standard. Is this the
same as the OAuth standard?

00:00:35
00:00:46
00:00:55

00:01:08
00:01:16
00:01:31

00:01:41
00:01:53
00:02:02
00:02:12
00:02:27
00:02:35
00:02:41
00:02:51
00:03:04
00:03:15

00:03:29
00:03:39
00:03:49
00:04:02

00:04:17

Or what are the differences? SAML is used and has been designed specifically to protect
Web applications.
But a Web application typically comes with a UI and is not the same as an API.And as the
client that is used to access this Web application typically a browser is used.
And a browser understands technologies such as HTML very well, so it can render HTML.It
can also execute JavaScript. And this is exactly the assumption from SAML that the
client fully understands how to render HTML and also can execute JavaScript.But those
capabilities are typically not fulfilled very well by a native REST client
that is used, for example, by a mobile application.Those clients can only speak the HTTP
protocol but they don't understand how to render HTML
and to execute JavaScript. And this is why we cannot use SAML in such a scenario, or
SAML doesn't fit very well to those scenarios and we have to use a different standard.
And OAuth here, as I said, is like a de facto standard for those scenarios. So in order to
authorize a client to call an API exposed on HANA Cloud Platform protected by OAuth,
the client needs to obtain an OAuth access token.OK. This access token, which we see
here in the middle, seems to me a bit
like a password. Is this some type of user name and password authentication? Or what's it
like?
Right. In a way, a password and a token are the same from the perspective that they both
should be very long and hard-to-guess strings.
So an access token is also represented by a very long and random string that is hard to
guess.But, nevertheless, via transport, and this is the same as with passwords,
a token should be protected so the communication between a RESTful client and an API on
HANA Cloud Platform by default, is always encrypted using TLS
so that nobody in the middle can sniff that communication and obtain that access
token.However, there is a huge difference between access tokens and passwords in the
sense that a password may give an attacker
very broad access on behalf of the user to maybe not only one website, but maybe also
other websites. And after successfully logging in with the stolen password,
the attacker could probably do many, many things on behalf of the user.An access token in
OAuth has a very narrow scope compared to a password.
With an access token, a client such as a native mobile application can only invoke a
particular API that is protected using OAuth and accepts this token.
So even if the token gets into the wrong hands, an attacker may only use this token to
impersonate the user and invoke a specific API. But the attacker may not be able to use this
token
in a broader scope. So this is what makes OAuth and an access token a more secure
credential compared to a password in those scenarios.

00:04:27
00:04:37
00:04:48
00:04:56

And in addition to that, the access token actually can also be scoped further so that with the
access token, for example, you can specify that a client may only be able to
get read access to data, or only write access to data, or updates.This is expressed in the
OAuth specification as the so-called OAuth scopes.
And we will go into more detail into these OAuth scopes in the demo.OK. So now we know
that we need this access token. How can we get it?
Right. The way to obtain an access token from a client perspective is described in the
OAuth specification.The OAuth specification is a Request for Comments issued and worked
out by the Internet Engineering Task Force, the IETF.

00:05:12

The same place where other very important Internet standards and protocols, such as
HTTP, are also specified.The way a client obtains an access token on the HANA Cloud
Platform follows this specification

00:05:27

and is shown on this slide. In the very first step, an account administrator on the HANA
Cloud Platform
needs to register a so-called OAuth client for the RESTful application or client, for example
in this scenario here, our native mobile application on the HANA Cloud Platform.
The administrator does so in the HANA Cloud Cockpit.So he needs to register a client,
which results in a unique client ID that represents the
client application that works with OAuth and later on obtains the token to make authorized
calls to the API.
So after doing this initial administrative step, the client application can request an access
token from the OAuth server. And it does so by first redirecting the end user
to the OAuth authorization server, which is an infrastructure or service provided by the
HANA Cloud Platform and the user accesses the authorization server, for example, using a
Web browser.

00:05:38
00:05:49
00:06:03
00:06:14
00:06:31

00:06:50
00:06:57

00:07:13
00:07:26
00:07:39

00:07:51
00:08:02
00:08:12
00:08:19
00:08:22
00:08:32
00:08:43
00:08:56

And the OAuth server behaves like any other application on the HANA Cloud Platform.It will
redirect the user to a trusted identity provider.
And in order to authenticate the user, and after successful authentication, the OAuth server
will ask the user to confirm that the client application, for example, a native mobile
application
gets authorized to act on his or her behalf.If the user confirms this step, the native mobile
application obtains an authorization code.
This can be seen as a unique, one-time token that the application then uses still in step 2
to finally request the access token from the authorization server.
In this process of obtaining an access token from the authorization server, the native mobile
application in this example makes use of two different URLs that both point to the
authorization server.
The first one to obtain the confirmation from the end user.To confirm that the client
application is allowed to act on his or her behalf.
And in the second URL, the native mobile application then silently goes back to the
authorization server, presenting this authorization code obtained from the first step,
to finally request the access token.OK. So now we have in our mobile application the
access code?
Right.Do we have to do anything else then?
Right. The native mobile application then needs to securely store the access token so that it
cannot be read by any unauthorized application or user.
And then finally, it makes use of this access token to call, in step number 3, an OAuthprotected API on the HANA Cloud Platform.
And the platform makes sure that a token received by an API gets automatically verified by
the authorization server.
Basically step number 4 that is shown on this slide is something that you only have to
configure.You don't have to implement, as a developer, that validation step.

00:09:07
00:09:17
00:09:25
00:09:35
00:09:48
00:09:59

00:10:19
00:10:38
00:10:50
00:10:58

00:11:11
00:11:21
00:11:34
00:11:44
00:11:52
00:12:10
00:12:27
00:12:41
00:12:53
00:13:04
00:13:20
00:13:29

00:13:41
00:14:00
00:14:10

I will now show you in a demo how this whole scenario works end to end and how we will
configure an API to be protected with OAuth
and how the whole process shown here works in practice.OK. Ah, we have one more slide.
Right. This is just an introduction to the configuration steps we will do.Basically, as we also
did in the other units, to protect our applications,
we also apply the configuration for protecting our API in the web.xml file.We did this before
with SAML, for example, or with the roles that we specified.
So again in the web.xml file, we specify a so- called servlet filter.That filter configuration also
follows the Java EE standard.
And the HANA Cloud Platform SDK provides a filter class that is specified here in the <filterclass> element.So the SDK comes with this filter class that allows you to protect an API
using OAuth.
So it's a ready-to-use implementation that can be used to protect your API.In addition to this
filter, you can provide additional parameters that further limit the
possible access to the API, such as an HTTP method.So you can specify that access to
your API should only be allowed using the GET method of the HTTP protocol.
So if we would now do a POST method, this wouldn't work.Right. So POST wouldn't be
allowed by this filter declaration.
And you typically specify GET if, for example, you only want to provide read access to an
API.And again, in addition to those protection mechanisms, you can also specify what I
mentioned before
the so-called OAuth scopes. So in order for a client to successfully access an API protected
with this filter,
this client also has to obtain the scope "read- sales-orders" in this example for successfully
accessing this API to read sales orders.
And finally, you basically then apply this filter declaration to a servlet, for example, in your
Java application on HANA Cloud Platform.
So you simply provide a filter mapping that says this filter declaration should be applied to
this servlet, right.
So let's jump into the code.Again, the source code for this unit will be provided as additional
material for this unit.
It basically contains a simple servlet that returns some mock data for sales orders. And we
protect this servlet, or this API, with a configuration in the web.xml files.
And as seen on the slide before, we basically apply here a filter.Could you just zoom in
here? I think then it will be better.
As you can see here, we have specified the servlet class that returns the sales order data
and have specified a filter
declaration that protects this servlet using, first of all, a limitation on the HTTP methods. So
only GET should be allowed.
And in addition to that, it also specifies that a client that successfully or that should be
authorized to call this API has to provide a specific scope
that allows this client to read sales order data.OK. I see now here on the slide that we had
first the HTTP method and then the scope
and here we have now first the scope and then the HTTP method. So this doesn't matter?
The order doesn't matter. Again, basically this declaration follows the Java EE standard on
HANA Cloud Platform.
We just apply what the Java standard specifies, so the order of these parameters doesn't
really matter.OK. So after now defining and declaring those filter declarations,
we can deploy this servlet that's now protected using OAuth on HANA Cloud Platform.And
we already did so in my trial account.
As you can see here in the Java Applications, I now deployed that unit so my session
expired but I'm

00:14:22
00:14:35
00:14:44
00:14:53

00:15:06
00:15:23

relogged in and as you can see unit4, which contains the servlet, is already deployed.Now,
as you also saw in the web.xml, we specified a scope
that protects our OAuth-protected API.Now this scope also has to be made available to the
HANA Cloud Platform
and the OAuth authorization server so that the authorization server also knows about this
scope.And this can be done by configuring the scope in the Cloud Cockpit.
So we go into the Java application and find here an entry in the menu that says OAuth
Scopes.By clicking on OAuth Scopes, we get the chance to define a new scope for this
application.
And I think we called this scope "read-sales- orders". So let me just copy and paste that
value.And let's also give it a short description: Read sales orders
Let's save that.So now the scope is also known to the platform.

00:15:28

It's not only known within the application, but also now known within the platform.Now, as I
also showed in the slides, we need to register an OAuth client for, for example, our mobile
application.

00:15:44

In the scenario, by the way, we won't use a mobile application but a simple REST client
from the browser to simulate the native mobile application.
OK. Let's go into the OAuth client registration step.This is done here under OAuth on the
account level.
And there you see a tab called Client and this is the place where you register OAuth clients
that should be authorized to call your APIs.
So let's give it a name. Let's say this is the Sales Order Client And we have to assign that
client to our API.
So to the unit4 Java application.A client ID is generated automatically. You can regenerate it
or even provide your own client ID.
But let's keep it like this. And now we also need to specify a so-called redirect URI.So that's
a required value when you register an OAuth client.
And this is the URI where the authorization code is sent back from the authorization
server.Remember that one-time token that is used by the client to request the access token
from the

00:15:56
00:16:05
00:16:17
00:16:31
00:16:40
00:16:52

00:17:05
00:17:20
00:17:29
00:17:38
00:17:50
00:18:03
00:18:18
00:18:28
00:18:37

authorization server. So this is the place where we have to provide a redirect URI. And let's
just use callback.url/code
I think that's what I also have here. OK.This is enough information to register our OAuth
client.
Let's save that.And now we can start the process of obtaining an access token from the
HCP OAuth server.
OK. Do we directly use our client for this? What we will do now is we will use a RESTful
client, such as Postman.
This is a RESTful client that allows us to simulate the native mobile application.But as I said
before, in the first step, the user has to authenticate against the authorization server.
And confirm that this client should be allowed to act on his or her behalf.In order to do so,
we have to invoke a specific URL, which is also listed in the Cloud Cockpit.
We have this authorization endpoint. That's the endpoint that the user has to go to in order
to request this authorization code. And with the authorization code, the client
our Postman REST client will then invoke the second URL, this token endpoint here to
obtain the access token.OK. Then let's do this.
Let's do this, alright. Let's copy this URL.Actually, I already did so in my little script here.

00:18:46

And according to the standard, this URL has to specify a few parameters in the request,
such as a response code, the client ID, and here we have to enter the client ID from our
registration.

00:19:10

It also has to specify the redirect URI that we also specified before.And finally the scope that
this client should obtain.

00:19:19
00:19:28
00:19:37
00:19:50
00:20:01
00:20:10
00:20:24
00:20:36
00:20:45
00:20:54
00:21:08
00:21:24
00:21:35
00:21:51

And remember, we specified the scope as the read-sales-order scope.So now with this URI
that follows the OAuth specification, we can now
open a new Web browser tab, paste that URL here. And that should redirect us to the
authorization server.
Now, as you just saw, I was logged in by the identity provider.So the SAP ID service
authenticated me as the user. And now I, as the user, am asked
by the authorization server to confirm that this client the sales order client is allowed to
act on my behalf within a certain scope.
And this is the read-sales-order scope.So now I can either cancel or authorize that request.
So let's authorize this.
Alright. Now you see that the OAuth server redirected my browser to this redirect URI that
we also registered with the client. So certainly this must not be a URL that really exists
but the client, for example a native mobile application, should basically listen to such a
redirect and extract from that redirect URI the authorization code.
OK. So this is now the authorization code or the one-time password? This is the one-time
password, which the client will now use in the next step to request the access token.
And this is what we now do in our RESTful client, in Postman.
Basically, we will now create an access token request to the authorization server and again
we will use the URL that is shown here. Now we make of the second URL.
So we will have to send, according to the specification, a POST request to that
endpoint.And that POST request must have a set of body parameters
values that we have to provide in order to request a successful access token.One is the
code that we just obtained. Sorry, that's the wrong one.
That code needs to be passed as a parameter.We also have to specify the redirect URI
again.
And that is this value.So we definitely have to use here the same redirect URI.

00:22:00

Yes. And let me just look up the specification again, which other parameters we have to
provide in the token request.So I'm now again looking up this document that we saw before.

00:22:13

And the authorization access token, right.So you see, we also have to have to provide a
grant_type parameter.
And that is a fixed value here in the specification that says authorization_code.I think you
copied there the quotes.
And last, but not least, the fourth parameter with the client_id And again, we have to copy
that client_id from the cockpit because that was the result of our registration step.
So that is our client_id OK. So let's double-check again before we send that request to the
authorization server.
So we have a grant_type set to authorization_code We have the code that we obtained from
the first step when we, as the user, confirmed that the
client can act on our behalf. We have set the redirect URI, and that's it.OK. So let's try that
and send that POST request to the authorization server.
Aha. And the redirect URI doesn't match.So let's see why. I think we have missed a colon
here. Let's do this again.
Alright. And as a successful response, we now obtained the access token from the
authorization server.OK. So now this is stored usually securely on the native client and used
from then on to communicate with the API.

00:22:31
00:22:50
00:23:09
00:23:19
00:23:33
00:23:45
00:23:54

00:24:08
00:24:18

00:24:35

Exactly. This still represents a very secure and confidential credential.So it must be stored
securely by the client.
But again, this credential only allows this specific client to call a specific API.Compared to a
password, the scope of what a potential attacker or a man in the middle could do with this
credential is very limited.
Finally, now let's make a call to the API to see if it works.Maybe let's do this first without a
token and see if it's protected.

00:24:44
00:24:53
00:25:04

00:25:18
00:25:34
00:25:43
00:25:52
00:25:57
00:26:06
00:26:17
00:26:24
00:26:35
00:26:47

And then provide the access token so that we see if it works.OK. So let's do a GET request
to our API without the access token.
Send that. OK. And as we expected, HANA Cloud Platform basically returns that access is
unauthorized. So we get a 401 response.
Now let's provide the access token as a header. And that again follows the specification.So
the header has to be the authorization header with a value of so-called "Bearer" token,
space, and then the value of the access token.Alright. So now the expectation is when we
send this bearer token, this access token, as a header,
in the authorization header, our call should go through and the API should send us the
response.Let's see.
Alright. And here we see now we don't get a 401 anymore, but we get a successful
response with the sales orders for that user.
So this means our communication to the API worked successfully? Right.
And do we have to do anything else or are we finished? No. Basically, from a developer's
perspective, all you need to do is to apply this configuration,
register the client, specify the scope in the Cloud Cockpit, and that's it.All the integration
between your Java application and the authorization server to validate the token
that's all done by the platform and by the infrastructure.So you can fully rely here on HANA
Cloud Platform to take care of that.
Also you don't need to develop your own authorization server all of this is provided by the
platform.So only configuration applies here and then you can implement such a scenario.
OK. Then thanks a lot Martin for this overview of securing Web APIs on SAP HANA Cloud
Platform.We had a really good look here into the OAuth 2.0 standard.
That's all for this unit. Thanks a lot and see you in the next unit. Bye bye.

Week 2 Unit 5
00:00:11

Hi. Welcome to Week 2, Unit 5 of the openSAP course SAP HANA Cloud Platform
Essentials.In this unit, we will get started with securing SAP HANA native services on SAP
HANA Cloud Platform.

00:00:25

Thank you, Sven, and also welcome from my side.In this unit, we will start with a slightly
more complex scenario than the scenarios we discussed in the previous units of this week.

00:00:41

In this unit, we will look at a scenario where we will build our end-user-facing interface the
UI with an HTML5-based application.And this HTML5 application will invoke a RESTbased service

00:01:09

which is deployed on an SAP HANA XS system.In order to authenticate the user at the
HTML5 application,
we will use the mechanisms you learned in the previous units, which is SAML, so we will
use a SAML-based login of the end user against the HTML5 application in your SAP HANA
Cloud Platform account.

00:01:21

00:01:41
00:02:01

00:02:22
00:02:37
00:02:50

However, the RESTful service on SAP HANA XS also requires an authenticated user
because it retrieves or provides data for that logged-in user on the HTML5 side.
So in other words, the service on HANA XS needs to know who the logged-in user on the
HTML5 application is.And this is why we need to propagate the user from HTML5 to the
SAP HANA XS service.
So this will actually be the focus of this session.And this slide shows again the high-level
overview of the steps.
How the user will authenticate and propagate through this whole scenario.So in the first
step, the user accesses the HTML5 application
and will be redirected by the HTML5 application to the trusted identity provider of your
account.Again for this scenario like we did before we will use the SAP ID Service to
authenticate the user.

00:03:07

So the HTML5 application delegates the authentication to the SAP ID Service, the user is
logged on.And after logging in, the user will see a list of projects that this user is assigned
to.

00:03:22

So we will again make use of the same application scenario that we used also in the
previous sessions, this project management sample application.
But in order to retrieve the user's project information, the HTML5 application will call a
service which is running on HANA XS,
and in the underlying HANA database, project data is stored for the specific user.So in order
to retrieve only the project data for the logged-in user,
HANA XS needs to know who the user is who logged in to the HTML5 application.Just now
you mentioned HTML5 applications, but on the slides, I also see Java.
How does this scenario apply to Java applications? Our setup that we will do in this session
equally applies to Java-based applications.
So what you will learn in this unit and in the next unit applies to both types of application.So
HTML5 and Java can be configured the same to enable such an identity propagation
scenario.

00:03:32
00:03:45
00:03:59
00:04:09
00:04:17

00:04:33
00:04:41

00:05:02

But in our demo later, we will use HTML5.Right. So for this scenario, we will continue with
the project management application that we also used in the previous units.
Due to the complexity of this scenario, we decided not to cover it in one unit, but actually to
split it into two units.So this is why we will cover this scenario in two parts: part one in Unit 5,
and part 2 in Unit 6.
All right, so since we already learned how to set up SAML authentication against an HTML5
and Java-based application in your HCP account, we will not go into the details again in this
unit,

00:05:19

but we will mainly focus on the configuration for this identity propagation, forwarding of the
logged-in user from one application to another.In this case, from the HTML5 application to
SAP HANA XS.

00:05:34

So that will be the focus of Units 5 and 6.So let's go into some of the details of how this
scenario is set up.
On the HTML5 side, in your SAP HANA Cloud Cockpit, we will have to configure a
destination that will be used by the HTML5 application
to invoke the service on SAP HANA XS.On the SAP HANA XS side, we will develop a
simple REST-based service that retrieves the data from the database, from the table,
and exposes this data in JSON format to the HTML5 application so that it can easily show
this data in the UI.Okay, I also see that SAML is mentioned here under the API.
What technology exactly is used here for this? It's not exactly the SAML 2.0 protocol that is
used to log in the user against the HTML5 application.
But actually for this identity propagation, a subset of the SAML standard is used, which is
the SAML assertion.So the SAML assertion is a core element of the SAML standard which
specifies the token format of the identity information.

00:05:46
00:05:56
00:06:12
00:06:30
00:06:42

00:06:59

And exactly this is used to propagate the user information securely from HTML5 to HANA
XS.So we make use of a part of the SAML standard, which is the SAML assertion which is
used by the HTTP destination,

00:07:15

which will be configured with an authentication method called App-to-App Single Sign-On,
or Application-to-Application Single Sign-On Authentication,
which will generate a SAML assertion for the logged-in user.So that SAML assertion
contains all the information about the logged-in user.
And that secure container of the identity information is used to propagate the user between
the different application scenarios, so the HTML5 application on the left-hand side, and the
SAP HANA XS service on the right-hand side.

00:07:25
00:07:38

00:07:56

So I don't have to log in every time in the back end. It's just propagated from the front end to
the back end.Exactly. From the end user perspective, the benefit here is that it happens
seamlessly.

00:08:12

The end user doesn't actually recognize that his identity here is forwarded or propagated
between these two applications.From an end user perspective, the end user only
recognizes once when he or she logs on against the HTML5 application with the SAP ID
Service.

00:08:30

But that propagation is not actually visible for the end user because it happens in the
background, using "back-channel communication" between the HTML5 application and
HANA XS.

00:08:44

In order to trust that information on the HANA XS side, we also need to apply cryptographic
mechanisms here, so that HANA XS can be sure that this information propagated by the
HTML5 application comes from a trustworthy origin.

00:09:04

And this is why we need to set up a trust relationship between the two.In other words, the
HTML5 application and this equally also applies to Java-based applications basically
acts here as an identity provider.

00:09:23

Because it provides identity-based information of the logged-in user to its counterparts.So in

this case, to the API or to the REST- based service that provides this project information for
the logged-in user.

00:09:40

So this is why it's very important that for this type of scenario you have set up a trust
relationship between the SAP HANA XS system and the HTML5 application.
So the SAML assertion generated by the HTTP destination will be signed by a key pair, and
that key pair belongs to your local service provider,
which you can configure in the Cloud Cockpit for the HTML5 application.And that key pair,
along with some additional data, will be imported as a trusted SAML identity provider on the
SAP HANA XS side.

00:09:55
00:10:09

00:10:27

So, one last but very important aspect of this scenario.As you may know, on HANA XS I can
only authenticate as a user if I have a corresponding database user in the HANA database.

00:10:44

However, for a scenario like this in the cloud, this may not always be the case.For example,
if you have an end-user-facing application on HTML5,
you may not already have all the users created in your HANA database.And this is why
HANA provides a very convenient way to create those users on the fly.
So if a propagated user successfully authenticates against HTML5 and then is successfully
propagated to the HANA XS system,
this user can be dynamically created just in time at the time of propagation in the HANA
database, and this is controlled by a flag that you have to set on the entry for your trusted
identity provider

00:10:51
00:11:04
00:11:15

00:11:32
00:11:45

in HANA XS, and this is called "dynamic user creation".So if HANA XS recognizes that this
user currently does not exist and this flag is set,
then it will create that user in the database.You can also assign a so-called "default role"

00:11:53

so that this user obtains the correct role that it may need for your scenario, and we'll actually
do this in this scenario, so that after dynamic creation, this user obtains the required roles to
also access the data in the database.

00:12:14

Okay.So with that, we are done with the instructions or introduction for this scenario.

00:12:24

In Unit 5, we will cover the first part of this scenario for configuring the local service provider
in the Cloud Cockpit for the HTML5 application.
We will set up this required trust relationship between the local service provider on HTML5
and the identity provider on the HANA XS side.And we will make sure that this dynamic user
creation is enabled for our scenario.

00:12:37

00:12:54

For the second part of this scenario, we will then look into the destination configuration for
this app-app single sign-on authentication method.We will configure XS for SAML so that it
can accept this application-to-application single sign-on SAML assertion.

00:13:19

And finally, we will test the scenario.Okay, then let's go into the demo.

00:13:24
00:13:42

Before we start with the demo, let me also point you to a blog post that is available on the
SAP Community Network.It's basically about this scenario.
With this blog post, you can also follow step by step what we will do now in this demo.So
just to let you know that everything about the scenario described here is also available in
this blog post.

00:13:57

And we will also provide a link to the blog post in the slides.All right. Cool.

00:14:03

So let's get started with the service provider configuration on the SAP HANA Cloud
Cockpit.What we need to do first is the service provider configuration for our HTML5
application in the SAP HANA Cloud Cockpit.

00:14:28

This is done in the Trust settings of the Cloud Cockpit.And while it is loading, we can...

00:14:39

So right now we are on Configuration Type: Default, which means we by default make use
of the SAP ID Service for authentication.
For this scenario, we will actually stay on this configuration type.However, as I explained
before, we need to have an account-specific key pair to sign the SAML assertion
that is generated for this app-to-app SSO mechanism.So this is why we have to configure
this key pair.
And this is done by switching from Default to Custom, and as you can see, there are two
entry fields available for providing this key pair.
So we will now generate such a key pair, which always consists of a private key and a
public key contained in a so-called "X.509 Certificate".And later on, we'll build the trust
exactly to this key pair on the HANA XS side.

00:14:49
00:15:04
00:15:10
00:15:21

00:15:36

So now let's get started with generating those two keys.We could either generate the key
pair.

00:15:41
00:15:55
00:16:12
00:16:24
00:16:42
00:17:01

For this scenario, I will generate the key pair with a tool called OpenSSL.I have already
prepared a statement here which allows me to do so.
So I will generate the two values, so that private key and the certificate for this signing key
pair.So now I have created two files: the certificate file and the key file.
In order to import the key file, the private key, into the Cloud Cockpit, I also need to
transform that key file into a slightly different format,
which is called pkcs8, which is an unencrypted representation of that private key.So now I
have three files, and I now need to open those two files.
Let's start first with the private key file.And I just need to copy the values of this private key
without these begin and end tags,
and just copy & paste them into my Cloud Cockpit.So this is the Signing Key.

00:17:08

Are there any benefits or drawbacks in using the generator here in the Cockpit or the one
with OpenSSL on your command line? The reasons why I have now generated these key
pairs here with this OpenSSL tool are that

00:17:26

first of all, I can define my own validity or expiration for that key pair, so I can control how
long those keys should be valid, and second, I could even use this generated key pair here
or the certificates to obtain a certificate

00:17:47

that can be signed by a publicly trusted certification authority.So there are a few benefits of
doing it like this, but you can also generate the key pair using this tool.
But just be aware that when you generate the key pair using this tool, you always generate
a self-signed certificate.Actually, we will do that here right now, so this is also just a selfsigned certificate.

00:18:01

00:18:11
00:18:26

But if you do it with this mechanism here, I would only recommend you do so in a nonproductive scenario.Okay, so let's also open the second file, the certificate here.
So this is called spcert.pem.And also just copy & paste the content in between those tags.

00:18:40

Paste it here.I saw that you used a different name for the local provider name.

00:18:45

All right, I need to change that as well, right? Because in the certificate now, my slightly
changed provider name is used.So I'll change that here as well.
Right, and with that, I'm now done and I can save my settings.And... okay, so let's wait for a
second.
Okay. So, now I have configured the signing key pair, which is used later on to sign the
SAML assertion for that app-to-app single sign-on mechanism.
But as I said before, we still want to use the SAP ID Service to authenticate the user against
the HTML5 application.And this is why I'm now switching back to Default.
Just note here that the settings won't be lost, so they are still kept in the background.

00:18:58
00:19:10
00:19:25
00:19:37
00:19:46
00:19:56
00:20:08

But if I switch back to the Configuration Type: Default, as you can see here, I'm now back to
SAP ID Service to authenticate my user.
It's more like that for the HTML5 app in the front end we use the default authentication, and
then for the back end, for between the front end and the back end, we use the local one.
I have just forgotten one last step, which I can do by simply switching back to Custom.As
you can see, the values are still there, and I now have to download the metadata for that
service provider.

00:20:21

So let me download that metadata.And open that here in Notepad.

00:20:29

So this is now the SAML-2.0-based metadata for this local service provider.And I can just
cancel it so I'm back to Default.
Now I need to import this metadata as a trusted identity provider in my HANA XS
system.And I'm here on the XS Admin Tool for my MDC container.
By the way, for this scenario we are also using a multidatabase container on the trial
landscape, so I created this one before this unit
because it behaves like a dedicated database.So now let me import this metadata as a
trusted identity provider to establish this trust relationship.

00:20:39
00:20:55
00:21:08

00:21:22
00:21:34

So by clicking on Identity Provider, currently there are none in the list.I can add one by
clicking on this plus sign, and this allows me here to copy & paste the metadata.
So I'll just copy... and paste it here.If I now click on Save, you will see that...

00:21:46

the values are prefilled.Ah, my session expired. Let me repeat that step.

00:22:28

So now you import it again, just as we did before, and save it.Okay, here we are.

00:22:40

You see that all the values retrieved from that metadata file have been used to prefill those
entry fields.However, since we did not provide metadata for an actual identity provider but
only for a service provider,

00:22:54

00:25:04

which on the HTML5 side, acts as a little identity provider, we have to provide two additional
fields here by simply providing some dummy values,
which just need to be filled in here in that form so that we can save these settings.So we
can just enter two values here.
It doesn't actually matter what we provide here.And last but not least very important we
have to click this Dynamic User Creation flag
because we want to create users that do not yet exist in the HANA database for our
scenario.Right, now we can save those settings.
And you see a little error here that says "Error during certificate input".Now, we are here on
SPS 10 for the HANA database.
This is why we need to issue another three or four SQL commands to actually import the
certificate that was part of this metadata into the HANA database.
If you are on a lower SPS, like 9, then you can forego these last steps.So let me do these
last steps for you.
I'm now connected to my MDC container, so first of all I'd like to check whether an HTTP
destination has been created for my new identity provider.
So you see that part of this import step was that for this identity provider that we just
created, an HTTP destination has been created in the database.
Now the next step is that we create the certificate in the database.And we still have the
certificate here in the editor.
So let me just paste that here.So with that SQL command...

00:25:17

we create the certificate.Okay, successfully created. And last but not least...

00:25:28

we have to add that certificate to...Oh, first of all, we need to know which number,

00:25:36

which ID that certificate has got in the database.Let us see.

00:25:43

Okay, here it is. So that's the number.Let's copy that.

00:25:51

And now add that certificate, based on this unique ID...that it got in the database to our socalled PSE file,
which contains all the certificates and graphic information for SAML-based authentication on
that HANA XS system.Again, if you are on a lower release, you don't need to do all these
steps.

00:23:05
00:23:15
00:23:28
00:23:37
00:23:48
00:24:02
00:24:13
00:24:31
00:24:45

00:26:01

00:26:14
00:26:23
00:26:29
00:26:47

But if you are on an MDC container, for example, so on SPS 10 or above right now, you
need to do this.And these steps are also explained in the blog post.
Right, those are all explained in the blog post.So with that, we are done, Sven.
I have now configured the trust relationship between HANA XS and HTML5.Okay, so we will
continue with this scenario in the next unit.
Thanks for listening to this unit, and see you in the next unit. Bye bye.

Week 2 Unit 6
00:00:11

Hi, and welcome to Week 2, Unit 6 of the openSAP course SAP HANA Cloud Platform
Essentials.In this unit, we will continue securing SAP HANA native services on SAP HANA
Cloud Platform,

00:00:23

which we started in the previous unit.Thank you Sven, and welcome from my side. Again, in
the last unit of this week.
As we started in Unit 5, we'll look at an identity propagation scenario between an HTML5based application that runs our user interface,
that accesses data from an SAP HANA XS- based RESTful service.To retrieve this data,
identity propagation is required to propagate the logged-in user
on the HTML5 side securely to the SAP HANA XS service, so that the correct data is
retrieved from the database only for that logged-in user.
To enable this scenario, we so far configured the local service provider on the HTML5 side
in the HANA Cloud Cockpit.
This was required because we need a specific key pair that is used to digitally sign the
SAML assertion
that is used to propagate the logged-in user's identity from HTML5 to SAP HANA XS.And
we imported this key pair, or basically just the X.509 certificate of the key pair,
along with some additional data about the SAML identity for the local service provider on the
HANA XS side, and imported that as a SAML identity provider to SAP HANA XS.
By doing so, we established a trust relationship between the HTML5 application and SAP
HANA We also made sure that users who don't yet have a database user in HANA
database will be created on the fly.

00:00:33
00:00:47
00:01:02
00:01:15
00:01:30
00:01:43
00:02:04
00:02:17

00:02:38
00:02:53
00:03:06

We did so by setting a flag on the SAML identity provider entry on the HANA XS side for
dynamic user creation.That ensures that even if the user does not yet exist in HANA DB,
if that user was successfully authenticated on the HTML5 side and was securely propagated
from that trustworthy source the HTML5 application to HANA XS,
that user will also be created in the HANA database.This is basically what we did in part 1.

00:03:14

In part 2, we'll continue with the scenario and test it in this unit.Based on that trust
relationship and the dynamic user creation, we'll now configure the application-level artifacts
on both sides.

00:03:32

We will start by configuring the HTTP destination that is used by our HTML5 application to
call the XS-based RESTful service.
To securely propagate the identity, we use this application-to-application single sign-on
authentication method, which is set as the authentication method for that HTTP destination
in the cloud cockpit.

00:03:45

00:04:05
00:04:20
00:04:34
00:04:51
00:05:02
00:05:15
00:05:27
00:05:40

To accept the generated SAML assertion on the HTML5 side, we have to configure our
REST-based service in the HANA XS system to work with SAML,
so this results in a configuration of the application package in the XS admin tool.So we
configure this package for SAML-based authentication.
OK, then let's see the demo. All right.Let me switch to my Web IDE.
To remind you how this HTML5 application works It basically uses a destination with the
name xsprojectdata
that is used when the application makes a call to this subpath, so api/projects makes use of
the destination with the name xsprojectdata,
which we have to configure in the HANA Cloud Cockpit.We need to remember that name as
it is configured in the neo-app.json file of our HTML5 application.
Going here, in the cloud cockpit of our account to the Destinations, we can create a new
destination and give it exactly the name that we chose in the neo- app.json file
This will be the name of our destination.The URL has to be the URL of our XS-based
service, and that's what we configure here.

00:05:55
00:06:14

For authentication, we now have to select application-to-application single sign-on.Let me

quickly give you more details about this generated SAML assertion
because in addition to those settings we have to set an additional property on that
destination.By default, the generated SAML assertion is intended for the service provider
that is configured in the cloud cockpit.

00:06:32

Basically for the service provider that is used by all Java and HTML5-based
applications.However, in this scenario, the SAML assertion will be received by the HANA
XS system.

00:06:47

That HANA XS system has a different service provider configured for SAML.This is why we
have to set the right recipient in that destination
for the SAML assertion that will be generated based on the app-to-app SSO authentication
mechanism.That additional attribute or property on the destination is called
saml2_audience.

00:06:58

00:07:13

"audience" because we have to set the name of the audience for which this SAML assertion
is intended as an additional property here.To find out the right value, so the name of the
service provider of the HANA XS service,

00:07:30

we can look it up in the XS admin tool.I'm now connected to the HANA XS system, to the
MDC container of my trial account,
and I can look up the SAML service provider in the XS admin tool, and I now have to copy &
paste this name, exactly as it appears here, into my property.
One more thing that you used here is the URL to your application. Could you show us how
to find that? You can also see that here in the XS admin tool, so if I go to Artifacts
Administration,

00:07:41
00:08:00

00:08:17
00:08:37
00:08:53
00:09:00
00:09:12
00:09:20
00:09:35
00:09:58
00:10:13
00:10:28
00:10:40

I see here in the sample package, I have the xproject application, and in this package, I've
stored the xsproject file.
That's here in my repository, that xproject.xsjs file.Opening this for a second, you see that it
selects the projects of the user that is propagated securely via the app-to-app SSO
in this where-clause.Here, it's called projectLead in this project table
and this value is set for the user ID of the logged-in user. OK, then let's save the
destination. All right. That's a good idea.
So let's save the settings here.Oh! Session expired. OK...
Maybe we need to enter the values again? Maybe we need to enter the values again, but
fortunately, I have them here in my cheat sheet.
Right, OK. The URL... the properties...For these steps, we're following the blog post that we
showed in the previous unit.
On the slides again, there's the link to the blog post. You can just follow the demo via the
blog post.OK. Let's try again and save that.
Now we've created the right destination under the correct name.We've now created the
HTTP destination on the XS side.
Now we need to make sure that the user that is propagated by this destination also obtains
the right role.Let me also give you a short overview of what we have done here.
As you can see in the project for that XS-based service, a design-time role is configured that
requires the user to have this projectMember role in the project to be able to read and write
data to the project table.

00:11:00

This means that dynamically created users ideally have to be assigned automatically to that
role.To do so, we first have to create a runtime role, which creates this design-time role.

00:11:18

This is done here in the studio by creating a new role, and let's call the role
DEFAULTROLE_PROJECTMEMBER.And assign to that role our design-time role
projectMember.

00:11:42

Now we can save that. Now we have a new runtime role with the name
DEFAULTROLE_PROJECTMEMBER.To assign this as the default role to the dynamically
created users,

00:11:57

we have to open the administration and go into the configuration of our MDC container, filter
for SAML, and add as a new parameter the key defaultRole with the value of our newly
created runtime role,

00:12:30

which is this here. And finish that.By adding this as a new configuration parameter, we
make sure that users created by the dynamic user creation flag
are assigned to this DEFAULTROLE_PROJECTMEMBER runtime role, which contains the
correct design-time role of our project so that users can actually retrieve the data from the
table.

00:12:51

00:13:09

Last but not least, if we go back to this overview, we also need to make sure that our
service is configured for SAML.Otherwise it won't be able to accept or retrieve the SAML
assertion and log in the user based on our HTTP destination.

00:13:32

Let's go back to the XS admin tool.This is where we can configure those settings.

00:13:41

In the XS Artifact Administrations, let's go back to the sample project here and as you can
see, right now only Form and Basic are configured as the authentication methods.
We'll now change that to SAML.Editing this, we'll disable these authentication methods and
make sure that only SAML is used.
We also have to assign one of our identity providers, which is trusted for SAML-based
authentication, and which also includes this app-to-app SSO mechanism.
The issue of our SAML assertions for the app-to- app SSO destination is exactly that
identity provider that we imported in part 1 of this unit.By doing so and clicking on Save,
we've now made those changes.

00:13:56
00:14:07
00:14:21

00:14:41
00:14:53

I believe that we're now done with our configuration for this scenario.We can now see if it
works.
Let's try to start the app and...Before we do that, let's take a look at what we expect.

00:15:01

We expect a list of the projects for the currently logged-in user and let's see how many
projects that user has in the database.Let's select the projects from that table, and you can
see that there are three projects listed.

00:15:22

And all three are assigned to my p-user that I'm using to log on.We expect that if we now
log on to the HTML5 application,
after successfully authenticating with this user against the SAP ID service, that user ID will
be propagated via the app-to- app SSO destination to SAP HANA XS.
The user will be logged on and also ideally created dynamically, and assigned to the default
role, which allows the user to retrieve the data from the project table.
So let's see.Let's go back to our cloud cockpit. Let's see the URL for the HTML5 application.
That's the xproject application.
That's the URL. Let's open the URL in a new, private window.That's the landing page. Let's
click on Login and let's log in with this p-user.
We've now authenticated successfully against the identity provider Now the user is
propagated from HTML5 to XS, and let's see if we now see a list of our projects
Et voil! And so the user should now have been created in our back-end system? Let's
check that. I hope so. And actually I assume so because otherwise we wouldn't see any
data. But let's see.

00:15:32
00:15:44
00:15:58
00:16:09
00:16:37
00:16:52

00:17:03

Let's go back to our administration console and click on Users.Et voil! We've now
dynamically created the p- user in the database based on the settings of the identity
provider,

00:17:18

and if we double-click on the user, we also see that the user has been assigned to the
DEFAULTROLE_PROJECTMEMBER as we configured via this configuration parameter.
So with that, we're through this scenario.Slightly more complex than the other scenarios in
the previous units
but in my experience very commonly used on HANA Cloud Platform and therefore worth
exploring in this essentials course.Thanks a lot Martin. What we've seen in this unit and in
the last unit, so the two together in a bigger scenario,

00:17:33
00:17:41

00:18:02

we used an HTML5 application as the front end, but we can also use a Java application that
works similarly.In the back end, we used an SAP HANA native service, and we secured
both and propagated identification.

00:18:16

I hope you learned a lot in this unit. Thanks a lot and see you next week. Bye bye.

www.sap.com

2016 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form
or for any purpose without the express permission of SAP SE or an SAP
affiliate company.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE (or an
SAP affiliate company) in Germany and other countries. Please see
http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for
additional trademark information and notices. Some software products
marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for
informational purposes only, without representation or warranty of any kind,
and SAP SE or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP SE or
SAP affiliate company products and services are those that are set forth in
the express warranty statements accompanying such products and services,
if any. Nothing herein should be construed as constituting an additional
warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue
any course of business outlined in this document or any related presentation,
or to develop or release any functionality mentioned therein. This document,
or any related presentation, and SAP SEs or its affiliated companies
strategy and possible future developments, products, and/or platform
directions and functionality are all subject to change and may be changed by
SAP SE or its affiliated companies at any time for any reason without notice.
The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking
statements are subject to various risks and uncertainties that could cause
actual results to differ materially from expectations. Readers are cautioned
not to place undue reliance on these forward-looking statements, which
speak only as of their dates, and they should not be relied upon in making
purchasing decisions.