How to setup streams with different access control to components for external access
Our goal is to expose RTC to some "external" developers who are not part of our internal network so that the developers can work from their own locations and can access RTC
The issue is we don't want to expose all components and make only few visible and few read only.
I tried the following approaches
Approach 1
In the same project area added a new team area (say "External dev") and assigned that as the component owner. Problems with this are
- The "external" developers can see much more than what they should see
- The main (internal) team members should be part the "External dev" team area which means maintaining the user registry on the Team area
- We have lots of other issues like exposing work items etc
Approach 2:
Set up new project area, create new team area and a stream. Add components from the stream of Main project area and set the main stream as flow target
Problems with this are:
- The user in the "external" project area needs to be a member in the main project (team) area to accept changes from as we need the flow to happen in both the directions
Are there any general practices / approaches for this kind of scenario where in we expose only what is need and not a lot due to obvious and legal restrictions
I read about the distributed SCM (https://jazz.net/library/article/535/) but right now we wanted o have minimal setup
By "External" I mean external to our company
Accepted answer
We had a meeting to discuss this, with the following summary of our conclusion:
Create a separate project area for each logical "read access control list".
Commonly in the above scenario, there will be:
- an "internal-only" project area, for the artifacts that should only be visible to internal teams
- a "public" project area, for the artifacts that should be visible to the internal teams and all the external teams
- one "external-x" project area for each external group x, which contains the artifacts that should only be visible to the external x teams and internal teams.
If one encounters the need for a different read-access control list from one of the above (such as artifacts that should only be visible to internal teams and external x, y, and z teams), a new project area would be created for that particular read-access control list.
Then a component or work items would be assigned to the project area with the appropriate access control list.
For streams, since to see a component in a given stream, one needs read access to both the component and the stream, it is commonly "safe" to make a stream visible to everyone, since they can only see the components that they have read access to. But if there is a stream whose existence should only be known by a limited set of teams, then you would assign that stream to the project with the desired access control list.
Note that in order to make this manageable, you would want to used a shared master process project area, so you aren't maintaining separate process descriptions for each project area.
In addition, you would want to script the addition of a person to a project area, because a given person (especially a member of an internal team) would need to be added to multiple project areas.
Create a separate project area for each logical "read access control list".
Commonly in the above scenario, there will be:
- an "internal-only" project area, for the artifacts that should only be visible to internal teams
- a "public" project area, for the artifacts that should be visible to the internal teams and all the external teams
- one "external-x" project area for each external group x, which contains the artifacts that should only be visible to the external x teams and internal teams.
If one encounters the need for a different read-access control list from one of the above (such as artifacts that should only be visible to internal teams and external x, y, and z teams), a new project area would be created for that particular read-access control list.
Then a component or work items would be assigned to the project area with the appropriate access control list.
For streams, since to see a component in a given stream, one needs read access to both the component and the stream, it is commonly "safe" to make a stream visible to everyone, since they can only see the components that they have read access to. But if there is a stream whose existence should only be known by a limited set of teams, then you would assign that stream to the project with the desired access control list.
Note that in order to make this manageable, you would want to used a shared master process project area, so you aren't maintaining separate process descriptions for each project area.
In addition, you would want to script the addition of a person to a project area, because a given person (especially a member of an internal team) would need to be added to multiple project areas.
Comments
