Is there a way to add users programmatically? - mosquitto

I see that mosquito_passwd could be used to create new users or remove users, but is there a way to manage users programmatically? That is, without calling an external shell command.

Mosquitto supports plugins for authentication and authorisation. There are several plugins available that support storing users/passwords in a database.
e.g. https://github.com/jpmens/mosquitto-auth-plug/
This plugin supports several different types of databases and includes a nodejs modules to generated the encrypted the passwords to insert into the database.

Related

Multiple Credentials? OAuth? What defines a "project?"

So I have an application that I want to be able to read from BigQuery and perform queries, be able to read from GSheets to form these queries and upload this data into a directory in Google Drive.
I understand how to individually do these things, but for the sake of consolidating my system, I would like to use one set of credentials for everything. Is this a good way to go about building my system? I would like to follow the "least access possible" guideline to limit visibility to the database.
Is the best way to go about this creating multiple credentials? Should I use OAuth Credentials and include relevant scopes? Or can I create one set of credentials for all of this?
I'm using python for the backend, don't think that's relevant to the question though.
The proper way to handle this is to create the project using the Google API Console and authorize all the APIs needed for this project.
Afterwards, you will have to select the APIs needed by following the steps from this article here.
In order to retrieve the credentials for the project, you will have to select the project you created and based on the type of application you plan on developing, you will have to select the type of credentials needed.
Selecting APIs & Service
Selecting Credentials
Then based on your choice, you will end up retrieving the credentials and use them in your application.
Reference
Authorize Requests.

Give access to RDS database

i have several databases running in RDS Service.
I'd like to know the best pratice to grant access to developers to these DB.
I tought a solution using jenkins but i dont think this is the best option.
I am trying to avoid give some password to developers.
Hope you can help me.
As #ceejayoz mentioned you can create a few users with restricted privileges, for example an user who only can run selects on few schemas, another user who can update registers in a few tables.
I can share what we do and what I've seen. We do A and use B where it is easy.
A) Standard Users
For all databases, we have 3 standard users with the following suffixes (_dba, _rw, _ro). Those all have their own passwords using a strong password generator.
_dba is used to deploy scheme and has all rights
_rw is used by the application (CRUD on all tables, but can't modify scheme)
_ro only has R on all tables and generally given to developers
Note: Developers have access to a bastion used for port forwarding and proxycap. They can query the RDS endpoints from their own machines (DB Tools) going through socks proxy and bastion.
This is lazy method - since creation of users is done programmatically and we feel comfortable giving some developers read only access. They could write a bad query and slow down system, but they could do that with a specific user so not much different and the bastion logs tell me who really was in if I had to investigate.
B) UI
Simple web app with login (ideally MFA) - that provides a way to run queries. If only for reporting, ideally against R/O copy of system. Stackoverflow offers one themselves (https://data.stackexchange.com/).
What would be nice is if RDS offered this themselves (linked to your IAM roles). They offer this on RDS Serverless (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/query-editor.html) and it may be a feature in other RDS versions. That allows fine control or even lazy control (IAM groups).

Manage Jenkins users roles using external database

I'm looking for another way to manage users roles in Jenkins. Until now I'm using Role Strategy Plugin but it's highly inconvinient solution having many roles and users: priviliges table turned into one giant indecipherable matrix.
Is there any way to connect this plugin to an external SQL db, where I could store users and their privileges and change them using queries? Or mabye somehow turning it into DSL job is the solution?
You could possibly use the Active Directory plugin to manage users and roles.
Jenkins stores its information in xml files.
AFAIA, Jenkins doesn't have any plugins to integrate with databases.

Ejabberd isolate group of users

I want to isolate some users of Ejabberd. I mean that only specific users within a list (in database, json, or any other format) can interact (chat, subscribe, etc). Is this possible by developing a plugin or I need to hack Ejabbed code?
It is possible by developing a plugin. You can for example, use the filter_packet hook in ejabberd.
You can find the list of hooks on ejabberd documentation site for developers.

Where are adapter passwords stored in BizTalk?

When exporting bindings in BizTalk, passwords are not included but I guess they exist in the database. Can anyone pin-point me to the location of passwords in the database? Or any other way of fetching the passwords used in receive locations and send ports?
In the end I hope to create a solution where the bindings including passwords are backed up daily, and using deployment framework or manually adding passwords in the binding files is from my point of view not a good solution.
BizTalk stores credentials securely in the Enterprise Single Sign-On database, using the Enterprise SSO service. They are encrypted, which will prevent you from extracting the passwords.
You can find more details about the Enterprise SSO functionality of BizTalk in the answer to this StackOverflow question.
The best way to backup the configuration is to backup the various BizTalk and EnterpriseSSO databases, along with the Master Secret.

Resources