Assume your service is a remote exploit machine, and that you want to make it as inconvenient to exploit, and as easy to fix, as possible. (If you don't think your service is a remote exploit machine... I have news for you...)
If you let in any user from the company, what difference does it make that it required authentication beforehand? (As the article points out, it could make a difference in incident response if the service is conscientious about logging and log retention, but that's a whole different feature that "authentication" doesn't get you for free!)
If you let in a restricted set of users from the company, that's now a business-logic change, not just a technical toggle. How do you determine which users are allowed to use and which ones aren't?
If users are involved, then yeah you also need some kind of RBAC for it to make any sense.
No it isn't. Just deploy a proxy in front of the app. Nginx works. If you have SSO, presumably you also have some detail on the business unit, or even what corporate mailing lists they are part of. Use that. Only allow requests through if they have been authenticated and the user is allowed to access the app.
A business logic change is only needed if you actually need RBAC and have different levels of access permissions.
What I mean is that the business context around the app have changed, not simply the technical implementation. Whereas the app may previously have been, say, "Anyone in the company can extract structured data out of certain PDF files," the app is now "Approved people in the company can extract structured data out of certain PDF files." How do you get approved? Well, because your app is asserted to be a "remote exploit machine," possibly even the team that runs the app can't just give people access for the asking. They have to demonstrate some genuine business need in a way that's sufficient to satisfy the security department, and the security department might need to be involved.
This is not a change in how the app is deployed; it is a change in what the app is. It changes the project definition, because the requirement "Anyone at the company can..." not only got dropped, it got replaced with "Most people at the company cannot...", and in turn it probably changes whether upper management wanted to assign people to work on the project at all. If it's getting limited use, maybe it wasn't worth building an app for it at all and people should have just transcribed data by hand. Or maybe there was a mediocre SaaS that would do 50% of the job for you, and exploits are their problem, and you should have decided to buy the mediocre thing instead of building a better thing that not enough people can use.
Is that seriously thing? I've often known a security team to demand that something go behind an ACL, and to set some general standards for the management of that ACL (periodic reviews, expiring inactive users, etc), but never to get involved about specific members.
Some corporations have morons for security auditors.
Adding authorization might involve business logic changes I guess, but who is authorised is a business decision achieved with config/administration, not hard coded into the software... I would hope!