Hello,

Sorry if this is documented somewhere, but I haven't been able to locate it.

I am running an RT 4.0.8 system with a few privileged Administrators and a few 
hundred unprivileged users who log into an RT SelfService interface to 
communicate (as well as by rt-mail) for support purposes. 

One of the Admins has requested access to the contents of a queue be given to a 
small group of unprivileged users. The most obvious way is to use a query to 
generate an RSS feed. So far so good. However, we may want to restrict access 
of the feed to a select few people in the organization. One way is to keep the 
feed URL confidential. This might work, but I was wondering is there is 
anything more robust than security-through-secrecy. Also I cannot find any way 
to manage the RSS feeds such as deleting or shutting it down when it has 
outlived its usefulness. Can anyone suggest where I can find this out. 

Another related topic is the "Go to Ticket ..." box where unprivileged users 
using the SelfServe interface can type in any ticket IDnumber and access the 
entire ticket. I can see how useful this is, but I'm wondering how to restrict 
access to this practice in the case where each tickets is to be considered 
confidential/privileged between each staff member and the support 
Administrators. So far, there is no issue of confidentiality in our 
organization, but it may come to the attention of management that naiive staff 
or even people who should know better and show lack of judgement by disclosing 
passwords, access codes or confidential information in their support requests 
that may be read or mined by others without privilege to this information. 

Again, we are not a super-secret organization, but I would not want to be in a 
situation where one unprivileged RT user has divulged confidential information 
to another unprivileged RT user who has been able to mine the RT SelfService 
page or a forgotten RSS feed for information. We have a policy right now that 
no confidential information or passwords/codes etc be included in tickets, but 
people are very fallible and any advice to target access a little better would 
be appreciated! 

                                                                      Duncan. 

Reply via email to