Hi, I am Denys van Kempen from SAP’s Partner Innovation Lab and the SAP HANA Academy.
In this video tutorial series, we are going to cover the security aspects of the HANA
Academy app generator, authentication and authorization.
This video was recorded in May 2021.
For the latest video tutorials on the topic, please check the playlist.
In the first two videos of this tutorial we did a quick walkthrough of our generated business
app without and with authentication.
In this video, we are going to generate version number 3, this time adding authorization.
Same procedure Open Template Wizard
SAP HANA Academy CAP Give the app a new name
appsec2 Same settings as before,
but this time with both authentication and authorization enabled.
Click next, and the app is generated.
Let’s start with the configuration of the app router, the front-end,
file xs-app.json.
To provide authentication, we changed authenticationMethod from none to route
and added xsuaa as authentication type for both the service back-end as for local
static files.
To add authorization, we also need to specify the scope.
Here it is viewer for both.
It makes intuitive sense to give a view privilege the name Viewer,
but you can give a scope any name you want, which itself is defined in the xs-security.json
file, as we will see in a minute.
Next is the service definition file, CDS,
for the back-end service.
With @restrict we specify how the scope maps to a specific privilege.
Here the action boost is restricted to anyone with the Admin scope,
allows to make changes.
The calculation view and function are view-only.
Authentication is obtained with an @requires authenticated-user,
as we saw in the previous video.
leaving this out makes the back-end service accessible to all.
Next, xs-security.json.
With this file we configure the XSUAA service instance,
Only exists when authentication is enabled.
Let’s start with the basic configuration, just authentication
tenant-mode = dedicated You could share the XSUAA service for several
business applications.
Here we are only using this config for a single app.
Single scope this isn’t much of a scope, really,
it is only used to pass the authentication along with the J.W.T, the jot, the JSON web
token Also a single role-template.
We explained this in the previous video, how this works with scopes, roles, role templates,
and role collections, some of them design-time,
some of them runtime.
Here we have the configuration that includes authorization.
Two scopes: Viewer and Admin The $XSAPPNAME variable will be populated
when we deploy our app; we will see this in a minute.
Role: templates.
Same.
This allows us to bundle scopes.
Here we have only a single scope for each role template,
but we could add, say, a scope to read, to update, to delete, to insert,
whatever would make sense to our business app
Then we also have role collections, and this allows us to bundle roles, same principle.
Finally, the configuration file for our Node app, package.json
This is the same as before.
For authentication, we had to add the @sap/xs env and the xs sec packages, plus passport.
This remains the same for when we add authorization.
The only difference is in the mock data, for local deployment and testing,
where the Admin and Viewer roles have now been added to the users.
That’s it.
As before, let’s first remove the previous deployment.
Then build the app.
While we are waiting, we can quickly review the mta.yaml file
It is the same as before, there are no authorization-specific settings
We have our modules, with the uaa service as required
for the deployer, the server,
and the app router the uaa service itself is defined as resource
with the xs-security file as parameter file not strictly required, we could also have
included them here but for more complex configurations, this
is not really recommended.
Let’s deploy the MTAR Fast forward,
and our app is deployed.
Back to the BTP cockpit.
Here we have our instances and Cloud Foundry environment.
If we then navigate to security, roles we can see the roles for our business app
listed, with the description provided.
Same for the role collection Notice that the $APPNAME variable has been
resolved to appsec2.
We can use the BTP cockpit to add users to roles.
For production systems, you probably would not be using the default identity provider
of the platform, SAP ID services but an enterprise IdP like
Microsoft Azure AD, for example, Where you would add users to roles
and map the role collection defined here with the roles in your identity provider.
For our sample use case, we wil be using SAP ID services,
and we could have assigned role collections to users here as well, same thing
okay, let’s navigate to our app.
We have already looked at this in the previous videos,
let’s just capture the URL for the app router then open a private window
log on HTML5
User info lists the contents of our web token identified and authenticated with the Viewer
scope and this allows us to view the data presented
by the calculation view, for example.
but when we open our Fiori app and try to boost our sales a bit
we are getting an error.
Let’s add the Admin scope to our user wrapped in a role and role collection
log on again user info
we now have the required role boost sales
refresh and sales have been boosted
If only it was that easy!
Very well so much for our demonstration of how authentication
and authorization works for a sample business application as generated by our SAP HANA Academy
CAP template.
If you would like to learn more, we have posted a number of video tutorials about XSUAA and
Cloud Foundry, you will find the reference in the description
of the video below Don’t forget to subscribe.
Denys van Kempen, SAP HANA Academy / Partner Innovation Lab
Thanks for watching