I have hazelcast deployed in c/s mode , where I started using UserNamePassword Credentials for authentication, so during the start of server and client, I used username1, password1 as my credentials.
Now due to security aspects, I want to update the credentials, how do I achieve this without downtime on server and client side application .
Hazelcast doesn't support the client credentials rotation out-of-the-box. It could be resolved incrementally:
introduce authentication config (login module stack) which accepts both - old and new credentials;
do a rolling restart of all members to activate the new authentication configuration;
replace credentials in client configurations and restart all clients;
configure members to accept only the new credentials and do the rolling restart again.
This is a similar scenario to updating TLS certificates in the running cluster. Check it in the Hazelcast reference manual:
https://docs.hazelcast.org/docs/4.1/manual/html-single/index.html#updating-certificates-in-the-running-cluster
Hazelcast Group name/password was available until 3.12.x (it's removed since Hazelcast 4), but it was never meant to provide security and therefore does not support password rotation.
<group>
<name>dev</name>
<password>dev-pass</password>
</group>
To configure properly the security in Hazelcast you need to use SSL (which is an Enterprise feature). SSL supports key rotation.
Related
Running on RHEL 7.5 with Java 8. Kerberos 5 release 1.15.1.
We are seeing a strange behaviour with this set-up that has been seen in all versions since 2.11.10.
Note, I can't post direct logs or config as it my company blocks this.
Steps to reproduce
1) Configure gerrit to use kerberos
gerrit.config
[container]
javaHome = <path to JRE>
javaOptions = -Djava.security.auth.login.config=<path to jaas.conf>
[auth]
type = LDAP
[ldap]
authentication = GSSAPI
server = ldap://<AD Realm>
<.. other AD related stuff..>
jaas.conf
KerberosLogin {
com.sun.security.auth.module.Krb5LoginModule
required
useTicketCache=true
doNotPrompt=true
renewTGT=true;
};
which is direct from the documentation.
2) kinit the keytab to create a ticket in the cache.
3) Try to login. It fails with "Server not found in Kerberos database (7)".
It will also fail if you change the jaas.conf to try and use the keytab directly.
You can access LDAP directly using the username/password but due to Company restrictions we can't have an unencrypted password at rest on a device so this is not a viable long, term solution.
We have taken packet captures of the traffic to the AD Realm and we see the same behaviour whether we use the keytab or the cache.
1) For the kinit we see one request to AD with the SPN field set to the SPN from the keytab. This, of course, works fine.
2) For any request from Gerrit we see TWO requests to AD, the first has the correct SPN from the cache/keytab the second tries to send an SPN of "ldap/" no matter what value of SPN is set. This second request is what is causing the error as that SPN is not recognised b AD.. Note, we have tried keytabs with various SPN's (HTTP/device, host/device, HTTP/device# etc etc). The same thing happens every time.
This may well be something very simple is wrong in our config but we have been banging our heads on this for weeks now.
The second request most likely shows up because you specified an LDAP server ldap://<AD Realm> in Gerrit's configuration. HTTP GSSAPI authentication may very well have succeeded at this point, but now the application needs to authenticate itself against the LDAP server before it can retrieve information about the user. That happens independently from the HTTP authentication itself.
It's normal that the SPN is not recognized because Active Directory generally doesn't use <AD Realm> to pick a domain controller – instead the individual server names have to be specified, e.g. ldap://dc01.ad.example.com. (Real AD clients choose a server automatically via DNS SRV records, but plain LDAP clients often don't support that.)
Note also that a keytab is essentially an unencrypted password at rest.
I have a java application running on a WebLogic 12c instance.
I would to perform a mutual authentication with HttpsURLConnection but I didn't understand if I need to create a SSLSocketFactory (code side approach) and/or setup the "Two Way Client Cert Behavior" on the server of WebLogic (configuration approach).
In this case, should the client certificate be imported into the weblogic or java keystore?
You should configure WebLogic for two-way SSL to enable a double authentication (client & server). This documentation explains how to achieve this.
Because I don't need to consider security issues in my application, I want to connect to RabbitMQ using the Java client without a password.
In the management UI, I set the users password to "no password". Then I tried it this way:
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
factory.setUsername("myuser");
connection = factory.newConnection();
Alternatively, I tried to assemble the URI by hand:
factory.setUri("amqp://myuser#localhost:5672");
...but in both cases the authentication fails with this exception:
Exception in thread "main" com.rabbitmq.client.AuthenticationFailureException: ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:339)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:716)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:760)
at de.bmw.rabbitmq.workerqueue.Producer2.main(Producer2.java:51)
Is it even possible to get a connection without a password?
Passwordless authentication can be achieved by using the rabbitmq-auth-mechanism-ssl as documented here: https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl. This requires that SSL/TLS support is set up and working. If this option is chosen, a trusted root certificate is used for authentication, and any username/password is ignored altogether.
I'm currently investigating whether passwordless authentication is possible in conjunction with LDAP, but I haven't had any luck getting this to work.
Edit: In my environment, Windows services are authenticating using certificate-based auth, and the RabbitMQ cluster admins can authenticate to the management web UI using LDAP. In case you're interested in LDAP auth, here's another post about it.
Because I don't need to consider security issues in my application
I would heavily question this assumption. In fact, I would go so far as to say this is never correct.
That being said:
just use a simple password that anyone can know. It's going to be easier to do that, than to try and make RMQ work without a password.
To finalize this issue. As suggested by Derick Bailey: I helped myself by introducing (default) credentials for the different clients.
I have a couple of java servlets which need to be secured with Mutual authentication with X509 certificates. I used the information from here to
implement mutual authentication and it works fine on my machine.
Now our integration environment has BigIP for load balancing traffic to weblogic. The SSL is terminated at BigIP and it forwards the https request to weblogic using an internal certificate instead of the client's certificate it got with the original https request. So mutual auth is not working.
The BigIP team says they can put the client's certificate in the HTTP header (SSL_CLIENT_CERT), and I am not sure how to configure weblogic to read client's cert from http header.
Do I need to write a custom Identity assertion provider and configure it in weblogic?? Is this the best approach or do I have any other option?
Any help on this is greatly appreciated!!
It is necessary to configure the identity asserter if you are using two way ssl to verify the client identity
and to use it to restrict access to application.If you are using two way ssl with signed CA(Verisign etc.) it
will be only used for trust -not for authentication or any type of application access restriction.
Check below link for detail clarification on above
http://www.oracle.com/technetwork/articles/damo-howto-091164.html.
You can follow your steps for configuring the X509 Certificate Authentication for weblogic server.
Along with above you need to follow below steps
1) Make sure that BIG IP handles client certitifcate and client key which can be configured in the HTTPS monitor in BiG IP.
2) Configure the BIG-IP to insert a header named WL-Proxy-SSL: with a value of true into each request.
3) Enable weblogic proxy plugin tab in
AdminConsole —> Servers —-> [Your_Server_Name] —> Configuration [Tab]
—> General [Sub-Tab]
Click on “Advanced” Link
Check the CheckBox in this Page “WebLogic Plug-In Enabled”
Above changes will help in undersatnding the weblogic that request coming from BIG IP was initially the SSL enabled.
Check below link for configuring WL-Proxy-SSL with BIGIP
https://support.f5.com/kb/en-us/solutions/public/4000/400/sol4443.html?sr=10058313
The scenario is around calling an external SSL SOAP web service from within Mirth. The web service is requires an SSL/TLS connection along with a client certificate.
The intention is to use the built-in SOAP Sender Destination to call the remote secure web service, and somehow include that client certificate.
I understand that you first need to install that client certificate into the Java runtime. This may be within the Java runtime's certificate store or the Jetty certstore.
The platform:
Windows 2003 SP2
Mirth 1.8
Java jre1.5.0_09
Question: what configuration steps (Mirth, JRE certificate stores, etc.) would you suggest to successfully have a Mirth SOAP Sender include a client certificate (*.cer) when calling a web service secured by SSL?
The Java runtime, or more specifically, the Sun JSSE provider, will present a client certificate if some system properties are set. You can read details in the JSSE Reference Guide, but the important properties are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.
There are a few drawbacks to this approach. First, setting the key store password as a system property makes it accessible to any code running in that process—although this can be controlled if a SecurityManager is installed. Second, these settings will be used for any SSL sockets created through the "default" SSLContext. If you need different credentials for different endpoints, you'll need a Mirth-specific solution.
No starting point was specified in the question, but if starting from scratch, the easiest approach is to create a new Java Key Store ("JKS" format) and generate a new key pair and a CSR. After sending the CSR to the CA and getting a certificate back, import it into the same key store. That key store is ready to use.
If a certificate is already available, it is likely to be in a stored with its corresponding private key in PKCS #12 format (.p12 or .pfx file). These can be used directly by a Java application, but the javax.net.ssl.keyStoreType property will need to be set to "PKCS12"
Mirth 1.8 cannot send a client cert when calling a SOAP web service.
I'm late a bit here for this but actually there is a possibility that it could. By sending a few config parameters to the JVM you could get the underlying SOAP engine to switch to HTTPs and provide the proper certificate.
refer to this question for details on which parameters to set for configuring the VM
Java HTTPS client certificate authentication
you will notice there are quite a few things to take care of. Normally HTTPs and client authentication should "just work" once you configured your certificates appropriately. BUT there are some servers out there that are not so friendly to B2B style clients so you have to watch out.
Using JDK 6_21 and a few tweaks with the certificate I was able to get one of them servers to behave but it was long and painful on our side for something that takes about 15 minutes to configure properly on the server.
here is another question that address this very issue (client side authentication towards unfriendly servers).
Client SSL authentication causing 403.7 error from IIS