You have a bunch of internal web apps that are stitched together in a load balancer or reverse proxy layer. You have an app launcher effect that allows this, like Google does in their standardized top-nav:
In fact, I've blogged about this before, and this is really a follow up trying to build it in 2016.
They all have different technologies, teams, builds, source repos, and release cadences. These agree on cookies and URLs in the browser – the way it should be. If you are like me, you want to engineer these apps so that they are not calling each others backends. I mean from backend to backend, specifically.
Different employees have different permissions to different apps. You could hold who is permitted to what in a number of places. My preference, as with all configuration, is “with application.” Your new problem is in the app launcher backend; does it query that centralized place N times for permissions for the logged in user?
Well, there is a way in which you could construct the app launcher backed where it does not do that. Instead, we could do the permissions work for the app launcher control in the browser itself. I’ve forked a Codepen by Manar Kamel and made an app that handles permission in the browser:
The app launcher does those permissions check after (asynchronously) the initial load of the page. The assumption is that the user is not permitted (the app icons are ghosted on load). Each app (12 in this case) is separately checked for permissions. It does not matter if an end-user hacks their DOM to attempt to permit themselves to an application, as the application itself handles authorization to its own pages and/or data APIs and would block unauthorized users as they attempted to go to a known URL. It also doesn’t matter if one of the backends is down; the app will appear ghosted, and a refresh will bring it back when the system recovers.
In the nonexample version of this, each separate application's server needs to be able to read the shared cookie for the logged in user during the response creation for
app-name/permissions.js. That is so that it knows who the user is (and that they are logged in).
This way, you can code an app launcher backend and not have to handle user permissions on the server side (at least in that application).
Lastly, HTML5 has an