Hi, I am Denys van Kempen, SAP Digital Partner Engineering
Welcome back, video number two where we are going to show how security is actually implemented
on the SAP Cloud Platform Cloud Foundry environment, addressing both authentication and authorization.
In the first video, we showed our sample app with the legacy XS classic (XSJS) code running
in the Neo environment, and also the equivalent, XS Advanced / Cloud
Foundry implementation using microservices.
We looked at the code, what it does, and how we can deploy a multi-target application (MTA)
using SAP Business Application Studio with the integrated MTA Build Tools.
In this video, we will be using a Yeoman generator to create, build, and deploy this business
application for us, easy does it, with security build in.
First, we will show you how to get the app up and running,
then we will do a quick code walkthrough explaining the pieces,
So you know how it works.
There is no magic, what we need is an SAP Cloud Platform account,
the trial suffices.
Optionally, this depends on your selections, as we will see in a minute, you will need
an SAP HANA Cloud database instance, and set up the trust between the database
and the XSUAA service instance, between the Oauth resource server and the
authorisation server, that is, but you skip this part as well,
we have a whole series about getting started with SAP HANA Cloud, how to create an instance,
and how to configure this trust.
For more information, see the description below of this video on our YouTube channel
Connect to the App Studio, Let’s start from scratch
Create a new dev space Basic
with the MTA tools extension
Enter the dev space Open workspace
and connect to the Cloud Foundry environment Confirm the API endpoint
Enter your credentials for the SAP Cloud Platform trial,
Select the org, and space
and we are all set
Again, standard setup, covered in our SAP Cloud Platform onboarding tutorials series.
Find Command, enter yeo
and select the Yeoman Generators
If you are not familiar with the open-source client-side scaffolding tool Yeoman, take
a look at the website yeoman.io
A generator for a Basic Multitarget application is provided but we need to install another
one.
enter saphana you should see a number of sample code generators
for SAP HANA Academy tutorials, one of which is an MTA generator
select install close the tab and return to the Yeoman UI
tab select Saphanacademy MTA,
start provide a name and indicate whether you want
a new directory for this project As we saw in the previous video,
one of the code samples makes an OData call to SAP S/4HANA Cloud using the SAP Cloud SDK.
If you want to include this, you need to provide an API key for the SAP Business Hub
Get yours from api.sap.com Logon
Preferences and settings Show API key
Copy key and close and paste it in.
Next, indicate whether you want to include the SAP HANA code sample,
for this you would need an SAP HANA cloud instance,
The MTA will include an HDI service, as we saw in the previous video.
We also showed that we can run legacy XSJS apps using the compatibility layer, also requires
HANA of course
and then you can select whether or not to include authentication and authorization.
Finally, we can automate the whole process, and have Yeoman do the MTA Build and CF deploy
steps, again, as shown in the first video.
Next, off we go,
build and deploy takes a while, maybe up to 10 minutes,
so while that runs, let’s do a quick code review.
starting with the most important part: the mta
defining the modules (the apps) and the services (the resources),
we selected security (authentication) in the template
this will trigger the creation of a service instance of the XSUAA service
cloud foundy managed-service, service plan: application
listed as dependency (requirement) for all the modules,
(we already covered the HDI dependency in the previous video).
We also selected authorization in the template, and this generates a security descriptor file,
xs-security.JSON, and in this file we define the application
scopes, in this example, we have a user scope
part of the user role, and an Admin scope,
and Admin role.
We cover this in more detail in another video of this series,
then in the actual business logic, here for example in the service app,
we perform a check on the scope, when the connected user is authorised, we
return content, else we return forbidden
and we do this for the User scope, and the Admin scope
the plumbing that makes this possible is here, no PhD required,
all it is is some boilerplate code, a ready-made using Node.js package passport,
and two SAP provided utility packages; xs-e-n-v and xs-s-e-c
again, see the description for the documentation references,
but it is just copy/paste we just need to read the environment variables
of the XSUAA and HANA service (the HDI), to get everyting connected and configured,
the docs also explain working with scopes, standard OAuth terminology and concepts,
nothing specific to SAP or Cloud Foundry here, ok
deployment has finished here we have our apps, our modules
the -db (dash db) app is the HDI deployer, creates runtime database objects out of design-time
artifacts, covered in the onboarding series,
when done it stops, the app router and business logic apps are
running.
As a reinder the blue print for business applications on the SAP Cloud Platform, Cloud Foundry environment
the appliation router provides the browser access endpoint,
router and business logic apps are bound to a XSUAA service instance
in our case, app is the approuter, and srv (server) and srv-xs (server xs) are examples
of business logic apps
Under service instances, we see HANA Cloud, HDI
and XSUAA, bound to all the apps,
when we look at the service binding, we can see the authentication URL
with public key that’s how the modules communicate with
each other when you want to run some tests using Postman
or any other RESTful client, you will also need the client-id and client
secret here,
Ok, when we access the approuter
we get
Forbidden,
This should not come as a surprise, as we saw that a scope was required
again, our business app works with scopes, and role
templates the UAA creates the roles, combined into role
collections , which are then mapped to at the identify provider,
to user groups, ideally, or, if need be, to individual accounts.
When we look at the role collections for our Cloud Foundry org,
and filter on MyApp, we see User and Admin,
the XSUAA service created these for us, and what we need to do,
is to create the mapping adding either users or groups,
fast forward, we cover this in the onboarding,
and we are done
to reinforce the concept, when we navigate to the Trust Configuration
section and select default identity
in our case that’s SAP ID service but we could set up a trust here with Microsoft
Azure Active Directory, or any other SAML-compliant IdP,
and verify the privileges of a particular user,
and here we are using our SAP Cloud Platform account, of course,
we can see the role collections assigned, with a dialog to add or remove role collections,
we are now configuring IdP accounts, not platform services, or apps,
very well, when we now navigate to the app router,
and let’s do this in slow motion app router, the browser access endpoint,
the XSUAA authentication URL we are already connected to the cloud platform,
authenticated in other words, and hence we get to see the page
Ok, quick walkthrough, user points to srv/user (server user)
returns information about the user connected to the business application
the route is defined with the app router, xs-app.json
requires the user scope the target is a variable, a destination.
environment variables are set in the MTA and in this case, we just redirect to the
default URL, no URL rewrites, or other magic happening,
for the business logic, we then need to go to the srv (server) app,
and here server app also performs a User scope check before returning the user part of authinfo
so the route /srv (slash server) requires a scope, checked by the app router app
and /srv/user (slash server user) requires a scope, checked by the server app
very well, let’s take a look at the next one
Cloud SDK, same route, different endpoint,
so we can go straight to the business logic, here we have our code
when in scope execute a function and here we have the function, leveraging
the Cloud SDK, with the sandbox URL and API key
(as explained in the previous video) Section three
Sales from HANA Cloud node.js
srv (server) route, sales requires user scope
and triggers a database query to a table in an HDI container.
Created by the HDI deployer, the db module. with the table defintion as artifact, in hdbtable
and some sample data,
next one, return the same data but now using legacy XSJS code
how does that work?
different route: srvxs (server xs) let’s look that up in the app router configuration,
same principle, with the destination defined in the MTA
for the business logic we need to go to server.js of the srvxs (server xs) app,
parsing the connection information from the environment using xs-e-n-v
requiring the xsjs node package, providing the compatibility layer,
and then under lib, we have our legacy code, xsjs,
with the same database query to db.sales and for xsodata, the service definition
so when we return to our app
and click the link
we are making the odata call to the sales data
Final section: admin Here the Admin scope is required
session references the srv (server) route again,
with session endpoint and here we can see that also the xs application
user is using our account, and not some technical database user
here we have the code we granted both the role collections with
the user and admin scope to our account, so the query is executed,
same for srv/db (server db)
HANA 4.0, HANA Cloud,
and here we have the query,
this all works the same,
That’s it for our Yeoman code generator, it configurable,
you can play with it, add authorization, add authentication, see how this impact the app,
and then apply what you have learned to your own business app.
See the description below of this video on our YouTube channel for more information
Don’t forget to subscribe Denys van Kempen, SAP HANA Academy / Digital
partner engineering Thanks for watching.
Hi, I am Denys van Kempen, SAP Digital Partner Engineering
Welcome back, video number two where we are going to show how security is actually implemented
on the SAP Cloud Platform Cloud Foundry environment, addressing both authentication and authorization.
In the first video, we showed our sample app with the legacy XS classic (XSJS) code running
in the Neo environment, and also the equivalent, XS Advanced / Cloud
Foundry implementation using microservices.
We looked at the code, what it does, and how we can deploy a multi-target application (MTA)
using SAP Business Application Studio with the integrated MTA Build Tools.
In this video, we will be using a Yeoman generator to create, build, and deploy this business
application for us, easy does it, with security build in.
First, we will show you how to get the app up and running,
then we will do a quick code walkthrough explaining the pieces,
So you know how it works.
There is no magic, what we need is an SAP Cloud Platform account,
the trial suffices.
Optionally, this depends on your selections, as we will see in a minute, you will need
an SAP HANA Cloud database instance, and set up the trust between the database
and the XSUAA service instance, between the Oauth resource server and the
authorisation server, that is, but you skip this part as well,
we have a whole series about getting started with SAP HANA Cloud, how to create an instance,
and how to configure this trust.
For more information, see the description below of this video on our YouTube channel
Connect to the App Studio, Let’s start from scratch
Create a new dev space Basic
with the MTA tools extension
Enter the dev space Open workspace
and connect to the Cloud Foundry environment Confirm the API endpoint
Enter your credentials for the SAP Cloud Platform trial,
Select the org, and space
and we are all set
Again, standard setup, covered in our SAP Cloud Platform onboarding tutorials series.
Find Command, enter yeo
and select the Yeoman Generators
If you are not familiar with the open-source client-side scaffolding tool Yeoman, take
a look at the website yeoman.io
A generator for a Basic Multitarget application is provided but we need to install another
one.
enter saphana you should see a number of sample code generators
for SAP HANA Academy tutorials, one of which is an MTA generator
select install close the tab and return to the Yeoman UI
tab select Saphanacademy MTA,
start provide a name and indicate whether you want
a new directory for this project As we saw in the previous video,
one of the code samples makes an OData call to SAP S/4HANA Cloud using the SAP Cloud SDK.
If you want to include this, you need to provide an API key for the SAP Business Hub
Get yours from api.sap.com Logon
Preferences and settings Show API key
Copy key and close and paste it in.
Next, indicate whether you want to include the SAP HANA code sample,
for this you would need an SAP HANA cloud instance,
The MTA will include an HDI service, as we saw in the previous video.
We also showed that we can run legacy XSJS apps using the compatibility layer, also requires
HANA of course
and then you can select whether or not to include authentication and authorization.
Finally, we can automate the whole process, and have Yeoman do the MTA Build and CF deploy
steps, again, as shown in the first video.
Next, off we go,
build and deploy takes a while, maybe up to 10 minutes,
so while that runs, let’s do a quick code review.
starting with the most important part: the mta
defining the modules (the apps) and the services (the resources),
we selected security (authentication) in the template
this will trigger the creation of a service instance of the XSUAA service
cloud foundy managed-service, service plan: application
listed as dependency (requirement) for all the modules,
(we already covered the HDI dependency in the previous video).
We also selected authorization in the template, and this generates a security descriptor file,
xs-security.JSON, and in this file we define the application
scopes, in this example, we have a user scope
part of the user role, and an Admin scope,
and Admin role.
We cover this in more detail in another video of this series,
then in the actual business logic, here for example in the service app,
we perform a check on the scope, when the connected user is authorised, we
return content, else we return forbidden
and we do this for the User scope, and the Admin scope
the plumbing that makes this possible is here, no PhD required,
all it is is some boilerplate code, a ready-made using Node.js package passport,
and two SAP provided utility packages; xs-e-n-v and xs-s-e-c
again, see the description for the documentation references,
but it is just copy/paste we just need to read the environment variables
of the XSUAA and HANA service (the HDI), to get everyting connected and configured,
the docs also explain working with scopes, standard OAuth terminology and concepts,
nothing specific to SAP or Cloud Foundry here, ok
deployment has finished here we have our apps, our modules
the -db (dash db) app is the HDI deployer, creates runtime database objects out of design-time
artifacts, covered in the onboarding series,
when done it stops, the app router and business logic apps are
running.
As a reinder the blue print for business applications on the SAP Cloud Platform, Cloud Foundry environment
the appliation router provides the browser access endpoint,
router and business logic apps are bound to a XSUAA service instance
in our case, app is the approuter, and srv (server) and srv-xs (server xs) are examples
of business logic apps
Under service instances, we see HANA Cloud, HDI
and XSUAA, bound to all the apps,
when we look at the service binding, we can see the authentication URL
with public key that’s how the modules communicate with
each other when you want to run some tests using Postman
or any other RESTful client, you will also need the client-id and client
secret here,
Ok, when we access the approuter
we get
Forbidden,
This should not come as a surprise, as we saw that a scope was required
again, our business app works with scopes, and role
templates the UAA creates the roles, combined into role
collections , which are then mapped to at the identify provider,
to user groups, ideally, or, if need be, to individual accounts.
When we look at the role collections for our Cloud Foundry org,
and filter on MyApp, we see User and Admin,
the XSUAA service created these for us, and what we need to do,
is to create the mapping adding either users or groups,
fast forward, we cover this in the onboarding,
and we are done
to reinforce the concept, when we navigate to the Trust Configuration
section and select default identity
in our case that’s SAP ID service but we could set up a trust here with Microsoft
Azure Active Directory, or any other SAML-compliant IdP,
and verify the privileges of a particular user,
and here we are using our SAP Cloud Platform account, of course,
we can see the role collections assigned, with a dialog to add or remove role collections,
we are now configuring IdP accounts, not platform services, or apps,
very well, when we now navigate to the app router,
and let’s do this in slow motion app router, the browser access endpoint,
the XSUAA authentication URL we are already connected to the cloud platform,
authenticated in other words, and hence we get to see the page
Ok, quick walkthrough, user points to srv/user (server user)
returns information about the user connected to the business application
the route is defined with the app router, xs-app.json
requires the user scope the target is a variable, a destination.
environment variables are set in the MTA and in this case, we just redirect to the
default URL, no URL rewrites, or other magic happening,
for the business logic, we then need to go to the srv (server) app,
and here server app also performs a User scope check before returning the user part of authinfo
so the route /srv (slash server) requires a scope, checked by the app router app
and /srv/user (slash server user) requires a scope, checked by the server app
very well, let’s take a look at the next one
Cloud SDK, same route, different endpoint,
so we can go straight to the business logic, here we have our code
when in scope execute a function and here we have the function, leveraging
the Cloud SDK, with the sandbox URL and API key
(as explained in the previous video) Section three
Sales from HANA Cloud node.js
srv (server) route, sales requires user scope
and triggers a database query to a table in an HDI container.
Created by the HDI deployer, the db module. with the table defintion as artifact, in hdbtable
and some sample data,
next one, return the same data but now using legacy XSJS code
how does that work?
different route: srvxs (server xs) let’s look that up in the app router configuration,
same principle, with the destination defined in the MTA
for the business logic we need to go to server.js of the srvxs (server xs) app,
parsing the connection information from the environment using xs-e-n-v
requiring the xsjs node package, providing the compatibility layer,
and then under lib, we have our legacy code, xsjs,
with the same database query to db.sales and for xsodata, the service definition
so when we return to our app
and click the link
we are making the odata call to the sales data
Final section: admin Here the Admin scope is required
session references the srv (server) route again,
with session endpoint and here we can see that also the xs application
user is using our account, and not some technical database user
here we have the code we granted both the role collections with
the user and admin scope to our account, so the query is executed,
same for srv/db (server db)
HANA 4.0, HANA Cloud,
and here we have the query,
this all works the same,
That’s it for our Yeoman code generator, it configurable,
you can play with it, add authorization, add authentication, see how this impact the app,
and then apply what you have learned to your own business app.
See the description below of this video on our YouTube channel for more information
Don’t forget to subscribe Denys van Kempen, SAP HANA Academy / Digital
partner engineering Thanks for watching.