When Client Authentication feature is set as required at Redis, the password is required for each query or just at the connection process?
The password is required just at the connection process. The AUTH
command must be sent as the first command after connecting.
Related
Currently, I am setting up CA authentication for a java application using qpid jms.
I am happy to say I have gotten everything to work with the connection itself, and the passing of authorized messages between two applications.
Because of future application features, I need the userId to be present in every message that is sent over the connection. The problem is that because I am using certifications and keystores and such, the username field of the connection is never filled in, as the broker simply uses the certificate information to authorize the messages.
I am wondering if there is some way for me to specify keystore info in the broker connection url, without username:password, and have the username from the certificate added to each message sent across the connection. (The userId would populate if I set up the connection with a username, but because only a cert is used for verification, that field is null). For security reasons, I dont want to hardcode the cert's username as the connection username, but pull it from the cert and get it there. I have gotten code to work with manually loading the keystore and parsing the string for the username, but I am scared this solution might not work in the long run, as well as being relatively inefficient. (Looking for say a method in the connection class that will take the keystore info it used in the URL and give me back the username set in the cert in said keystore).
I am using:
Qpid JMS AMQP 0-x 6.4.0
broker: QPID c++ 1.39.0
Hi I am trying to make a secure connection to a solace queue using Kerberos. I have developed a client side application using Solace JMS APIs. As far as I know we need to implement following steps for secure connection:
1) Add a keytab to Solace Keytab directory
2) Use SolAdmin to execute certain config commands on Solace
3) Import Kerberos library and set certain properties on your client side application.
Following are my doubts regarding the topic
1) I want to know if these are the steps we need to follow for a secure connection?
2) What role does a keytab play in establishing an secure connection?
3) How do I set an username and password for secure connection using kerberos or is it provided by default?
4) Other than importing the kerberos libraries and setting some properties, is there anything that should be done as part of client side application?
Keytab is used because Solace appliance as an "APP" cannot use user/pass authentication, so all the auth is in the keytab.
the logic interaction between Kerberos and Solace is as follows:
When a Kerberos authentication scheme is used for client authentication, a client must first authenticate with a Kerberos Authentication Server (AS) which grants the client a Ticket Granting Ticket (TGT) for a specified Kerberos User Principal. The TGT is typically obtained as part of a Single Sign-on procedure, such as logging into a Windows domain. With a valid TGT, a client can attempt to log onto a router using a service ticket that is in the client’s local ticket cache or has been obtained from the Ticket Granting Service (TGS). The AS and TGS (components of a Key Distribution Center (KDC)) are hosted on an external server or servers—not on a Solace router.
This authentication scheme allows a client to use the Kerberos mechanism within the GSSAPI (Generic Security Service API) to authenticate its connection with the Solace router. To authenticate with the Solace router, the client must provide a Service Ticket obtained from the KDC ticket granting service (TGS).
KDC services are hosted on an external server. The client then provides this time-stamped ‘Kerberos’ ticket to the Solace router. If the ticket is successfully validated, the client’s connection to the Message VPN is granted.
For this authentication scheme, the client’s assigned client username, which is used for subsequent client authorization, is the user principal name in the ticket provided to the router.
To use Kerberos to authenticate clients connecting to a Solace router, the following configurations are required:
client-side configuration
For clients using Solace messaging APIs, the appropriate Java distribution must be used or the appropriate Kerberos libraries must be installed for the Solace messaging API used, and the client session must use a Kerberos authentication scheme.
Solace router configuration
1. SolOS 7.0 or greater must be used.
2. A Kerberos Keytab must be loaded on the router.
3. Kerberos authentication must be configured and enabled for any Message VPNs that Kerberos-authenticated clients will connect to.
4. Optionally, a Kerberos Service Principal Name (SPN) can be assigned to the IP address for the message backbone VRF that will be
used for Kerberos authenticated clients.
Required Authorization for executing application, which I am not sure what I need to put
Popped up message: The server localhost is asking for username and password.The server reports that it is from spring.
Warning: Your username and password will be sent using basic authentication on a connection that is not secure
You should add security.basic.enabled=false in application.properties file and put it under src/main/resources path.
We have a redis instance setup with ObjectRocket which provides us with a host, port, and auth key. I can connect fine with the redis-cli to the instance but I can not figure out how to configure apiaxle-proxy to use the auth key. I have the config json file setup with the host and port but have tried an auth key and a password key in the config file and have not been able to get it to work.
Does apiaxle support connecting to a redis instance that requires auth?
After investigation, apiaxle actually did not have this support. I forked and submitted a pull request for this and now it does support authenticated redis stores.
There's this thing I don't understand concerning LDAP (conceptually speaking, and - at least so I think - not tied to a particular implementation).
I noticed that a typical LDAP client library(for example apache DS) does a connect() first (for which some servers might require username/password), and then executes a bind() operation (which also requires username and password).
Questions:
What is the point of this two step operation in LDAP?
Does it add extra security?
Why not just a single step ?
What is the conceptual signification of these two steps ?
When an LDAP client connects to an LDAP server, that connection is unauthenticated. Clients use the BIND operation to authenticate the connection. The server then processes requests on the connection using the authorization state of the connection with the privileges and access control thereto.
Some (if not most) LDAP APIs offer a single-step connection and BIND, for which one must provide the credentials of the user, or a pre-constructed BIND request (there are different types of BIND requests, simple and SASL). In the case you describe, the API is most likely establishing a connection to the server and then issuing the BIND request to the server. If this is successful, then the connection's authorization state is set. This would be a "convenience" method for clients.
Separating the connection from the BIND (the two steps you mention), is done so that the same connection can be used with different authorization states. Each BIND resets the authorization state of the connection. The LDAP client can connect, then BIND using one user and credentials, perform some operations as that user, then send another BIND request on the same connection to change the authorization state to that of a different user. This enables the client and server to be more efficient since the connection need not be made more than once. This is supported by LDAPv3.
The UNBIND request's name is a relic of LDAPv2, which did not allow multiple authorization states per connection. UNBIND is not the opposite of BIND, and it does disconnect as you discovered. LDAP clients using LDAPv3 can transmit a BIND request to change the authorization state of the connection. The misnamed UNBIND request does not "un-authorize" a state, it merely disconnects the LDAP client from the LDAP server.
see also:
LDAP: Programming Practices
LDAP: Authentication Best Practices
Actually, there is a difference!
Connect() refers to the connection to a LDAP server on a specified hostname and port, as the bind () binds to the LDAP directory with specified RDN and password.
Hope this is helpful!