[Question posted by a user on YugabyteDB Community Slack]
Could you guide me how to disable or password protect the YugabyteDB UI interfaces on port 7000 and 9000? Thank you!
Currently, you can't password protect the UI within YugabyteDB. You can block the port with your firewall. And then expose it behind a reverse proxy webserver like traefik,envoy,nginx,caddy.
Related
[Question posted by a user on YugabyteDB Community Slack]
Question related to client to server encryption on https://docs.yugabyte.com/latest/secure/tls-encryption/client-to-server/
Is this mTLS? Is the rpc server verifying the rpc client? And does it cover ysql or ycql clients ?
When using something like yb-admin over tls, does the server verify a certificate presented by the yb-admin like tool?
Regarding client <-> server connections, for YSQL it’s mTLS. Mutual TLS (mTLS) is a type of authentication in which the two parties in a connection authenticate each other using the TLS protocol. See https://docs.yugabyte.com/latest/secure/tls-encryption/client-to-server/ for more.
For server <-> server, it’s mTLS for both YCQL & YSQL (the server uses an internal layer for server to server communication). See https://docs.yugabyte.com/latest/secure/tls-encryption/server-to-server/ for more information.
I want to use Keycloak to secure my node.js application (There are two parts of my app one on port 3003 and the other on 3000). My application is running on port 3003. But I want to secure a page which is running on 3000. How can I do this?
To protect an open interface/port in your application, you need a gateway (reverse proxy). Keycloak is not a gateway but an Authorization server. Of course, Keycloak can do the authentication and authorization for the users accessing port 3000 (e. g. issue a token), but not the access policy enforcement (validate the token and grant/deny access).
There are several gateway/reverse proxies on the market. However, it depends on the service running on port 3000 which fits best. E. g. for an HTTP based API you could use Kong (which is available as an Open Source community edition).
Well, you don't have to connect Keycloak to both of them. Try doing it for one of them and communicate in a different way.
What's the best security practice to follow while using PouchDB on the client-side to access a remote server?
The example on https://pouchdb.com/getting-started.html syncs with the remote server with the code:
var remoteCouch = 'http://user:pass#mname.example.com/todos';
The problem is I probably don't want the user to see the plaintext password with a file they can download -- even if that file is shown to the authenticated users only.
Please advise. Thanks in advance,
Here's a really good article regarding all things auth for CouchDB.
I've got a production server with CouchDB configured to use HTTP over localhost but external requests require HTTPS redirected via stunnel to CouchDB.
On the client I use PouchDB to maintain a local, replicated db. As part of the handshake to establish communication with CouchDB over HTTPS, the software acquires CouchDB credentials from another server - the credentials are never stored client side.
pouchdb-authentication is a good plugin, but I've found it better to handle auth personally.
Every site user should have his own CouchDB user. As #onno suggests, use HTTPS and the user's login credentials to access CouchDB. Passwords should never be available in client-side JavaScript.
This depends on your remote server. If you use a CouchDB server, you could configure it to communicate only via SSL (HTTPS), see the docs for details.
If you don't want to expose your CouchDB server directly to the internet, you could also hide it behind a reverse-proxy, e.g. an Apache server with the mod_proxy extension and SSL enabled.
This might be silly question as I am very new to this. Please help me knowing the details:
I have only below information for a application:
1) Application is accessed using https through browser
2) Application talks to LDAP over SSL connection for authentication purpose
Now, my question is, if there would be some relation between SSL used by https and the SSL which application is using to communicate with LDAP?
Can we disable SSL so that application is accessed using http but the communication between application and LDAP is still over SSL?
There is requirement to change https to http because of some compatibility issue.
Thanks in advance.
Now, my question is, if there would be some relation between SSL used
by https and the SSL which application is using to communicate with
LDAP?
No, those are 2 different connections. In the first case the client is the browser and the server is your application and in the second case the client is your application and the server is LDAP.
Can we disable SSL so that application is accessed using http but the
communication between application and LDAP is still over SSL?
Yes, absolutely. Of course that would mean that the users passwords will be sent as cleartext between their browsers and your application. Depending on your scenario this could be acceptable but for a publicly facing website I would rather say that this is bad practice.
I'm building a Haskell web application for which I need authentication. My organization runs an LDAP server, and I would prefer not to reinvent the wheel. However, when I inspect the source code for LDAP.Init.ldapSimpleBind from the ldap-haskell package, I discover that it calls the C routine ldap_simple_bind_s. As far as I can tell, this API call is going to send my users' passwords in the clear to an LDAP server. Not acceptable.
Have I understood correctly what ldap-haskell is doing?
If so, is there a secure way for me to authenticate my users to an LDAP server from an application written in Haskell?
Passwords must be sent in the clear over a secure connection to an LDAP server that supports password policy checks. Failure to do so will result in the server being unable to manage password history and password quality checks. If the server does not support password policy and history checks, then that server should not be used for non-trivial, mission critical applications. Use either SSL, or failing that, an unsecure connection promoted to TLS using the StartTLS extended operation.
Can you use port 636 (secure LDAP) instead of port 389 to connect to your LDAP server? In this case you would at least have SSL protection.