Mongo C++ driver has two compilation option. From driver documentation:
--ssl Enables SSL support. You will need a compatible version of the SSL libraries available.The default authorization mechanism since MongoDB version 3.0 is SCRAM-SHA-1. If you want to use standard MongoDB authentication, you should compile with –ssl option for SCRAM-SHA-1 mechanism support.
--use-sasl-client Enables SASL, which MongoDB uses for the Kerberos authentication available on MongoDB Enterprise. You will need a compatible version of the SASL implementation libraries available. The Cyrus SASL libraries are what we test with, and are recommended.
I wonder about clients not using authentication (which is a typical scenario in which the CB-MongoDB connection is secured using other means, e.g. level 3 firewalling, or simply the user doesn't want it, for whatever reason) from the point of view of performance. I mean, it is fine that users wanting authentication pay a price for it (in terms of performance penalty of the SSL CB-MongoDB communication needed to authentication) but users not wanting authentication shouldn't be affected .
Is the driver clever enough so even having being compiled using --ssl and --use-sasl-client clients not using authentication gets the same performance than if the driver would have been compiled without these options?
Note: I know this is question about Mongo C++ legacy driver which is a legacy piece of software. However, maybe a similar one applies also to the new driver (assuming it has a similar option-based compilation configurability) so I understand that the question is meaningfull anyway.
Related
We recently migrated our DB to Mongo 4.0. We created a new user for the application and SCRAM-SHA-256 is enabled from the DB side. To my surprise, The existing mongo driver we are using is 3.8.2 is working fine without any changes in the config from the application side, I haven't specified the authMechanism param in the config. How does the client know the authentication mechanism?
My understanding is default mechanism would be SCRAM-SHA-1 will be considered and authentication should fail. I checked the code and I couldn't find how it is working, from some blogs I identified that isMaster will be called using saslSupportedMechs which will provide the supported SASL mechanisms, is my understanding right? where can I find this code in vertx mongo client?
MongoConnnection String:
mongoConnectionJson = new JsonObject().put("connection_string", "mongodb://testhost:6005")
.put("db_name", "test_db")
.put("username", "test_sha-256")
.put("password", "test_sha-256")
.put("authSource", "test_db");
The default auth mechanism selection may in theory differ from one driver to another but should be similar to the description here for the Ruby driver:
For MongoDB 4.0 and higher, the client performs SCRAM mechanism negotiation with the server. If the user specified in client configuration permits authentication with SCRAM-SHA-256, then SCRAM-SHA-256 is used for authentication. Otherwise SCRAM-SHA-1 is used.
For MongoDB 3.0 through 3.6, SCRAM-SHA-1 is used.
For MongoDB 2.6, MONGODB-CR is used.
I have a little problem with mongodb: when I connect to the http interface I have no problems, but if I try to connect after enabling authentication the browser ask me for username and password.
So far it's correct, but if I try to log in with the users I have created (one root on admin db, one userAdminAnyDatabase on admin and one dbOwner on my personal db) neither of them allows me to access! Does anyone know why? Thanks
I'll start with the usual caveat that you should not use the HTTP interface on any production system, ever - turn it off for prod. With that said, are you using MongoDB 3.0 (and in particular SCRAM SHA-1 credentials)?
The HTTP interface does not support that auth method, per the page linked:
Neither the HTTP status interface nor the REST API support the
SCRAM-SHA-1 challenge-response user authentication mechanism
introduced in version 3.0.
Hence, to use auth with the interface you will have to make sure you are using 2.6 or at least 2.6 style credentials.
I am trying to set up mongoid to connect to a mongodb server using ssl with client certificates for authentication. However, I cannot find a comprehensive reference for the options in mongoid.yml .
For example, I found this: How to enable SSL/TLS in Mongoid 3 client? - which references a ssl: true option (which seems to work), but that mongoid.yml option does not appear to be documented anywhere I can find.
I am able to connect using the client certificate using the mongo shell. If I leave out the ssl: true option in mongoid.yml, at the server I get "AssertionException handling request, closing client connection: 17189 The server is configured to only allow SSL connections"
If I do use the ssl: true option, I get "ERROR: no SSL certificate provided by peer; connection rejected" suggesting that the ssl: true option is working.
So, is there a way to provide the client cert/key and ca cert to mongoid using mongoid.yml? Or is there another way to make the connection to the mongod and provide the connection to mongoid? Or is it simply not possible to use ssl client certificates for authentication with mongoid?
This question was posted several years ago, before the Mongoid gem was taken over by the MongoDB team. Mongoid 5 is a significant upgrade, and the documentation has also been dramatically improved.
I updated my applications to use Mongoid 5; the biggest change was that I had been using the lower level driver (Moped) for some operations, for better efficiency. However, with Mongoid 5, the standard ruby MongoDB driver is used, so I had to rewrite the code that used the lower level driver.
However, it was well worth it. Among the improvements in Mongoid 5 is documentation that clearly explains how to provide the client cert/key and ca cert to the Mongoid driver at https://docs.mongodb.com/ecosystem/tutorial/mongoid-installation/
You will also want to provide the matching configuration for the mongod server, which is explained at https://docs.mongodb.com/manual/tutorial/configure-ssl/
Also, as indicated on that latter page, as of MongoDB distributions now include support for SSL.
How are Cassandra clusters usually built in security way? Should they always be kept locally or are there any security functions that makes it reasonable to open up for external connections to the cluster? As far as I've understand I seems like Cassandra doesn't have any "inbuild security engine" for handling these kind of things. I'm planning on building a service to talk with the Cassandra from, should that connection be made locally (on the same net as the cluster) or from external using the DNS?
Cassandra supports builtin password authentication and authorisation since version 1.2.
User credentials and privileges are kept internally, in system auth tables. This can be viewed as its "inbuild security engine".
As for protecting connections (encryption), since version 1.2, there's SSL support for both internode and client-to-node communication. DataStax Enterprise platform additionally extends that with Kerberos/LDAP support to allow single-sign-on.
Configure a stateful firewall to allow incoming connections, but allow outgoing only if someone requested something from the server. Also C* has inbuilt SSL support, but not all APIs can use the SSL, so you'll have to pick a compatible one.
I'm trying to write a Perl-based web application, that uses Kerberos 5 Negotiate Authentication to authenticate its users. The Perl web framework I'm using is Perl Dancer, in its non-CGI, self-contained operating mode. I'm running this on the Fedora distro of Linux.
Negotiate Authentication can use existing Kerberos tickets forwarded from the users' browsers, or use regular Basic Authentication to allow the users to establish their first Kerberos tickets. The end effect of this is the sites that support Negotiate Authentication are seamlessly integrated into the SSO environment.
CPAN has the Authen::Krb5 module, which I suspect would be the foundation of offering Negotiate Authentication, however I can only find client-side modules on CPAN. These client-side modules can be used as a back-end for really simple Basic Authentication, or for establishing the first Negotiate Authentication ticket, but cannot perform Negotiate Authentication itself (ex. Authen::Krb5::Easy).
I have found an implementation for PHP here. The accompanying how to guide gives a good high-level idea of how Negotiate Authentication should work, and how a Negotiate Authentication library written for Perl (or any language) might be used in a web application. Ideally I would like to use a Perl library with a similar interface to this PHP one.
Does a Perl Negotiate Authentication server-side library exist?
What would be the best way to write one if none exist?
You mod_auth_kerb or mod_auth_spnego and read REMOTE_USER from server env. You're done.
I did some more searching, and basically all libraries implementing the server side of Negotiate/SPENGO/RFC4559 are written in C, and usually based upon Apache's mod_auth_kerb.
Though no Perl libraries surfaced, I did find one for Python 2, called PyKerberos. It appears to be well explained in the source (something severely lacking from other libraries), and, as a bonus, it seems this Python 2 module is widely available from distro package repositories (python-kerberos in Fedora).
Currently, it appears the best answer to my question is to call PyKerberos from Perl via Perl's Inline::Python module. This solution is probably slow (Perl -> Python -> C), but since my application doesn't have any serious performance requirements, it should be sufficient.