Hi, my name is Denys van Kempen, SAP HANA Academy.
You are watching a video tutorial that is part of a series about SAP Business Technology
Platform certifications, part of the playlist SAP Certified Development Associate - SAP
HANA Cloud This tutorial covers the topic area Application
Security This video was recorded in September 2022.
For the latest tutorials on the topic, please check the playlist.
The topic area Application Security has a 10% weight, about 8 questions.
We already covered some aspects in a previous video in this series, when we discussed the
approuter. Here we have the authorisation flow.
Business user connects to business app, the endpointm, the URL, the link, connects first
to the approuter, the request is routed to an instance of the
User Account and Authentication Server, (UAA), the identity management service for Cloud
Foundry, as implemented by SAP for the Business Technology
Platform, called XSUAA, the authorisation service,
which routes the request first to an I D P, an Identity Provider,
which, on the Business Technology Platform defaults to SAP Cloud Identity services
but any SAML-compliant IdP could be configured, like Microsoft Active Directory, for example,
one of the most common enterprise identity providers around.
SAML, by the way, is a protocol in XML format for security assertions (SA), hence the name,
you are not expected to be intimately familiar with SAML and J W T, pronounced “jot”,
which stands for JSON web tokens, JSON, JavaScript Object Notation,
a more lightweight standard to exchange security information, which became popular with the
use of mobile devices, SAML is a bit older, XML tends to be a bit
heavy in terms of the amount of data required to exchange
again, on the side, for your information
at step 4 the user is prompted to authenticate
with the IdP (you may have seen this screen before)
a certificate may be used, or user name password
if this matches with the information maintained by the IdP, a SAML message is returned to
XSUAA,
which then checks the authorisations of the user for this request,
the privileges, the roles, required,
generates a web token, a JWT, with either a green or red light for the request
sends it back to the approuter,
which attaches the token, the JWT, to the original request, in case it is green,
and routes it to the business app,
or back to the user, in case it is red, with a non-authorised message
that’s the authorisation and authentication flow for business apps in the Cloud Foundry
environment
For more information about SAP Cloud Identity Services, visit the SAP Discovery Center
Here we can see that Identity Services provides a single solution for identity authentication
(the flow we just looked at) and identity provisioning for all SAP Cloud Business Applications,
with delegated authentication, as we just mentioned, to a corporate IdP like Active
Directory
Here we see this in a bit more detail
the different authentication methods, username/password, X.509 certificates, 2FA, two-factor authentication,
and so on, no need to memorise this.
documentation, tutorials, tools, all the information you need
The UAA service itself, is a Cloud Foundry concept, which we find documented on cloudfoundry.org
also recommended is the development guide for the Cloud Foundry environment,
section Adding Authentication and Authorization
here we find the same illustration
with an explanation how we can configure authorization by creating an application security descriptor
with an xs-security file,
where we define scopes, the different actions, privileges, valid for the business app
which we can fine-tune with attributes
Links to tutorials, for the different languages and frameworks,
pointing to the developer center
with hands-on exercises
creating the security descriptor, xs-security.JSON,
the approuter,
and so on.
Let’s go through this step-by-step.
==
As before, if you want to follow along,
Combine CAP with SAP HANA Cloud to Create Full-Stack Applications on the SAP Developer
center
Add User Authentication to Your Application (SAP HANA Cloud).
When we added the approuter, a template xs-security.JSON file was created, listing scopes, attributes,
and role-templates as empty arrays.
We are going to update this file but first let’s make some changes to CDS that defines
the service model, CatalogService
with @requires we indicate the user needs to be authenticated, made a round-trip to
identity-provider, before the Interactions Header can be accessed,
with @requires Admin, we specify that not only the user needs to be authenticated, the
user also needs to be authorised, the Admin role-collection is required before
we can grant a READ on entries in the language DE, German, for all interaction items
Next, we are going to update the security descriptor, xs-security.JSON
as we have already defined with @requires what is required, we can simply use the cds
compile srv (service) with parameter to xsuaa, output to the xs-security.json file
and this will update the security descriptor for us,
we only need to add the name of the business app, whether this configuration is shared
with other apps or dedicated, and a section which enables us to the test the security
configuration when developing applications using the Business Application Studio (but
this is beyond the scope of the exam)
Now that have a security descriptor, we can create a service instance of the XSUAA service
in our Cloud Foundry environment
if we briefly switch back to the illustration,
we are now creating a dedicated XSUAA service for our business application
which,
we can then view
in the SAP BTP Cockpit
next, we also need to create a service key,
so we can bind the service to CDS,
the same as we did with the HDI Container
now, we are going to add a role collection,
we could do this programatically, but here we are using the BTP Cockpit
GIve the role collection a name
Edit
add the role name
and, for now, add a user
so we can test if new service model with @requires is functioning correctly
using the default identity provider, SAP Identity Services, for the platform
Now that we have a service instance of XSUAA configured and updated our service model,
we now need to make some changes to the approuter
first, we are going to revoke the changes we made before
authentication method = route
and authentication type = xsuaa for both routes, root and app (approuter), for the static content
we added a bit more code for what to do when the users performs a logout
and how to handle a request to the user-api endpoint, which we will demonstrate in a minute
again, no need to memorise each and every parameter,
just the major pieces, the approuter configured with xs-app.JSON and the XSUAA service instance,
configured with xs-security.json
Let’s connect to the CDS server
and try to access the interactions header
this returns a 401 message unauthorised
We are now going to bind CDS to the approuter and start the approuter with a single command
application router is listening on port 5000
and if we now access the header
(spoiler alert: I actually had to logout and logon to get this to work)
but now we can access our header data again, using the service endpoint
same when using the web application
if we now paste user-api / attributes as endpoint (as a reminder, we just added this as route
to the xs-app.json file)
and this list the attributes in the JWT (the web token)
with the scope, appname, and role
one more thing,
My colleague Raja Gupta posted a series of technical articles about the fundamentals
of SAP BTP Security
covering the role of the IdP
SAP ID Service,
Cloud Identity
XSUAA
the application router
and the call flow, which we showed at the start of this video
continueing with OAuth and SAML
JWT
how to secure a Node.js app, step by step, sample code on GitHub
highly recommended
and that’s it
You can find the links to the resources mentioned in the description of this video below.
This video tutorial was recorded by Denys van Kempen, SAP HANA Academy.
Any good? Give us a like, and for updates, don’t forget to subscribe.
Thanks for watching.