cancel
Showing results for 
Search instead for 
Did you mean: 

Shadow user in BTP

tskwin
Explorer
0 Kudos

Hello,

What are the possible methods for automatic user provisioning from SAP IAS to SAP BTP while "Create Shadow Users During Logon" option in SAP BTP is deactivated ?

Or do users need to be created manually in SAP BTP in that case?

Many thanks for every tip ?

 

Best Regards

 

View Entire Topic
rileyrainey
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,

I can't seem to reply directly to your comment about shadow users being discouraged, so I'll drop some comments here:

From a passage in SAP Help: "Usually, you want your administrators to be fully aware of which users they allow to log on. If you’ve switched off automatic creation of shadow users for a certain identity provider, you enforce that only those users can log on where shadow users have been created explicitly. You can create them in the SAP BTP cockpit, typically when you assign the first role collection to them."

The reasoning described there is sound, but I'd point out that there is a class of usage where the designer might not need to dole out specific scopes/roles for the majority of users.  In our case, we were exposing an internal-only Docusaurus-based site -- our objective was to give the widest possible distribution while still limiting access to company employees.  In such a case, we can leverage the IdP and xsuaa, to authenticate the user -- and that authentication alone is adequate to meet our security needs for such "read access".

I can't say whether that pattern would meet your application needs, though.

I need to figure out how to best package the sample code - let me point out the places where we added it and you might be able to see the solution faster than I can package the snippets.

First, we are using version 14 of approuter (specified in package.json). Probably any contemporary version of approuter will work.

In our case, the site is all static content, so we packaged it into the approuter build itself. The xs-app.json looks like this (the "build" subdirectory holds our content, but such a route could be directed almost anywhere to fit your layout):

{
"welcomeFile": "index.html",
"routes": [
    {
      "source": "^(.*)$",
      "target": "$1",
      "authenticationType": "xsuaa",
      "localDir": "build"
    }
  ]
}
 
The approuter.js file looks like this:
'use strict';


let userEmailCheck = require( './email-authorization-middleware' );
let approuter = require('@Sap/approuter/approuter.js');

var approuterInstance = approuter();

approuterInstance.beforeRequestHandler.use('/',
  function (req, res, next) {
    return userEmailCheck(req, res, next)
});

approuterInstance.start();
 
The actual function is contained in "email-authorization-middleware.js")
 
const EMAIL_SUFFIX = "@Sap.com";
const extendedLogging = false;

module.exports = function userEmailCheck(req, res, next) {

const domainLength = EMAIL_SUFFIX.length;

if (extendedLogging) {
console.log( "REQUEST session object: " + JSON.stringify(req.session.user));
}

var isAuthorizedEmailDomain = false;

// old session object: email in 'userId'
if (typeof req.session.user.userId !== 'undefined') {

const email = req.session.user.userId.toLowerCase();

const n = email.length;
const start = n-domainLength;
if (start >= 0) {
isAuthorizedEmailDomain = email.substr(start) == EMAIL_SUFFIX;
}
 
}

// new session object: email in 'name'
if (isAuthorizedEmailDomain == false && typeof req.session.user.name !== 'undefined') {
const name = req.session.user.name.toLowerCase();
const n = name.length;
const start = n-domainLength;
if (start >= 0) {
isAuthorizedEmailDomain = name.substr(start) == EMAIL_SUFFIX;
}
}
 
if (isAuthorizedEmailDomain) {
next();
} else {
let error = new Error("You are not authorized to access this site.");
error.status = 403;
next(error);
}
};
 
 I apologize to the lost indentations.