Set a data service (OSGI bundle ==> .jar) to be only accessible from a specific connector in jetty.xml file

[Anonymous]

Hi community,

I created two connectors in jetty.xml file, so two ports will be used for my data services as follow : 

- 8043 : used for all data services using https and one way ssl (client is not forced to be trusted)

- 8053 : used for all data services using https and two way ssl (client is forced to be trusted)

How can i set a data service to use only the desired connector (8043 for example) because when i deploy it in karaf as osgi bundle (.jar), it becomes accessible from all the ports i created in jetty.xml file.

Ps: My data service used for tests is a very simple rest api.

Thank you in advance.

Regards

[Anonymous]

I think the easiest way of achieving this with the TOS product is to run two different ESB Runtimes. Have one for SSL with client authentication and one for just SSL. 

[Anonymous]

Hi @rhall ,

I tested this solution (just after raising the ssl configuration issue in tos esb 7.2.1 and using the 7.0.1 version) and it works well, however, if i want to use several ports in the future (this need will comming soon), we have to create as many runtimes as ports and i think that the jetty configuration in this case is more interresting.

Regards

[Anonymous]

What is your use case for using several ports? It sounds like you may want to switch to using microservices, but that is a paid for feature.
This *may* help you out, but I have not tried this.....

https://help.talend.com/reader/RIDndCjEFD2oHNLa9CrfAQ/MMq_a_Ap1Vi2P05b85_ppQ

[Anonymous]

Hi @rhall,

Globaly we have to create 3 ports : 

- The first for the internal customers with https and basic Oauth.

- The second for the external customers with https and 2 way ssl

- The third also for the external customers but who will disappear in the future (may be in a few months)

Why we use a third port ? 

- Customers will disappear in the future

- The process of setting up security in the compagny is long (Adding, updating or deleteing a certificate for example takes much time)

- infrastructure service with is responsible for the security (and many other things) is busy every time ...

So we discussed on that together and we decided to create a keystore for customers who will disappear, the goal is to make the decomissioning of services more simple (remove services, port and delete the keystore).

Ps : We have the cloud version since 2 months and the Talend support is helping us to choose the best architecture and installation for that, when this platform will be ready, we can start to migrate our works from TOS version to cloud version and we will be able to use the microservices in the case.

As it is not the case for the moment, we have to continue using the TOS version, we noticed also that the installation of 3 runtimes in the cloud version (wich use TMC and remote engine) is different from the on premise installtion and the infrastructure will not accept to create several runtimes... that is why i want to know how to do that in jetty.xml file to use only one runtime and try to choose the best solution (jetty configuration or microservices) in the cloud version in the future.

Regards   

[Anonymous]

Hi @rhall,

Globaly we have to create 3 ports : 

- The first for the internal customers with https and basic Oauth.

- The second for the external customers with https and 2 way ssl

- The third also for the external customers who will disappear in the future (may be in a few months)

Why we use a third port ? 

- Customers will disappear in the future

- The process of setting up security in the compagny is long (Adding, updating or deleteing a certificate for example takes much time)

- infrastructure service with is responsible for the security (and many other things) is busy every time ...

So we discussed on that together and we decided to create a keystore for customers who will disappear, the goal is to make the decomissioning of services more simple (remove services, port and delete the keystore).

Ps : We have the cloud version since 2 months and the Talend support is helping us to choose the best architecture and installation for that, when this platform will be ready, we can start to migrate our works from TOS version to cloud version and we will be able to use the microservices in the case.

As it is not the case for the moment, we have to continue using the TOS version, we noticed also that the installation of 3 runtimes in the cloud version (wich use TMC and remote engine) is different from the on premise installtion and the infrastructure will not accept to create several runtimes... that is why i want to know how to do that in jetty.xml file to use only one runtime and try to choose the best solution (jetty configuration or microservices) in the cloud version in the future.

Regards   

[Anonymous]

I see. I am not entirely certain how to achieve this scenario or even if it is possible. I suspect that it probably is possible though. Since you are buying the product, what I would recommend is that you state this as a requirement that must be resolved. Support and Professional Services will look into this and they will have access to R&D support.