It's all about the answers!

Ask a question

Security issue: Need an ownership/visiblity recipe that allows single team ownership and multi-team visibility


Alexa Nafke (4167) | asked Jul 30 '13, 6:36 p.m.

I am looking for a security/visibility recipe that will work for the use case described below.

In our Project we have

Components: A B C D E

Teams: W X Y Z

Ownership and visibility should be as follows:

Component A: owned by Team W, visible only to Teams W, X and Y

Component B: owned by team X, visible only to Teams W, X and Y

Component C: owned by team Y, visible only to Team Y

Component D: owned by team Y or (Y and Z), visible only to Teams Y and Z

Component E: owned by team Y, visible to Teams W, X, Y and Z

I can easily satisfy the requrements for C and D:

  • create Team V as the parent of Team Y and Team Z
  • Make component C owned by Team Y with team-private visibility
  • Make component D owned by Team V with team-private visibility

For E, it might be acceptable to have it owned by Y with project-scoped visibility.  I am awaiting an OK from the team that owns it.  If not, then the requirement for E will change to "Component E: owned by Team Y, visible only to Teams W, X, Y, and Z"

I have not been able to come up with an ownership/visibility recipe that works for Components A and B. 

Any help I can get would be apreciated.

Thanks,

Alexa


Comments
Geoffrey Clemm commented Jul 31 '13, 12:45 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

When you say a "a component is owned by a team", what permissions did you intend that to imply.  Write permission? 


Alexa Nafke commented Jul 31 '13, 11:20 a.m.

I am concerned here with read access.  We have highly sensitive IP that needs limited visibility (component C in my use case).  That was easy to set up.  However, we have slightly less sensitive IP data that needs to be visible to multiple teams but must not be visible to all teams (Components A and B in my use case must not be visible to Team Z).  That is more, everyone-except-Team-Z visibility.  I have considered putting the multi-teams into a parent team that would own the component but I'm not sure that the individual teams will be OK having their components owned by everyone in the super-team.  Also, what are the implications of team ownership for components with regard to tailoring processes? 

Accepted answer


permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 01 '13, 2:45 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Currently, RTC only provides "hiearchical" team-area based read-access control on components.  In particular, you can say "only this team area and all of its child team areas have read access to this component".  But this does not give you the flexibility you would need to achieve the permissions in your example.  You could get most of them though.  For example, by making  Z the parent of W, and W the parent of X and Y, you can get the permissions you want for A, B, C, and E, but not the permissions you want for D.

The only workaround currently to achieving this kind of precise access control would be to define a separate "component access control" team area for each different read-access control list, and explicitly add as members of a team area the users that should have access to that component.   This would mean that every time you added someone to a team, you would need to add them as a team member of each of the appropriate component access control team areas. 

What we really want is work item Provide Access Groups in SCM (as already available for Work Item Access configuration) (249674) to be implemented.

Alexa Nafke selected this answer as the correct answer

Comments
Alexa Nafke commented Aug 07 '13, 12:43 p.m.

Yes, we need more granular control over component visibility that is distinct and separate from component ownership.l


Geoffrey Clemm commented Aug 07 '13, 2:26 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I understand (and agree with) the need to have more granular control over component visibility.  Could you explain why this is distinct/separate from component ownership?   The visibility, or read-access, to an RTC artifact is determined by its owner ... or stated otherwise, what would you use component ownership for, other than to determine access control for the component?

2 other answers



permanent link
Abraham Sweiss (2.4k1331) | answered Jul 30 '13, 7:18 p.m.
Hi Alexa,
Let me know if the following article provides the needed info
https://jazz.net/library/article/215

Comments
Alexa Nafke commented Jul 30 '13, 7:29 p.m.

Which part of this article do you think covers my use case?  I could not find a matching situation.


Abraham Sweiss commented Jul 30 '13, 7:44 p.m. | edited Aug 01 '13, 11:48 a.m.

The first part which describes how to use the ACL in RTC should get you headed in the right direction.


Alexa Nafke commented Jul 30 '13, 7:56 p.m.

I thought the access list was for the project as a whole, not individual components.  The only choices I see for components is "Team-private" or "project-scoped", neither of which will work to give more-than-one-but-less-than-all teams access.


Abraham Sweiss commented Jul 30 '13, 9:23 p.m. | edited Aug 01 '13, 11:49 a.m.

My mistake, I was under the impression when setting ACL on a component, the scoped option would allow to select from the available users / team areas. 

It looks like to get the permissions to work, each component would need to be moved to its own project area, add the teams to each project area and select scoped to limit visibility of the component to the project area it belongs to.


permanent link
Abraham Sweiss (2.4k1331) | answered Jul 31 '13, 8:46 a.m.
There is an existing enhancement which looks like it may add additional functionality to components and their permissions.  I would suggest subscribing and adding any suggestions if needed:
Make it easier to set the permissions on the component root (192716)


Comments
Geoffrey Clemm commented Aug 01 '13, 2:28 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I don't believe Make it easier to set the permissions on the component root (192716) is relevant here.   It is just a mechanism for defining access control on the root folder of the component, not for defining access control on the component as a whole.  I believe the relevant work item is Provide Access Groups in SCM (as already available for Work Item Access configuration) (249674) (or one of its related work items).

Your answer


Register or to post 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.