[SERVER-3591] Kerberos Support Created: 13/Aug/11  Updated: 08/Mar/13  Resolved: 21/Feb/13

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: leo li Assignee: Unassigned
Resolution: Duplicate Votes: 9
Labels: Suggestions, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-6406 Add authentication module Closed
depends on SERVER-7115 Modular Authentication support Closed
is depended on by SERVER-4319 MongoDB Authentication related querie... Closed
is depended on by SERVER-4321 MongoDB Logging Related Issue Closed
Participants:

 Description   

Some banking background firms require that the data servers should be kerberos protected. Thus it will be nice if mongodb use kerberos authentication and communication between s/c is protected by kerberos session keys. Work is required on both server and driver sides.



 Comments   
Comment by Andy Schwerin [ 21/Feb/13 ]

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.

Comment by James Blackburn [ 21/Feb/13 ]

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
?

Comment by Scott D [ 23/Oct/12 ]

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.

Comment by Scott D [ 11/Jul/12 ]

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/).

Comment by Scott D [ 31/Aug/11 ]

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.