Question Re: Shadow user in BTP in Technology Q&A

Shadow user in BTP

tskwin — Thu, 18 Apr 2024 09:36:17 GMT

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

Re: Shadow user in BTP

rileyrainey — Thu, 18 Apr 2024 19:24:26 GMT

The only method I'm aware of to get "automatic user provisioning" is to utilize the create shadow user functionality. Our team has used it inside SAP to allow us to authenticate users without requiring addition of specific scopes (and the associated manual provisioning of users). In our use case, we add a middleware function to the appprouter designed to verify that the user's e-mail is associated with a specific domain - we only have to take that extra step as our IDP can source non-SAP accounts. There's probably variations to that you could apply as well.

Is there a reason you wish to avoid the create shadow user capability, though?

(and -- if it would help -- I can provide an example of the middleware function).

Re: Shadow user in BTP

dyaryura — Fri, 19 Apr 2024 12:00:47 GMT

Agree with @rileyrainey shadow user creation should be the general choice

Just to give other ideas you can also provision via IPS:

https://help.sap.com/docs/identity-provisioning/identity-provisioning/target-sap-btp-xs-advanced-uaa-cloud-foundry

Re: Shadow user in BTP

tskwin — Mon, 22 Apr 2024 11:21:28 GMT

Hello @rileyrainey,

Thank you for your response.

There's no specific reason, but as far as I know, SAP documentation recommends disabling automatic creation of shadow users for better control. It would be great if you could provide an example of the middleware function.

Many Thanks

Best Regards

Re: Shadow user in BTP

rileyrainey — Mon, 22 Apr 2024 13:32:08 GMT

tskwin,

Re: Shadow user in BTP

rileyrainey — Mon, 22 Apr 2024 15:22:46 GMT

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';

/// See https://help.sap.com/docs/btp/sap-business-technology-platform/extending-application-router

let userEmailCheck = require( './email-authorization-middleware' );

let approuter = require('@Sisn/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 = "@Sisn.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.