JAZZ external access
We've setup our Jazz CLM for internal access - a single instance install serving 2 seperate internal domains through a proxy server (squid) using the default Tomcat.
Management now wants to allow our clients access to certian JAZZ features (eg. status reports, problem reporting) against systems they utilize.
Has anyone setup external access to their JAZZ env in a similar fashion? if so I'd like to here how you happened it.
Currently our IM group is proposing setting up VPN accounts that customers first log into, then they have to log into JAZZ tools. We would prefer a single JAZZ sign-on.
What implemenetation options are available to me - an outside facing proxy, etc..?
One answer
Please make sure to understand what users can or can not access in your system. RTC is for collaboration and unless you restrict access, it is more done for sharing information than for hiding.
Comments
I can appreicate that RTC is made for colloboration however it has to be done in a secure fashion otherwise you are letting your company's Intellectual property walk out the door.
You mentioned that several coimpaines have done this. Can you ellaborate on what their solution was?
One approach that we are using is placing the SCM sourcecode into another project with strict read access.
Other customers have created a special server where the external users have access to. They don't have access to the internal one. They can browse the projects on that server they have access to. The disadvantage here is that the external users have their work items and the developers usually have linked work items and there is no automatic static update. You could overcome that with some Plain Java automation.
In 4.x there are Access groups you could use, however, you would have to come up with some good automation (follow up action or calculated value provider in Java) to sensibly set the default visibility.
For hints on automation see https://rsjazz.wordpress.com/ for example https://rsjazz.wordpress.com/2013/06/26/attribute-customization-java-based-value-providers-conditions-and-validators/ .
As a last word, RTC has been developed to support transparent, agile development. That was the main focus in the beginning.So it is designed for transparency. Enterprise customers want that and they want to hide stuff, so there are several requests in the backlog to make that possible. It is just a question how to implement all that without sacrificing the benefits RTC has, like useability and performance.