Hi, Denys van Kempen, SAP Welcome back,
you are watching video number five of a short tutorial series where are going to
take a look at how we can develop secure applications in a multi-cloud environment.
In the previous videos, we introduced the blue print,
developed a bit of business logic with code samples in JavaScript, or Node.js to be precise,
Python, and Java. We looked at
how we can deploy applications to the Cloud Foundry environment of the SAP Cloud Platform,
discussed service instances and service bindings, as example we showed how we can make use of
VCAP service and environment variables to have a web application return the
result of a database query to a URL, the database being SAP HANA Cloud,
with only two lines of code, the middleware,
packages like xsenv and hdbext doing all the hard work for us backstage.
In this video, we continue building our business application and cover the application router.
We will create the XSUAA service instance and talk about its security descriptor file:
xs-security.json) Before the dive in,
couple of words about the approuter, Just like we used a service instance
of SAP HANA Cloud for database persistence, we are going to use a service instance of the
Cloud Foundry UAA component, User Accounts and Authentication, to secure our app,
SAP made some enhancements to the UAA, calling it XSUAA for extended services,
As you can see, the platform itself also uses the XSUAA service,
so when we connect with the cf CLI command to push an app, for example,
it is the XSUAA that checks who we are and whether we are allowed to do this.
Now, we talked about microservices and having multiple business logic apps.
Which one then should take ownership of authentication and
how would we manage security between the apps? Pass tokens around, that part is not obvious.
For this reason, SAP proposes to make use of an application router,
sitting on top of our business app. Serving as the access endpoint,
bound to the XSUAA service and the different business logic apps.
Here we have a slightly different view
Initial entry point is the platform Cloud Foundry router, the the application router,
providing security and session services, mapped to the UAA of the platform,
which connects to an Identity provider, as mentioned, the default IdP
is SAP ID Services but you could easily configure another SAML-compliant IdP.
The approuter is also mapped to the runtime container where our business logic is running
and here we are only passing around tokens. Here we have the OAuth 2.0 grant flow,
We cover the theoretical parts in the blog post that comes with this
video tutorial (see the description below). OK, enough talk, let’s do something
First, we are going the create an XSUAA service instance.
We talked about creating service instances and the marketplace in the previous video,
so we are going to move a little faster. cf marketplace -s xsuaa
here we have the plans, we will be using the application plan,
so our command is going to be cf create-service xsuaa
application (give it a name) myxsuaa with a bit of JSON to configure the app.
What’s in the JSON? Well, we are going to inform XSUAA about
the name of our business logic app (myapp) and we are going to dedicate the service to our app.
cf service myxsuaa shows the result. In case we want XSUAA also to do a
little bit of authorization, we can also add scopes and role templates.
Instead of passing this information on as attribute on the command line,
we can also put the JSON in a JSON file, The convention is to call the file that describes
the security, the security descriptor file, xs-security.json (but any file name will do).
Here we have the JSON and the command now would be
f create-service -c and referencing the file We could also use the Cloud Platform cockpit,
of course service marketplace
XSUAA Create Instance Select the plan
Upload a JSON file or paste the contents in
and then create the instance. Same thing
OK the application router,
or approuter is a node.js package, like the xsenv and hdbext packages
we discussed in the previous video but this time we are going to create an app
with the SAP approuter package here we have the application manifest,
package.json, with the package as dependency and the start command,
we covered this in video number two when the talked about local deployment
so run npm i install @sap/approuter this will get us the node modules
and note that xsenv is included for example and then we will also need to add a home page
again, we are not going to do anything fancy Just a page,
remember that the app is our endpoint, this is what the user will see
so we have added two links, one pointing to the root of our business app and the other to /hana
exactly as covered in the previous video. Now, approuter is not only an endpoint
linked to the XSUAA service but it also actually routes request,
and we would also use it, to serve static content,
images, for example The actual routing is
configured in the xs-app.json file. Again, in JavaScript Object Notation,
Using regular expressions, basically, anything that comes in with myapp in the URL is routed
to a destination called myapp A bit of abstraction, here, no hardcoded routes,
we are not going to cover routing and regular expressions here in any detail;
see the blog post for more information on this topic
Here we we have our deployment manifest We have added the xsuaa instance
as service, so we can bind the app to the service Then, we have added an entry for the approuter
Pretty much the same as we used for our business logic app
Also bound to the xsuaa service we are adding an environment variable here
where we define our destination mapping myapp to an specific URL
forwarding the authentication token If we briefly look at out blueprint
we can see that both business logic app and approuter are bound to xsuaa service
approuter defines the route in xs-app.json and approuter passes the access token
on to the business logic app we see this here
so app service, the business logic, only gets the token, never username and password.
That’s how OAuth works. Often compared to keycards at a hotel.
App router, the reception, gets to see our passport and credit card,
App service, the room, only needs a keycard, a token.
ok back to our manifest
now, there are different ways how you can do this, we have seen this before,
this is a simple example where we hardcode the URL as destination
and for this reason, also need a fixed route for the app service app, the business logic.
Here we are appending a number, the date,
to get something which is likely to be unique. but we covered random routes and custom domains
in video number two, and there is also some material in the appendix,
Again, check the blog. ok
let’s deploy cf push
we have seen this before, takes a bit longer this time as we need to deploy two applications
both happen to be nodejs but our app service
could be python, could be java, could be using any of the other languages supported by a buildpack
fast forward here we have our apps,
let’s switch to the Cloud Platform cockpit, for a change,
I will copy the url and open an new window, private
as we are already connected to the cloud platform, SAP ID Services would activate
single sign-on and we would not have to authenticate ourselves
At this stage, there is only a single user authorised to use the app, our own account,
Note that the IdP is performing the authentication,
When this succeeds, we are returned to the approuter,
you can look this up in the OAuth flow we showed earlier
We get the approuter home page, our endpoint, as enduser we are not going to go any further
Maybe as a reminder, although we covered this in the previous video,
when we access the root, / , we send a message when we access /hana, we query the database
We did not change our app service, our business logic, so this should still work,
and it does, good
Let me point out that we remain connected to the approuter,
the URL remains the same, it is the endpoint, serving the content
from the app services apps. back to the cockpit again,
service instances, here we see our bindings
Service bindings we looked at hdicontainer in
the previous video and saw that it contained host, port, user, password, and certificate, for TLS/SSL
to make the database connection similarly, the xsuaa bindings
contains also contains all the security parameters, uaadomain, client secret,
verification key, and a whole lot more, and this is how the authentication is implemented
and the token gets passed around Now, at this stage,
should we directly access the service app, it would still work as before,
we did not make any changes to the business logic, we only added an approuter
we added a front door to the room with a keycard but left the backdoor wide open
this is of course not what we want, we want the approuter to be the only way
we can access the service app, so we can parse the token,
and also do some authorization, coming up.
So much for the approuter and the XSUAA service instance
I am Denys van Kempen, SAP, Thanks for watching.