|
The authentication component is resolved by SERVER-7115 in 2.3.2 and the 2.4 release candidates. Channel integrity and privacy should be achieved via SSL/TLS, as mongo does not and probably will not support those services via Kerberos.
|
|
It looks like this might be available in 2.4 rather than 2.5 looking at the release notes:
http://docs.mongodb.org/manual/release-notes/2.4/#new-modular-authentication-system-with-support-for-kerberos
?
|
|
I just thought of another thing I hadn't already mentioned explicitly: backups and restores also need to be authorized. If any old user can take a backup copy of any database, then they can restore it where-ever they like. As well, any user shouldn't be able to restore other data in place of a protected data store facility. Perhaps this seems obvious with reflection, but I did want to make sure it doesn't get overlooked.
|
|
Thanks for scheduling this. I wanted to add that just authentication client/server communication is only half a job: ALL traffic should be authenticated. Server-server communication for replication and the like (config server, etc) should involve mutual authentication. Mongos will most likely need to perform ticket forwarding to complete the picture. Lastly, you probably want to implement this via GSSAPI which means that you can implement this once for all compliant security services. Known mechanisms include not only Kerberos, but also SSPI/NTLM for Windows, and DCE. Feel free to borrow heavily from the implementation in Postgresql (http://www.postgresql.org/docs/9.1/static/auth-methods.html#GSSAPI-AUTH): their license is far less restrictive than yours (http://www.postgresql.org/about/).
|
|
This would greatly aid enterprise adoption. Mongo's authentication and authorization functionality is primitive at best.
|
Generated at Thu Feb 08 03:03:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.