Project

General

Profile

Forums » Open discussion »

constrainst when opening enteprise redmine towards the customer

Added by Terence Mill about 14 years ago

We want to use redmine for internal project config mamanagment but also for customer communication in some cases.
This means the customer can create tickets via the web frontend (not email only) and can track the ticket status so far.
At the moment we only use redmine internally (customer can't access web frontend) and use advanced subversion inegration where the source code is kept on the same server and user's are authenticated against enterprise ldap for redmine and subversion. We don't want to open up the whole server (where all tickets are kept and source code) to the internet because of security risks and that not all tickets and its information shall be shown to the customer.
So the core problem for opening redmine towards customer via the internet is
1. there is enterprise source code on this machine
2. the customer shouldn't see all tickets

The customer shall be enabled to see tickets which have a custom flag set or was created by himself. He shall also get notification when status changed to a special value. He shall able to create tickets. THe version managment ajnd planing shall be done by the internal redmine system, but we need to transfer tickets from external system to internal system when a ticket reached a special status (requirements stable - if that is even possible in real worlds projects)

So we could maybe setup a second redmine server using the same database only enabled with some modules as ticketing, but without svn and some others. Also on this physical server there is no source code kept localy in filesystem, to security flaws on the server won't harm. I am nore sure if this even is possible with the architecture or will result in mass data inconsistency or what the constraints are?
The second approach could be to make a kind of application level syncronization between the external server and the internal server. What means that all tickets changes on the tickets hosted on external server are mirrored towards the internal server and changes on the same tickets done on internal server are mirrored to external server.
The third approach is that we try to move svn server towards another server, but configure this svn server with apache this way, that it still uses the redmine mysql role-rights table for authorization and enteprise ldap for authetification, which is what we already do, but on the same server. We still have the problem that the custimer can see all tickets, because thre is no "role 2 ticket view" rights managment, so we could define views on tickets, that the customer can access but nothing else.

Is there any similar approach towards my requirements which helps? Does someone has a similar problem and has a idea how to solve?


Replies (5)

RE: constrainst when opening enteprise redmine towards the customer - Added by Felix Schäfer about 14 years ago

I haven't read all at lengths but:

  • pointing any number of redmine installations to the same DB will cause all those redmines to be configured the same, i.e. the same projects with the same modules enabled, and so on.
  • some parts of the SCM stuff is cached in redmine, i.e. other than the actual content, anyone allowed to see the "repository" tab will see every commit message, filenames, and so on (if you were to find a way to revoke access to the svn/SCM to one of the instances).
  • Redmine doesn't have any kind of app level synchronization, though some crude form of it might be possible once the REST API is finished (wouldn't hold my breath though).

You could deny access to the repository for certain roles, which would solve the code-seeing part, that won't solve the ticket-seeing part though. A member of a project with the permission to view tickets can view them all. The current solution to this currently seems to create a project to which the client has access, and a child project to that to which only employees have access.

RE: constrainst when opening enteprise redmine towards the customer - Added by Glenn Gould about 14 years ago

I remember a board entry http://www.redmine.org/boards/1/topics/17464 where some thoughts about a (roughly) similar usage szenario were laid out. However it won't help with the fact that you need to open a server with internal information to wild and dangerous internet. Depending from several parameters, like available network structure, the number of customers and and last not least how close business relationship to them may be, the idea with using kind of interface-projects could be coupled with something like (open)vpn access which could avoid opening the server to the internet completely.

RE: constrainst when opening enteprise redmine towards the customer - Added by Terence Mill about 14 years ago

I thought of creating a second server with apache, svn server and advanced svn inetgration. This means apache mod which uses url based user authenification for the svn webdavn url against enteprise ldap and the apache mod for redmine-mysql table lookup for user authorization based on role. I asking me if that is possible, i mean to use external https url based svn repositroy config in redmine server where the svn server is hosted on another apache server instance in the same domain like described above.
THis will solve the security server with the svn server hosted on another machine, where i can secure the server on ip level (mean only v(via role) developer partners have access to the svn server, but the customer only to the redmine server. Even if some manager would give svn read/write rights to customer it wont be able to acess the server physical.

RE: constrainst when opening enteprise redmine towards the customer - Added by Terence Mill about 14 years ago

Moreover i maybe found a solution for the ticket problem. There is patch available which changes tickets permission behaviour. See here

RE: constrainst when opening enteprise redmine towards the customer - Added by Terence Mill about 14 years ago

Felix Schäfer wrote:

I haven't read all at lengths but:

  • pointing any number of redmine installations to the same DB will cause all those redmines to be configured the same, i.e. the same projects with the same modules enabled, and so on.

I know that, and it shall be not the problem in fact i need to solve the issue problem in both systems (the external opened to the internet and the internal).
If i use a proxy web server in first DMZ for internet access which connects to the redmine web server in 2. DMZ and this web server has no network access to the svn server in 2 DMZ, but another internal redmine server does have and both redmine web server connects to the same mysql database in 3. DMZ it would be a secure thing wouldn't it? THe internal redmine web server would be only accessible within vpn network.

  • some parts of the SCM stuff is cached in redmine, i.e. other than the actual content, anyone allowed to see >the "repository" tab will see every commit message, filenames, and so on (if you were to find a way to revoke >access to the svn/SCM to one of the instances).

If the external redmine server could never connect to the svn server thet can't be established any cache. What would happen i i have configured a Project acrhive for https://mysvnserver/svnroot/.. and the redmine web server can't every reach it ? .. For the internal server it would work fine.

As i said i am only doing this in case somone accidently gave the wrong person the wrong rights or that there is a bug in any access module. The svn code is a real important part, which has to be secured hardly from internet attacks.

    (1-5/5)