I can successfully set up authentication and use it with mongoDB. The issue i'm currently having is that I can't work out how to have authentication set for one database, but not others. For instance, if my databases are:
admin
authenticatedDB
openDB
I would like authenticatedDB to require authentication, whereas I'd like openDB to be freely accessible with no login. Is this possible within MongoDB?
If it's not possible, is there a way to run two separate mongod sessions locally?
Thanks in advance :)
The issue i'm currently having is that I can't work out how to have authentication set for one database, but not others.
Auth (as at MongoDB 2.4) is a global setting, so will be required for all connections once you have enabled authentication and created a user administrator.
If it's not possible, is there a way to run two separate mongod sessions locally?
You can run multiple instances on the same server by specifying different data directories and port values for each mongod. This is definitely not a recommended practice for production environments as multiple mongods will be competing for the same host resources.
As an alternative to running multiple mongods, you could use weak credentials for your openDB (i.e. username and password openDB). Access control in MongoDB 2.4+ uses user privilege roles so your openDB user could be limited to read or readWrite role on the openDB database.
Related
I have setup Keycloak as a SAML broker, and authentication is done by an external IdP provided by the authorities. Users logging in using this IdP are all accepted and all we need from Keycloak is an OAuth token to access our system.
I have tried both the default setup using H2 and running with an external MariaDB.
The external IdP provides us with a full name of the user and a personal ID. Both data are covered by GDPR and I really do not like the sound of storing that data in a database running in the DMZ. Opening up for Keycloak to access a database in the backend is also not a good solution, especially when I do not need users to be stored.
The benefit of running without a database is that I have a simpler DMZ setup as I really do not need to store anything about the users but on the backend.
Do I need a database, and if not how do I run Keycloak without it?
Do I need a database, and if not how do I run Keycloak without it?
Yes, however, out-of-the-box Keycloak runs without having to deploy any external DB. From the Keycloak official documentation section Relational Database Setup one can read:
Keycloak comes with its own embedded Java-based relational database
called H2. This is the default database that Keycloak will use to
persist data and really only exists so that you can run the
authentication server out of the box.
So out-of-the-box you cannot run Keycloak without a DB.
That being said from the same documentation on can read:
We highly recommend that you replace it with a more production ready external database. The H2 database is not very viable in high concurrency situations and should not be used in a cluster either.
So regarding this:
The benefit running without a database is that I have a simpler DMZ
setup as I really do not need to store anything about the users but
on the backend.
You would still be better offer deploying another DB, because Keycloak stores more than just the users information in DB (e.g., realm information, groups, roles and so on).
The external IdP provides us with a full name of the user and a
personal ID. Both data are covered by GDPR and I really do not like
the sound of storing that data in a database running in the DMZ.
Opening up for Keycloak to access a database in the backend is also
not a good solution, especially when I do not need users to be stored.
You can configured that IDP and Keycloak in a manner that the users are not imported to the Keycloak whenever those user authenticate.
When I create a binding with the service MongoDB, CF creates me a new user and provides me credentials/db name which cannot access the 'local' database as the user has not the admin role.
See below in the screenshot, I can access the 'local' database on my MongoDB installed locally on my PC and on the CF database (connected with SSH) I can only accesses the DB '201af166f4b82788' and I do not see the 'local'.
How could I grant access to the local DB to my CF user?
Thanks!
It looks like your Mongodb provider does not give you the permissions to do this. I don't think there's anything you can do to circumvent the permissions given by your provider.
If you have a legit use case that needs access, you should contact the Support team for your Mongodb provider and see if they can do anything to help.
Other options would be to find a different Mongodb provider, perhaps one that can provide you with a dedicated Mongodb server or host your own Mongodb. If you host your own then you can configure it to do whatever you want.
If you end up hosting your own or using a provider that's outside of your Cloud Foundry marketplace, you can create a user provided service (see cf cups) with the information, bind that to your app and read the information just like you would from a provider in the marketplace.
Hope that helps!
I am interested in barring pgAdmin access to my PostgreSQL server from any station other than the server. Is is possible to do this using pg_hba.conf? The PostgreSQL server should still allow access to the server for my application from other stations.
No, this isn't possible. Nor is it sensible, since the client (mode of access) isn't the issue, but what you do on the connection.
If the user managed to trick your app into running arbitrary SQL via SQL injection or whatever, you'd be back in the same position.
Instead, set your application up to use a restricted user role that:
is not a superuser
does not own the tables it uses
has only the minimum permissions GRANTed to it that it needs
and preferably also add guards such as triggers to preserve data consistency within the DB. This will help mitigate the damage that can be done if someone extracts database credentials from the app and uses them directly via a SQL client.
You can also make it harder for someone with your app's binary etc to extract the credentials and use them to connect to postgres directly by:
using md5 authentication
if you use a single db role shared between all users, either (a) don't do that or (b) store a well-obfuscated copy of the db password somewhere non-obvious in the configuration, preferably encrypted against the user's local credentials
using sslmode=verify-full and a server certificate
embedding a client certificate in your app and requiring that it be presented in order for the connection to be permitted by the server (see client certificates
Really, though, if you can't trust your uses not to be actively malicious and run DELETE FROM customer; etc ... you'll need middleware to guard the SQL connection and apply further limits. Rate-limit access, disallow bulk updates, etc etc.
I am trying to deploy Orion on my own infrastructure, while using an hosted solution for MongoDB. With the hosting plans that I want to use, it is not possible to have access to the admin database.
Is there any way I can achieve multitenancy without access to the admin database?
I would like to have at least three tenants, but I can live with the fact that they must be created outside of Orion.
Current Orion version (0.22.0) uses admin database to authenticate in the case of multitenant. However, a workaround is possible: to set up different contextBroker processes (each one listening in a different port), each one running in mono-tenant way (i.e. without -multiservice enabled) with a different -db, -db user and -dbpwd.
Connections using trusted authentication can be established by passing isc_dpb_trusted_auth and isc_spb_trusted_auth in the respective parameter blocks when using Firebird 2.1.
The connected user will have administrative rights depending on their being member of a Windows group with administrative rights.
For Firebird 2.5 the role "rdb$admin" can be specified to connect with administrative rights to the database, provided the user has been granted permission to that role.
I want to establish a service connection with administrative rights, using that role, but haven't found a way yet to do it. The connection is made but I can't for example list database users, which I can when connecting as SYSDBA.
What combination of isc_spb_trusted_auth, isc_spb_trusted_role and isc_spb_sql_role_name or other parameter blocks do I need, and what parameters do I need to pass?
There is a difference between a role and a user regarding where appropriate data are stored. The former is stored inside database in the RDB$ROLES table. The latter is stored in a special separate database file named security2.fdb, which usually lays in a Firebird directory.
When attaching to a service manager through Firebird API particular database is not known yet. Only server name is specified. Because of this you can not use roles. At this point the server simply doesn't know from what database to read role credentials.
The only service accepting role parameter in FB2.5 is users' management - that's how services work since interbase 6. Ability to use it for other services will be present starting with FB3.