Project data isolation
Hi,
I have learnt recently RTC1.0 doesn't provide data isolation among projects. However, that is crucial feature for us at the moment and can destroy are plans to use RTC on few projects at the same time (our customers require NDA's to be signed off and data security). I have been thinking... I have noticed web URL always mentions project name therefore I could configure deployment descriptor to require certain role to be associated with an user. Would that work for rich client as well? Could you please point me to some specification how the URLs look like? Roman |
6 answers
The URLs that the RTC client uses to access data in the Jazz Team Server
do not include the project name. The URLs are in the form of <server>/jazz/service/<servicename>. I'm not sure if there is a specification about the communication between the client and server from the RTC client, because it is not API. Roman Smirak wrote: Hi, |
I was wondering... Is there a way to restrict an access from rich client?
Ie. specific role can use the rich client other are supposed to use web ui. Next question: if I was about to implement an interceptor to implement the data isolation (to parse web service request and check against the configuration) would you recommend any material to study? Regards, Roman "Matt Lavin" <matt_lavin> wrote in message news:g77cvk$23p$1@localhost.localdomain... The URLs that the RTC client uses to access data in the Jazz Team Server |
There is not a way to restrict access from a rich client.
About implementing an interceptor, that would be pretty hard (near impossible). Most APIs between the client and server (at least the low-level repository API) are based on Item IDs and not related to project areas. You would need to provide an implementation of each service, to understand the meaning of the arguments, to track down the project areas associated with the incoming data, and the compare that to the rights of the requesting user. If you were set on doing it (and I really don't recommend it), the only thing I could recommend is to get the code, learn every remotely accessible API and understand how the data isolation would impact that API. Roman Smirak wrote: I was wondering... Is there a way to restrict an access from rich client? |
Just loud thinking....
I am unfamiliar whether app containers allow you to specify access rules based on URL patterns and app container defined roles and role assignments. Assuming that works and you can scope the problem of project area isolation to web clients, I am unsure whether you can succeed. Not all URLs follow the pattern and include the project area name. Some URLs are just type specific and use UUIDs in them to identify the actual item. In addition the request parameters use DTOs that don't follow the scheme either. Kai Jazz Process team Roman Smirak wrote: I was wondering... Is there a way to restrict an access from rich client? |
Millard Ellingsworth (2.5k●1●24●31)
| answered Aug 04 '08, 3:54 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER
This isolation topic seems to come up pretty regularly. While I appreciate how it can be important in some situations, is it a licensing issue or some other sort of concern that keeps folks from just setting up a separate server? I would think you could even share a DB2 server among several web servers and still achieve your isolation requirements. Each app server could even connect to a different database. A Linux server capable of doing this can't be that expensive, especially compared to the software and support costs (and headaches) of trying to spoof the system. But maybe I'm missing something.
|
Hi,
it is the licensing issue; an idea was to share cost and encourage teams to move from cheap/open source tools like Jira to RTC. Since we bought the licenses already this was unpleasant surprise... Regards, Roman "millarde" <millarde> wrote in message news:g77n03$6hk$1@localhost.localdomain... This isolation topic seems to come up pretty regularly. While I |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.