How to extend a firewall protected CLM deployment with a RTC serving as a publicly available issue tracker?
we currently operate CLM behind our company firewall, i.e., user have full access to the system while being connected to the company intranet or from the outside using VPN.
In addition to the internally used CLM, we also operate a publicly accessible issue tracker. The latter needs to be replaced, so the question came up whether this can be achieved using RTC, since we use this as an internal issue tracker anyway.
What we need to achieve is to allow customers to access RTC in order to file and follow progress on their defects, enhancements, etc. while keeping all of the data currently contained in the CLM inaccessible to them. However, internal users shall be able to access this customer provided data alongside the "protected" internal work items. Artefact duplication should be prohibited, though.
My rough idea would be to deploy a second publicly accessible JTS/RTC server, whose PAs will be configured as members of the existing internal CLM projects, which are still protected by being behind the firewall.
Does this sound feasible or does anyone have any ideas how this can be achieved more effectively?
Thanks a lot for your input in advance. Cheers,
Timo.
Accepted answer
On Jazz.net we expose the RTC development for internal and external use. So this can be done.
If you want the users to be able to access your current internal development RTC, you would have to move it - at least a HTTP proxy outside of the firewall - keeping the public URI stable.
You could set up a dedicated RTC server outside the firewall and allow customers access to it and have the internal RTC server befriended to the external one, to be able to create links between the two.
Pleas be aware that RTC has only limited capabilities in data hiding. So depending on what you want external users to see and not to see, you would have to check if RTC can provide you with that.
Comments
Ralph,
thanks for your competent answer. The scenarios you describe therein confirm my rough understanding.
As to access configuration, I guess this will boil down to access lists and team visibility. What I'd imagine is to have a public accessible PA where everything can be accessed by everyone. This would then be "befriended" with the internal PAs which would allow access only based on the aforementioned access lists and team visibility configurations. However, WIs could be linked between these PAs. At least this is something I'd expect to work this way from my experiences with Jazz.net, where I cannot deep-dive into the complete tree of linked artefacts but get do an error message at some point down the tree ("no account on this sever", or something like that).
But again, with stating that such a scenario is feasible you already provided the most important piece of information. I guess, when we decide to implement anything in this direction, the best would be to contract this project out to Rational Service and not to try too much on our own.
Thanks again & Cheers
Timo.
Timo,
the challenges are not really related to Jazz. Any other product would have the same problems if the other server is not reachable. Please note, your answer made me think. At least the external RTC server must have a way to reach the internal one - and the other way around, otherwise creating the links will be problematic. This is typically done buy placing the proxy outside and only allowing the proxy to communicate through.
This is really just a challenge of network topologies and security and I am sure IBM has people that can help you make this work.
Other customers have done this.
External users would not necessarily have any access to your internal servers. They would not be able to follow the links there at all and you would only make sure that only members of the project area hierarchy can access your servers.