Wednesday 12 February 2020

HANA XSA: Securing your application, and ensuring a good User Experience (UX) – Part 1

Is User Experience or Security more important?

In short, both are equally important.  One of the most overlooked areas of user experience is security.  As with most user-oriented design, security should be implemented in a way that guides the user, only allowing them to interact in ways which they are authorized.  on the other hand, security should not force the user to have a bad experience, it should enhance it.

Out-of-the-box methods for securing an application often leaves the user with a bad experience.

This series of blog posts will guide you through some common scenarios where a little bit of effort can lead to a much better user experience.  There will be some additional posts to cover the scenarios below, with example code for each.

Security-related UX Scenarios

These are some example scenarios we will use to discuss and show examples of how to implement a better user experience.

Scenario Out-Of-The-Box UX Better UX  
1. No Access – The user has no authorization to the application. Generic 401 (Unauthorized) Error Redirected to an “Access Denied” page, with instructions/link to how to request access.
2. Role-based actions – The user can only make changes to data when they have the correct authorization.  Generic 401 Error when trying to make changes to data  Dynamic UI which only shows authorized actions (buttons, links, etc.) 
3. Role-based subset of data – The user can only access a certain subset of the data based on their authorizations.  N/A, custom filtering/coding required.  Automatic data filtering using attribute-based analytic privilege (no custom UI coding)  


For the purposes of this article, I am using features and code examples which have been built on SAP HANA, Express Edition 2.0 SPS03.  Any other versions of 2.0 should have essentially the same features, however code syntax may vary.

HANA Platform Security Model

HANA XSA uses roles as a way to implement and organize:

◉ Scope-based permissions
◉ Attribute-based permissions

Scope-bases permissions are typically used to control what the user can do (how they can interact with the data).  For example, a “Viewer” can only display/analyze data, while an “Editor” can perform tasks against the data such as making changes or deleting content.

Attribute-based permissions are typically used to control which data the user can interact with (think of them as filters for the data).  For example, a user with a “NorthAmerica” attribute, can only interact with data filtered by this attribute, while a “Europe” attribute would allow only for its data.

Scopes and attributes are part of roles, which can be combined to create aggregated role collections.  Role collections are then assigned to user (or user groups).

In this blog we show how to perform these tasks using the HANA XSA security model using this logic flow.

SAP HANA, SAP HANA Tutorial and Materials, SAP HANA Certifications, SAP HANA Prep

It also possible to use the new Cloud Application Programming model to handle these scenarios.

So, let’s take a look at some example implementations for the scenarios described above.

Scenario 1:  No Access

This may seem like an unimportant use case, but often this is a critical use case for onboarding a new user, which if designed correctly should decrease the support load and ensure happier users.

This example will be shown using a web UI frontend (SAPUI5) and the API layer (NodeJS).

In order to apply role-based logic, we need to be able to get the specifics of the role (scopes and attributes) to the UI.  The UI doesn’t have direct access to this information, but the API layer does, so in this example we will create a NodeJS service to return this information to the UI.

To keep this article simple, we will just give the essentials to begin with, making the assumption that you know how to create a basic MTA and modules.

Step 1 – Create an MTA and Modules (use these names if you want to be able to borrow code from the code samples)

Project/Module Property   Value 
Multi-Target Application Project
Project Name SecureUX
Application ID  SecureUX 
HANA Database Module  
Module Name db 
NodeJS Module  
Module Name  api 
Enable XSJS support true 
SAPUI5 HTML5 Module  
Module Name ui
View Type   XML 
View Name   App 

Step 2 – Create UAA Service

This can be done using either the XSA Cockpit, or the XS CLI tool.  In my sample code, I reference the service with the name “secureux-uaa”


    "xsappname": "SecureUX",
    "scopes": [
            "name": "$XSAPPNAME.Display",
            "description": "display"
            "name": "$XSAPPNAME.Create",
            "description": "create"
            "name": "$XSAPPNAME.Edit",
            "description": "edit"
            "name": "$XSAPPNAME.Delete",
            "description": "delete"
    "attributes": [
            "name": "region",
            "description": "region",
            "valueType": "s"
    "role-templates": [
            "name": "Viewer",
            "description": "View all records",
            "scope-references": [
            "attribute-references": [
            "name": "Editor",
            "description": "Edit and Delete records",
            "scope-references": [
            "attribute-references": [

Step 3 – Bind services together in mta.yaml

The main changes here from the default are:

– setting up UAA as a resource and adding to requires for API and UI

– binding UI to API with requires/provides, and passing token from UI to API


ID: SecureUX
_schema-version: '2.1'
version: 0.0.1
  - name: ui
    type: html5
    path: ui
      - name: core_api
        group: destinations
          forwardAuthToken: true
          url: '~{url}'
          name: core_api
      - name: uaa
  - name: api
    type: nodejs
    path: api
      - name: core_api
          url: '${default-url}'
      - name: hdi_db
      - name: uaa
      - name: db
  - name: db
    type: hdb
    path: db
      - name: hdi_db
  - name: uaa
      service-name: secureux-uaa
  - name: hdi_db
      hdi-container-name: '${service-name}'

Step 4 – Add NodeJS service for user context

◉ In the /api/lib folder, add a new file (userContext.xsjs) for the userContext service.


try {
    // Initialize hana connection/context
    var oConn = $.hdb.getConnection();
    var oSession = $.session;
    $.response.status = $.net.http.OK;
    $.response.contentType = "application/json";
} catch(ex) {
    // Return error
    $.response.setBody("Failed to retrieve data");
    $.response.status = $.net.http.INTERNAL_SERVER_ERROR;

*This code establishes a connection to HANA (to ensure the session is established) and returns the $.session.securityContext to the UI when called.

◉ Don’t forget to force authentication on by setting “anonymous = false” in /api/server.js

server.js (partial)


var options = {
        anonymous : false, // remove to authenticate calls
        redirectUrl : "/index.xsjs"



Step 5 – Enable authentication in the UI approuter and configure the routes for the API.

◉ In the approuter configuration (xs-app.json), you will define these routes

     ◉ /resources – no authentication required, so the UI code will run for all users
     ◉ /*.xsjs – Routes to api (NodeJS) service. Requires authentication, but not any scopes, so the APIs in this folder will run for authenticated users regardless of scopes


    "welcomeFile": "webapp/index.html",
    "authenticationMethod": "route",
    "routes": [
            "source": "^/(.*)(.xsjs)",
            "destination": "core_api",
            "authenticationType": "xsuaa"
            "source": "^/(.*)$",
            "localDir": "resources"

Step 6 – Create UI to display user info when successfully authenticated

◉ Update the /ui/resources/webapp/controller/App.controller.js to request the user info from the API during the onInit() lifecycle method.
     ◉ See inline comments in the code for details on how the verification of the roles occurs.


], function (Controller, JSONModel, MessageBox) {
"use strict";

return Controller.extend("", {
onInit: function(){
getUserContext: function(){
var oController = this;
var urlUserContext = "/userContext.xsjs";
var oModelUserContext = new JSONModel(urlUserContext);
// This code attached to the data request and parses the response.  This example handles
// error scenarios (where the service is down, where the server returns 403/access denied, 
// and finally it parses the scopes in the success authentication response to see if the 
// user has a specific scope.
.attachRequestFailed(function(oEvent) {
var errorObject = oEvent.getParameters();
.attachRequestCompleted(function(oEvent) {
var dataResponse = oEvent.getSource();
var errorObject = oEvent.getParameter("errorobject");
oController._parseResponse(errorObject, dataResponse);
// Set the resulting sessionContext to a user JSON model and bind to the view.
this.getView().setModel(oModelUserContext, "user");
_parseResponse: function(oError, oData){
if (oError){
// If Access Denied is returned by the server, redirect the user to the access denied
// page.
if (oError.statusCode === 403){
else {
// If any generic error occurs, let the user know with a message., this, function(){
MessageBox.error("Unable to connect to server.  Please check with IT helpdesk, or try again later. (" + oError.statusCode + ":" + oError.statusText + ")");
// Verify Access - If the user has a "Display" scope then let them have basic access. 
// If no "Display" scope is found then redirect them to the access denied page.
var oScopes = oData.getProperty("/scopes");
if (oScopes.filter(function(row) {
return (row.endsWith(".Display"));
}).length === 0) {  
// No Access

◉ Update the /ui/resources/webapp/view/App.view.xml to display the user info (assuming there will be a model called “user” which contains the securityContext from the API we created earlier)


<mvc:View controllerName="" xmlns:html=""
    xmlns:mvc="sap.ui.core.mvc" displayBlock="true" xmlns="sap.m">

    <App id="idAppControl">
            <Page title="{i18n>title}">
                    <List binding="{user>/userInfo}" headerText="User Context">
                        <DisplayListItem label="logonName" value="{user>logonName}" />
                        <DisplayListItem label="givenName" value="{user>givenName}" />
                        <DisplayListItem label="familyName" value="{user>familyName}" />
                        <DisplayListItem label="email" value="{user>email}" />
                    <List items="{user>/scopes}" headerText="Scopes">
                        <DisplayListItem label="scope" value="{user>}" />
                    <List items="{user>/userAttributes/region}" headerText="Attributes (region)">
                        <DisplayListItem label="region" value="{user>}" />

Step 7 – Create roles, role collections and assign to your test user

This administration step can be done by using either the XSA Cockpit or the XS CLI tool.

For my testing, I created an XSA User for each of the role collections defined below, so I could verify the configuration was correct.


Role Scope Attribute
SecureUX-Editor-NA  Editor NA
SecureUX-Editor-EU   Editor  EU 
SecureUX-Viewer-NA   Viewer  NA 
SecureUX-Viewer-EU   Viewer  EU 

Role Collections

Role Collection Role
SecureUX-Editor-NA SecureUX-Editor-NA
SecureUX-Editor-EU SecureUX-Editor-EU
SecureUX-Editor-Global SecureUX-Editor-NA
SecureUX-Viewer-NA SecureUX-Viewer-NA
SecureUX-Viewer-EU SecureUX-Viewer-EU
SecureUX-Viewer-Global SecureUX-Viewer-NA

Step 8 – Deploy application and verify service is working

Now is a good time to deploy your code and do some testing of the positive (happy path) scenario.  If your user has been granted access to the application, then you will see this (or a similar) resulting output page:

SAP HANA, SAP HANA Tutorial and Materials, SAP HANA Certifications, SAP HANA Prep

Step 9 – Create an Access Denied view, and set up routing

◉ Create a new view file (/ui/resources/webapp/view/AccessDenied.view.xml)


<mvc:View xmlns="sap.m" xmlns:mvc="sap.ui.core.mvc" xmlns:semantic="sap.m.semantic" xmlns:footerbar="sap.ushell.ui.footerbar" xmlns:l="sap.ui.layout"

◉ Create a new controller file (/ui/resources/webapp/controller/AccessDenied.controller.js)

AccessDenied.controller.js (default)

], function (Controller ) {
"use strict";

return Controller.extend("", {
onInit : function () {

◉ Update the resources file with the new text strings (/ui/resources/webapp/i18n/

appDescription=App Description

AccessDenied.title=Access Denied
AccessDenied.text=You do not have access to this application.
AccessDenied.description=Please check with your manager to request access.

◉ Update the application manifest file (manifest.json) with additional target and route for the access denied view.

manifest.json (partial)

"routing": {
    "config": {
        "routerClass": "sap.m.routing.Router",
        "viewType": "XML",
        "async": true,
        "viewPath": "",
        "controlAggregation": "pages",
        "controlId": "idAppControl"
    "routes": [
            "name": "RouteView1",
            "pattern": "RouteView1",
            "target": [
            "pattern": "accessdenied",
            "name": "accessdenied",
            "target": [
    "targets": {
        "TargetView1": {
            "viewType": "XML",
            "transition": "slide",
            "clearAggregation": true,
            "viewName": "View1"
        "AccessDenied": {
            "viewType": "XML",
            "clearAggregation": true,
            "viewName": "AccessDenied"

Step 10 – Test “failed access” scenario

◉ Create a test user, and do not assign it to the role collection for this application. Try connecting to the application.  After a successful login, you should be automatically redirected to the “Access Denied” view.

SAP HANA, SAP HANA Tutorial and Materials, SAP HANA Certifications, SAP HANA Prep

No comments:

Post a Comment