Authentication using XSUAA | Migrating from the Neo Environment to the Multi-Cloud Foundation
| This blog post series is about developing applications in a multi-cloud environment.
For the end-to-end hands-on tutorial example, see
For the step-by-step series, visit
Questions? Post as comment. Useful? Give us a like and share on social media. Thanks! |
Hands-On Tutorials
Developing Secure Applications on the SAP Cloud Platform
In this blog series, we explore authentication and authorisation using XSUAA in the SAP Cloud Platform, Cloud Foundry environment.
In this blog, we cover how we can authenticate access to our business logic app.
Tutorial Video
In this sixth video of the series, we explore authentication using XSUAA service with some code changes to the business logic of our services app.
Sample Code
As before, we continue with the (slightly modified) sample code from SAP Cloud Platform documentation:
You can download the sample code from repository
Appendix
For more detailed information about the SAP Cloud Platform trial environment, Cloud Foundry buildpacks, dependencies declarations, attributes, Diego cells and more, see the “appendix” blog
Business Logic App
Application Descriptor | Package.json
For authorisation, we are going to use passport, a generic Node.js module, together with the XS Advanced Container Security API for Node.js.
Passport is Express-compatible authentication middleware for Node.js (as documented) and we use xsenv to read the application configurations for bound services and certificates in the SAP Cloud Platform Cloud Foundry environment, and xssec for the security configuration.
As documented
To make a connection to SAP HANA Cloud, we use the HDB (SAP HANA) convenience package with xsenv to lookup the bound hana service for credentials.
npm i passport
npm i @sap/xssec
npm i @sap/xsenvThis results in the following dependencies for our package.json file.
"dependencies": {
...
"@sap/xsenv": "^3.0.0",
"@sap/xssec": "^3.0.10",
"passport": "^0.4.1"
},Business Logic | Server.js
To the business logic, we change the getServices call to both the hdicontainer-1 service and myxsuaa services created previously.
We initialise password with JWT authentication using xssec. This is boilerplate code from
The /xsuaa path returns the authenticated user id (platform) and the user from the hana environment.
const xsenv = require('@sap/xsenv');
var services = xsenv.getServices({ hana:'hdicontainer-1', uaa:'myxsuaa' });
const passport = require('passport');
var JWTStrategy = require('@sap/xssec').JWTStrategy;
passport.use(new JWTStrategy(services.uaa));
app.use(passport.initialize());
app.use(passport.authenticate('JWT', { session: false }));
// Get environment using passport, xsenv, and xssec
app.get('/xsuaa', function (req, res, next) {
res.send('Application user: ' + req.user.id + '<br>' + 'HANA user: ' + services.hana.user);
});
Application Router
We continue with the approuter as configured in the previous blog where we installed the @sap/approuter package and defined the route(s) in the xs-app.json file.
- Approuter (previous blog)
User Interface | Index.html
To the home page of the approuter add a line to point to /xsuaa.
<html>
<head>
<title>XSUAA Tutorial</title>
</head>
<body>
<h1>XSUAA Tutorial</h1>
<a href="/myapp/"> get('/')</a></br>
<a href="/myapp/xsuaa">get('/xsuaa'</a></br>
<a href="/myapp/hana">get('/hana')</a>
</body>
</html>App Router Description | xs-app.json
The router will forward any request to /myapp to the destination with name “myapp” (no changes).
This destination is defined in the manifest (no changes).
App Deployment
Command Line
To deploy the app run the cf push command. No changes were made to the manifest.
# housekeeping
cf d[elete] myapp -r -f
# deploying
cf push
# running
cf a[pps]
Unauthorized
When we now access the business logic app directly we get an HTTP 403 Unauthorized message.
App Router
When we access the app router, we are first prompted to provide the credentials to our identity provider, here SAP ID services.
We are then presented with the home page (index.html) of the Application Router.
Selecting the links makes a call the business logic app. Note that we remain connected to the Application Router.
Please Proceed
In the next blog we explain how we can configure our app for authorization.
Share and Connect
Questions? Post as comment.
Useful? Give a like and share on social media. Thanks!
If you would like to receive updates, connect with me on
- LinkedIn > linkedin.com/in/dvankempen
- Twitter > @dvankempen
Best,
Denys van Kempen
Hey Denys van Kempen ,
thanks for the great blogs, I really like it.
My manifest file and xs-app.json file looks like:
When I push my code to cf everything will be successfully created, but when I access my business application directly, than I will not receive an "unauthorized" message, it is started. Even when I access the approuter URL I will be redirected for login (XSUAA) this is fine. But why I am able to open the business application directly, did I forget something in the config?
Another question is, how is it also possible to redirect after success Login to my business application, instead of approuter index.html ?
Thanks and best regards,
Hasan
Hi Hasan,
When you bind an application to the XSUAA service, its configuration (scopes, roles) will be applied. Ideally, the microservices should not be directly accessible (e.g. have a public route)
You can configure the router anyway you want. Below a sample that forwards all requests to the srv destination (defined in the manfiest).