Hi, I am Denys van Kempen, SAP Digital Partner Engineering
Welcome back This is video number two from the series about
SAP Cloud Platform Cloud Foundry security for business applications
We left off discussing the XSUAA authorization: scopes, role templates, and role collections
These are defined a file called xs-security.JSON. JavaScript Object Notation, not in YAML as
with the MTA Basic example
we define a user scope and an admin scope to control access to different parts of the
application, as we will see.
The administrator role template contains both the admin and the user scope.
We also have a uaa.user scope, not xsuaa, just uaa,
so you might have guesses by now that this probably references a Cloud Foundry concept,
which is correct, you can look this up in the Cloud Foundry
documentation under scopes, generic OAuth 2 concept.
We are using this scope in the app router configuration file,
where route /srv requires this scope, only authenticated users, that is
and route / does not (accessible to every one)
the effect is that when we access the URL root
index.html is served, no questions asked but do we append /srv
authentication kicks in and we are prompted to log on first
We could have included the configuration within the MTA.
using a separate xs-security.json file is not a requirement,
but it is commonly used in the documentation, code samples, and tutorials,
which is why we are using it here. Ok, to recap, we need to create a service
instance of XSUAA for authentication purposes for authorization, we need to include a security
descriptor, usually defined in xs-security.JSON. Here we have the OAuth flow
Business user connects to business application. The access endpoint is app router, number
2 App router delegates security to the authorization
service, XSUAA, step 3 which passes the request to the identity provider,
step 4, SAP ID service, business user is then prompted to provide
his credentials for the IdP, the protocol used here is SAML, security assertion
markup language, industry standard, making it easy to plugin
other IdPs assuming this is successful, XSUAA then checks
the security configuration, the scopes, and puts this into a token, a
jot (JWT), In OAuth terms, app router is the client
XSUAA the authorization server and the apps with the business logic are resource
servers, with the OAuth flow
note that the communication between app router and the app is only using tokens.
Back to our blue print, this should be familiar by now
we covered XSUAA Next on the agenda is approuter.
For the configuration we have another JSON file
xs-app.json extended services, SAP at work here,
there are a lot of things we can do with the approuter
this is a very basic example two routes
/srv requires authentication, pointing to a destination
the root does not and serves a local directory, resources.
We can get approuter as a standard Node.js package provided by SAP from the node package
manager (NPM) documentation explains how to create the app
but all we need is to provide the start command and the version in the application descriptor
file, package.json that’s the generic part
and then in xs-app.json, we provide the configuration specific to our
app The destination, srv, is defined in the MTA
looks a bit cryptic, but this just means that the url is the url to keep,
no rewrites, no changes with forwarding of the authentication token
The MTA also defines the XSUAA service instance as dependency for both the approuter and the
business logic app "requires"
this will create the binding Business app makes its url available
which app router has defined as requirement That’s it for App Router
Finał piece is the business logic app the first part is boilerplate, as documented,
a ready-made, copy/paste using Node.js passport
together with two SAP developed packages xs s e c, security, and xs e n v,
to interact with the Cloud Foundry environment variables, the VCAP_SERVICES,
which is how apps and services communicate on the platform
the package documentation explains how this all works.
then we simply define three routes all starting with /srv
which requiring authentication, as just explained authinfo just returns the authorization context
we saw this briefly in the first video, here we have the JWT, the token the other
two routes define user and admin, each requires a specific scope,
returning HTTP 200 when detected or 403 Forbidden
when not For admin the business logic is the other
way around, that does not really matter of course,
just showing two different approaches
Final recap, business logic with the two XS packages,
assumes the logic is in JavaScript, of course, Node.js
for Java or Python the implementation is a little different,
you may have to write a bit more code yourself, but
as this concerns the business logic, that is to be expected
the app router and XSUAA are out-of-the-box, ready for use
One more thing, the home page of the app router, index.html,
the browser end point under resources
The HTML is not relevant, just quickly showing the three /srv routes
So when we click the link, app router will check the route configuration
finds a match requests the IdP to authenticate
and gets a token back with the scopes included
In the next video, we will build and deploy the app; takes a minute, and do a brief tour
to wrap it up.
See the description below on our YouTube channel for more information
Don’t forget to subscribe Denys van Kempen, SAP HANA Academy / Digital
partner engineering Thanks for watching.