QPIDJMS-548: support taking principle and credentials from context

[michaelandrepearce]

Add mapping from jndi principle and credentials to username and password for the default connection factory when using provider url Add test case

[michaelandrepearce]

@gemmellr :dog: please.

[michaelandrepearce]

@gemmellr the issue, we are getting is that whilst ActiveMQ (Openwire) and ActiveMQ Artemis (CORE) clients seem to be honouring the credentials when set via JMS as such its vendor agnostic and secrets can be present to app securely and separately connectionFactory.createConnection(user,password)

where as with Qpid we are getting issue whereby connecting to secured artemis clusters we seem to be having to set the credentials on the CF itself for it to be happy with artemis when secured. And thus looking for options how to securly and in an agnostic way (by using JNDI properties that are explicitly meant for credentials) set that then on the CF if it is having issues not honouring the creds passed when we do connectionFactory.createConnection(user,password)

putting credentials in url, isnt the best as you are essentially mixing a config item with a security item, e.g. i want the URL to be visible to ops/dev teams theres no security concerns there, but credentials clearly more sensitive. Thus why to look to use the JNDI properties that are meant for credentials.

[michaelandrepearce]

Just for your benefit, we are actually trying to switch some Kafka Connect JMS Sinks to use AMQP to get everything over to AMQP instead CORE/OPENWIRE , we are using this vendors connector.

https://github.com/lensesio/stream-reactor/tree/master/kafka-connect-jms/src/main/scala/com/datamountaineer/streamreactor/connect/jms

Which is where the issue lays around the credentials. It seems to be not happy when we switch to QPID-JMS client and is relying on creating the connection and passing in the credentials using connectionFactory.createConnection(user,password) https://github.com/lensesio/stream-reactor/blob/master/kafka-connect-jms/src/main/scala/com/datamountaineer/streamreactor/connect/jms/JMSSessionProvider.scala#L109

but as noted when using qpid its barthing out access issues to artemis which we dont get with openwire or artemis client.

[gemmellr]

Well again, there are ways that dont require putting them in the URL, including the very one you used to implement the change under the covers.

If you are saying that the factory.createConnection(user, pass) method doesnt work and this does, then that would likely be a bug that should be investigated and fixed, but it is not a good reason to add this hack, which I still dont intend to.

For what its worth, the createConnection(user, pass) method is tested, and it operates by passing the credentials to the client innards in the same field as setting them on the factory does, since both are transferred to an intermediate object from where they actually get used, its actually the more explicitly set of the two, so I dont immediately see how this could make any difference at all to what the client does.

[michaelandrepearce]

If you are saying that the factory.createConnection(user, pass) method doesnt work and this does, then that would likely be a bug that should be investigated and fixed, but it is not a good reason to add this hack, which I still dont intend to.

Ok let me see if i can work out why this seems to not be working in the other project i referenced and see if we can make some kind of reproducer, agreed, i would also prefer to have this working as it should with the credentials just being set at connection creation time, just i struggled the first time to see why it wasn't working where as setting on the CF itself was. If you have any tips to where it might be causing issue for us to hunt down please share.

[gemmellr]

I dont, as I say I cant really see a reason this would alter the client behaviour at all really, during connection the different routes are essentially the same and the details are passed into the client innards in the same way at the same point in both cases, one just calls a getter to retrieve the existing value from the factory first while the other is provided it, from then they use a common impl.