I am confused on SASL_SSL. Do we need SSL certificate configured for the Kafka producer application ? Or is it just the username and password ? What is the difference between SASL_SSL and SASL_PLAINTEXT ? I am sending message from a plain java application to a topic.
SASL_SSL used TLS encryption like SSL so you will need to create a certificate, and with SASL_SSL you need to specify an authentication method.
This page should help you https://developer.confluent.io/learn-kafka/security/authentication-ssl-and-sasl-ssl/
SASL_PLAINTEXT doesn't use TLS encryption (SASL_PLAIN does and this uses the username/password authentication).
It really all depends on your security requirements. SASL_SSL is mainly used when integrating with a existing authentication server but this increases your vulnerability to attacks.
Related
In ActiveMQ 5.15.6 they enabled the TLS host name verification, and I see my application failing after upgrade.
In their documentation they mentioned they have fixed the server side TLS validation by making default to False. Is their any way I can make TLS hostname verification FALSE at client side as well?
Yes, you can disable TLS hostname verification at the client side as well. Use something like this:
ssl://hostname:61616?socket.verifyHostName=false
or
ssl://hostname:61616?verifyHostName=false
In Camel's examples doesn’t have any example or documentation for mutual TLS.
How to setup the mutual tls setup in both java dsl and spring dsl ?
From the camel point of view you'll be targeting a https resource if you are acting as a client or serving it if you are the service. The mutual authentication is handled at the network layer so Camel won't have explicit hooks.
In the case of the client add the keystore/truststore (with the required certs added) to the startup commands -Djavax.net.ssl.keyStore=C:\temp\clientkeystore.jks -Djavax.net.ssl.trustStorePassword=password
-Djavax.net.ssl.trustStore=C:\temp\truststore.jks -Djavax.net.ssl.trustStorePassword=password
The additional flag -Djavax.net.debug=ssl is useful for debugging ssl handshake
For a server (assuming Spring boot) enable ssl as follows, again with the required certs added to it's keystore
server.ssl.enabled=true
server.ssl.key-store=C:\\temp\\serverkeystore.jks
server.ssl.key-store-password=password
server.ssl.trust-store=C:\\temp\\trustStore.jks
server.ssl.trust-store-password=password
server.ssl.client-auth=want
Relating to my other question: UnboundID LDAP DIGEST-MD5 binding cause NPE
I'm using ApacheDS as the server and UnboundID as the API.
I followed the suggested answer and the NPE is gone. However, now I'm getting this error.
LDAPException(resultCode=49 (invalid credentials), errorMessage='INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for 'dn:uid=blah,ou=dev,dc=blah,dc=com in realm : mizar.com', diagnosticMessage='INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for dn:uid=blah,ou=dev,dc=blah,dc=com in realm : blah.com')
at com.unboundid.ldap.sdk.LDAPConnection.bind(LDAPConnection.java:1881)
at UnboundDemo.main(UnboundDemo.java:40)
Code as follows:
conn = new LDAPConnection("1.1.1.1",389);
mdBind = new DIGESTMD5BindRequest("dn:uid=blah,ou=dev,dc=blah,dc=com", null, "test", "blah.com",null);
bindResult = conn.bind(mdBind);
System.out.println("MD5 bind success!");
Here's the ApacheDS SASL configuration from the Directory Studio config page:
SASL Host: 1.1.1.1
SASL Principal: ldap/ldap.example.com#EXAMPLE.COM
Search Base Dn: ou=dev,dc=blah,dc=com
The ApacheDS doc didn't explain what the SASL Principal is so I'm starting to think that it may be a mis-config on my part. The main idea here is to test UnboundID against a number of SASL mechanism.
It is likely the case that the ApacheDS server isn't configured to store passwords in a format that allows it to determine the clear-text value for the password.
The primary attractive property of the DIGEST-MD5 and CRAM-MD5 SASL mechanisms is that the password is combined with other information and encoded with a one-way digest before being sent to the server. This ensures that the password is not transmitted in the clear, so that it is protected against anyone who can observe the communication without the need to secure the rest of the communication. However, the ability to authenticate with one of these mechanisms requires that the server be able to determine the clear-text version of the password so that it can perform the same cryptographic processing as the client.
If you're just looking to test the UnboundID LDAP SDK's ability to perform SASL authentication, then I'd recommend using the PLAIN mechanism, since it shouldn't impose any special requirements on the user entry. If you really want to use DIGEST-MD5, then you'll need to ensure that the server has access to the clear-text representations of the passwords for the users that need to authenticate with that mechanism.
Neil
is it possible in spring framework to have 2 login implementation at the same time for the login page? Form login and Certificate based login (x509). I've tried either one of these method but combining them at the same time, it is hard for me to do it. Any idea how to enable these two methods? Any book or site reference that I can refer to regarding this?
Thanks
Yes, it is possible, by making the SSL client-auth optional.
Here on Baeldung is a good tutorial on enabling SSL client authentication with X.509 certificates, with forced client-auth (not good for your case, with login form fallback)
Follow that tutorial and pay attention in the application.properties file to make the client-auth want instead of need. This will make the client-server SSL handshake attempt to ask for a certificate.
server.ssl.client-auth=want
If the browser does not provide a certificate (does not have any configured or the user clicks on cancel when prompted to select a certificate from a list), the SSL handshake will be done without the client certificate, and the user will have to login with username+password
If the user chooses a certificate, the SSL handshake is done with the client certificate. The server then verifies the given certificate in the trust-store. If the certificate is valid, the SSL handshake is successfully established. Otherwise, the connection is refused by the server.
Pay attention that
only the authentication is done with the x.509 certificate. For authorization, you must provide the X509Configurer an UserDetailsService implementation, to retrieve the UserDetails for the user that just authenticated via x.509
thus, if you have a database of users with their assigned roles, even if the certificate is in the trust-store, the user might not be in the user database, so you will have to treat this possibility in your application logic. I.e. when the SSL connection is mutual, but the user is not present in the user database.
Yes it is possible. All you need is to declare x509 support in your http config:
<http ...>
...
<x509 ... />
....
</http>
and configure SSL in Tomcat.
See this entry and this thread.
Is there any way to configure an additional SSL listener port on an existing WebLogic server that uses a different keystore and truststore configuration from the "main" SSL port?
I don't think you can use multiple keystores for the same server - Even if you're using custom key/trust stores, you should be able to consolidate everything (using import/export for keytool/ikeyman).
Under the Server -> Protocols -> Channels tab, you can define an additional port using your SSL protocol of choice (t3s/https/iiops/ldaps) but your issue should be resolved by using the earlier suggestion alone.