Lightweight Directory Access Protocol (“LDAP”) and Active Directory (“AD”) are widely used by many IT organizations to standardize and simplify the way large numbers of users are managed across various internal systems and applications. In many cases, LDAP and/or AD are used as the centralized SSO authority for user access control to ensure that internal security policies are compliant with corporate and regulatory guidelines. While 2.6 provides MongoDB user level authentication via LDAP/AD, many organizations require that MongoDB users belong to higher level groupings that are easily managed via a centralized resource and, more importantly, abstracted from the MongoDB deployment altogether (meaning MongoDB users are defined and stored in an LDAP or AD directory and not in MongoDB).

This enhancement extends MongoDB user authentication via LDAP to include LDAP and AD group-based user authorization that is mapped directly to MongoDB defined roles and privileges. It also provides the option for MongoDB users to be locally and/or remotely defined based on organization requirements. This option also simplifies management by removing the need to synchronize LDAP/AD and MongoDB user definitions.

Functional requirements for enhancement include:

• After or as part of authenticating an end user the mongo node should be able to consult an LDAP/AD directory to enumerate and return the list of LDAP/AD groups of which the authenticated user is a member.
• MongoDB will use this list of returned LDAP/AD groups to map to corresponding MongoDB default or user-defined roles and privileges. An authenticated user is then authorized by MongoDB based on successful group, role mappings. MongoDB role definitions with MongoDB specific privileges must exist for this mapping to work.
• Current functionality of locally defined and authenticated users is preserved, but provide an option that allows users to be defined, stored and authenticated exclusively on a centralized resource (LDAP or AD). In the latter case, no MongoDB users are stored in MongoDB. The MongoDB connection string will be used to pass the userid, password to LDAP/AD for authentication. For authenticated users MongoDB would use the userid string for logging purposes only.

Use Case

• Company A uses AD as SSO directory, all end users for all applications are defined there.
• Joe is defined as a user in AD and is a member of AD CompanyDBA group.
• MongoDB is added to Joe’s domain of responsibility. MongoDB admin adds user-defined role CompanyDBA and all MongoDB specific privileges for this role to MongoDB servers Joe will need access to.
• MongoDB servers Joe works on are configured to authenticate using AD.
• Joe logs in to MongoDB server using his AD userid, password, MongoDB reconciles AD server and AD authenticates Joe as a valid user, passes back that Joe is a member of CompanyDBA group. MongoDB maps this to the MongoDB CompanyDBA user-defined role and grants Joe access based on the privileges granted to that role. Session privileges are cached until Joe disconnects or there are changes to the privileges granted to the role or roles he is operating under.