How to setup streams with different access control to components for external access
Karthik Krishnan (884●5●119●163)
| asked May 06 '14, 12:26 p.m.
edited Jun 01 '16, 11:34 p.m. by David Lafreniere (4.8k●7)
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
Geoffrey Clemm (30.1k●3●30●35)
| answered May 08 '14, 11:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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. Karthik Krishnan selected this answer as the correct answer
Comments We will go with the approach of having multiple project areas for permissions of components. Even though this technique is cumbersome in terms of managing users & permissions throughout the project areas, this is more sensible in terms of organizing components access rights.
Thanks a lot Goeff for your inputs and it was nice talking to you.
Cheers,
Karthik
Note: I think this might have been answered before 'access groups' became available for SCM artifacts. The answer above is still acceptable, but this feature might add extra flexibility on how to define the read access of components/streams (ex: you can define an access group of 'internal' and another one of 'internal'+'external')
Hi David, Thanks. Yes noticed it in RTC 6.0.1 but not sure if it's easy to script the access groups.
We now have some automation to create Project Areas for managing the component access. With Access Groups, I don't know if there are any API support to automate this.
I will look into this anyway.
|
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.