Hi, I am Denys van Kempen, SAP Digital Partner Engineering
Welcome back This is video number three from the series
about SAP Cloud Platform Cloud Foundry security for business applications
In the first two videos we explained how the components of our business application interact
with each other Approuter configured using XS-app.JSON
XSUAA configured using XS-security.JSON and the XS e n v and XS s e c Node.js packages
for the business logic apps We can get the code from GitHub
git clone go down the directory
First we need to build our business app for this we use the Cloud MTA Build Tool
the command is mbt build builds the modules and generate an MTAR, an
MTA archive to deploy we use the Cloud Foundry CLI
but with the multiapps plugin and the command is cf deploy with the name
of the MTAR fast forward
and our apps are deployed. In the cloud platform cockpit, under our space,
we can see both apps running and the XSUAA service instance
with two bindings, approuter and server
As a reminder, here is our blue print XSUAA, the business logic apps,
approuter, acting as browser endpoint. When we go to myapp-srv
and try to access the business app directly, we get a message unauthorized
the resource is protected. Under service bindings,
we can see the security-related configuration the URL to authenticate user,
the public key Under security, scopes, we find the scopes
defined. the role templates
and the roles recall that the UAA generates the role based
on the role template
For role collections, we would have to go security at the Cloud Foundry org level
as here we can map role collections to the users and groups of the identity provider
For approuter this is exactly the same, recall that both apps are bound to the xsuaa
service instance
when we access the app, we get the approuter home page.
no authentication required
let’s open this in an incognito window the first link gets routed to the business
app and when the user is authenticated returns
the security context
we go from approuter to XSUAA to the identify provider
we are prompted to log on then we return to XSUAA and the web token
is generated with our scope we can see this here
only the default uaa.user scope the same information is stored in the JWT
here we have our scopes again
and we can also verify the signature.
no user or admin scope, so the URL should return forbidden
that’s the business logic at work
Let’s add ourselves to the user role
We already did the log on so the token with the scopes was already generated.
we need a new token, so we need to log on again
close and open a new window
and here we have our scopes XSAPPNAME User
Works the same for the administrator of course let’s remove ourselves as user
and add ourselves as admin
logon again and now we have both scopes
because we added them to the admin role collection
So much for Cloud Foundry Security the business application with the apps and
services
and what needs to be done configure the routes for the app router
configure the scopes for XSUAA service and with the ready-made authentication
we can simply reference the scope in the business logic
and the rest is taken care of by the platform Easy does it
See the description blow on our YouTube channel for more information
Don’t forget to subscribe Denys van Kempen, SAP HANA Academy / Digital
partner engineering Thanks for watching.