Spring-Amqp-NET libraries for RabbitMQ - SSL support - spring-amqp

We want to use spring-amqp-net in our applications to listen for messages in RabbitMQ.
https://github.com/spring-projects/spring-net-amqp
We couldn't figure out any configuration parameter for SSL connection neither in the source code nor in the documentation.
Does anybody now if spring-amqp-net supports SSL connection to RabbitMQ?
If yes, how can we configure the SSL connection in our .net application's Application.xml file?
Thank you.

I am not familiar with .NET, or that project (I am the lead for the Java Spring AMQP project).
With the Java Spring AMQP library, SSL is configured by appropriately configuring the underlying RabbitConnectionFactory and then that instance is injected into the Spring CachingConnectionFacrtory.
Looking at the code, it appears a similar mechanism is available in the .NET library...
public CachingConnectionFactory(ConnectionFactory rabbitConnectionFactory)
: base(rabbitConnectionFactory) { }
whereby you can configure the underlying ConnectionFactory with SSL and provide it to the CachingConnectionFactory.

Related

JHipster gateway application SSL certificate from cloudflare setup

So I am using JHipster to build my micro service architecture. I am at a point it is almost time to fully deploy my gateway, but i have an issue.
SSL/TLS specifically i use cloud flare to proxy my public ip, and provide certificates. I use kemp for layer 7 routing incoming traffic. My app is housed inside a Kubernetes cluster. My problem is i cant get ssl/tls to work right and I don't even know where to begin on how to add cloudflare certificates to my JHipster gateway.
Any suggestions or help would be greatly appreciated I have been looking for two weeks now trying to solve it on my own.
Have you read JHipster doc about TLS? https://www.jhipster.tech/production/#security
One point to think about is whether or not you want to expose your gateway publicly or if you prefer to put it behind a reverse proxy (e.g. nginx).
If you for the reverse proxy, you'll find plenty of resources to explain how to do it.
If you want to expose your gateway directly then it's not specific to JHipster, it's the same as for any java application, you must import your certificate into a KeyStore.
You can do it using JDK's keytool or simpler using KeyStore Explorer.
After that you might have to find a way to do it Kubernetes but I can't help here.

Solace JCA using JBoss JNDI

The JCA resource adapter uses Solace as a JNDI store for fetching connection and destinations. We are looking at an option where Solace JNDI option is disabled at the broker but the application needs to be fetch the connection factory/destinations using JNDI lookup in JBOSS server. Is this feasible?
This feature will be available in the upcoming release of the Solace JMS Resource Adapter. In this release, there will be the option to configure your application to use a non-Solace JNDI store. This can be done by setting the JNDI provider's (in your case, JBoss) Connection URL, username, and password in the Resource Adapter's bean properties.

Does JIRA work on Google Compute Engine VM

Is JIRA supported in GCE? If so, how to make it work?
We have installed 64-bit .bin of JIRA(6.4.1), and opened necessary custom http ports under Networks.
Started JIRA as service, but unable to see it work via browser. No error message than, timed out error!
Any help would be highly appreciated.
Note: We are new to Google Cloud Platform.
Did you enable the http and https services on your instance ? By default the GCE instance does not allow Http and Https traffic, you have to do it manually.
The Jira configuration for Google Compute Engine can be tricky. You need to make sure that:
The firewall rules under Netowrking allows a connection to Jira HTTP port or the HTTP enables in VM properties
The global Networking rules allow TCP traffic on this port
The virtual network have routes configured
If you use Apache as proxy for Jira (recommended) then make sure Apache is configured to point to the Tomcat port
Your Tomcat is configured
You have enabled port allocation using setcap utility
Your local machine firewall enables the connection (in Red Hat ipconfig is enabled by default and blocks the connections)
As you can see it may be tricky to install Jira on Google Cloud. It may be a good idea to use a deployment service like Deploy4Me to do this quickly and automatically.

spring boot + secure jmx

By default spring boot exposes a number of JMX endpoints, has anyone had any experience securing these, it seems there is no security surrounding JMX.
The only config available to Spring boot:
endpoints.jmx.enabled=true
endpoints.jmx.domain= # the JMX domain, defaults to 'org.springboot'
endpoints.jmx.unique-names=false
endpoints.jmx.enabled=true
endpoints.jmx.staticNames=
I have seen examples using JmxSecurityAuthenticator, should I follow this pattern.
AFAIK securing the JMX connections is all about how you set up the server. I think you just need to add a #Bean of type ConnectorServerFactoryBean.

Running an LDAP Server on Cloudbees

I have a simple Grails app that I've written to authenticate against an LDAP server. To develop it, I've installed ApacheDS locally and populated it with an LDIF file. Now I want to deploy it to CloudBees. Is it possible to install an LDAP server on CloudBees?
If not, an alternative seems to be to use the Grails ldap-server plugin. However, it doesn't have any documentation on how to configure it. How do I configure this plugin to load an LDIF on startup?
Unfortunately, running LDAP in a CloudBees app container/stack won't work because in-bound routing to your application port must be over HTTP/HTTPS.
Alternative 1: host the LDAP server outside of CloudBees (like on your own EC2 server)
Alternative 2: [for the highly motivated] you might be able to get a WebSocket gateway of some kind to work, but you'd special code on the client and server side to negotiate the socket stream hand-off outside of the LDAP server and client. [Client -> WS-Client --> CloudBees --> WS-Server --> LDAP Server]
gripe: why can't all protocols support virtual hosting like HTTP? -- that would make them much more Cloud-friendly :(

Resources