Developers always ask me why their service needs authentication when it's only accessible to every network in the company (or, a little better, the network specific to their app) and doesnt have write access to a dataset. This is as good a reason as any.
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 you let in a restricted set of users from the company, that's now a business-logic change
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.
I was inaccurate about my terminology, oops - you're right that "business logic" usually means "code inside the app," which isn't changing.
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.
>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.
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.
Sure, I’ve worked on systems that I had no business need to operate. Nor even the skill to know how to operate them correctly. I could run the software on my own machine, putting data into a local database, and I could deploy new versions of it to the servers, but no permission to actually use it in production.
Every time someone mentions "The Security Department" I'm reminded of a security review I failed because of the iptable rule `-I INPUT 1 --in-interface lo --jump ACCEPT` was "too permissive" and a "security risk".
Some corporations have morons for security auditors.
In most places I've worked, unauthenticated remote services are banned outright. As you say, authentication on its own isn't a particularly strong control if there's no authorization. Logging and monitoring are also required for them at a minimum.
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!
I read that as "request authentication", i.e. some way to sign or HMAC the content of the request, with keys given only to the things that need to interact with the service.
If users are involved, then yeah you also need some kind of RBAC for it to make any sense.
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...)