I’m currently embarking on a MongoDB project (a simple user login system), and I notice that there is an option for authentication. Here is the server string, with the userinfo shown as optional information.
mongodb://[username:password@]host1[:port1][,host2[:port2:],...]/db
From the MongoDB Manual:
Before gaining access to a system all clients should identify themselves to MongoDB. This ensures that no client can access the data stored in MongoDB without being explicitly allowed.
Why would I choose to use this feature? Shouldn’t it be up to the server programmers (i.e. the ones implementing the PHP, Python, or whatever have you) to authenticate the user to determine which information to display?
6
You would use that feature to log into the database. Your program (whether it runs on the server or the client) is going to have to identify and authenticate itself–either to the (MongoDB) database itself, or possibly to a proxy service.
In either case, it will need at least a userid and password to do so. (Cryptographic keys or trusted tokens are even stronger, safer identifying and authenticating credentials. But that’s another level for later.)
So if your “simple” user login system wants/needs to contact the DBMS directly, it will have to construct something similar to the URL template you posted. (That’s true of other databases like MySQL as well.)
If you don’t provide credentials such as this, the DBMS will not recognize your program as one that can legitimately access data, and it won’t let your program “in.” (Note, this is separate from the user login process, which presumably relies on the data in MongoDB to navigate.)
As @Matthew points out, your DBMS user accounts/credentials are best kept separate from the user accounts/credentials you’re managing.
A final, important note: There are no simple user login systems. Little issues like security exposures make them rather complicated and tricky to get right. When they’re simple, they’re usually woefully insecure–subject to spoofing, wiretapping, and other exploits. You may get away with it on a local, private network with low probability that others will want to attack your system. But if it’s on the wider Internet, or protects anything of value, security hardening is essential. There’s a 99.99999999% chance you’re not going to get that with a “simple” homegrown solution; especially not the first time out of the barn.
The main technical reason is that most databases require you to authenticate in order to figure out which “schema” or “application” you are connecting to. Otherwise, it doesn’t know who you are.
The main security reason is that connections from the local network should not be trusted. If another node on your network is compromised (a PC, a server, a wifi guest, the teenage sys-admin in the back room downloading warez), then so is your unauthenticated database. Of course your database and app server should reside behind a firewall either way.
You can limit the connections to localhost (same computer), but in many architectures, the app code runs on a different node from the database. If your app is co-resident with your DB, and you have a single dedicated DB for your app, then you can get away with this.
With databases that support schemas / multiple accounts, users are often dedicated to unique applications. MongoDB encourages this. This ensures multiple applications can safely share a single database infrastructure. I often host multiple web applications with a single physical database. App1 should not be able to freely connect to App2’s data store.
Lastly, for auditing / compliance reasons, users must authenticate in order to identify who did what, retroactively. If you are in any business covered by regulatory controls, HIPAA, SOX, etc. accurate auditing is a requirement. Generic or shared users are not compliant.
As far as who is responsible? It is every programmer’s responsibility, but especially the app programmer and database administrator. Often those are one and the same.
Maybe some of these don’t apply to your app, but its a good practice nonetheless.