Security Labels and Authorized Participants

[avillanueva]

So, slogging my way through this configuration. I've had security labels for some time but just basic export control ones. Following James Bailey at NASA, implementing labels for CUI. I have the following configuration:

It seems straight forward where you can specify a group based on the value for who can see items of a particular value when tagged. It does not appear you can specify a context role or group. An org or site level group would seem to be the only option then. So how would this work if say I wanted all Program Managers or System Engineers to access CUI data without having an agreement defined?

I get that the context access rights would be the first line of defense, so program manager A would not see CUI in the context of program manager B. But it appears you need to define globally a list of users who are authorized to see this type of data regardless of context but context access is the first filter. 

Looking at a custom Java Evaluator Class, this might be the solution:

isRestrictedBySecurityLabelValue (WTPrincipal principal, SecurityLabeled object, String label_name, String label_value)

From the SecurityLabeled object, I can get the context and check if the users is a member of a team role that I would allow by business rule. Seems like writing this might have solved my problem. I can see a very generic class that enables mapping via an external XML file.

[jbailey]

So there is supposedly a way to make it happen.  I haven't had a chance to dig deeper into it - been busy on other efforts. We have a use case where we would have a "Project Sensitive Data"  label (things like financial information, resource tracking etc).

I would be very interested to find out if you have this working (especially if by Liveworx, will I see you there?).

Jim

[avillanueva · Accepted solution]

Recommend folks read the securityLabelsConfiguration.dtd file. I fixed a bunch of issue by reading how the file should be structured. One thing that I picked up on is that for UnrestrictedPrincipal, you can only have one. This means if you specify a user, its one user. If its a group, its one group. If you use a custom class, its that one class. This does not appear to be support for multiple entries like two groups for example. For testing, I used Agreement Managers group and this might be the easiest solution. In order to create an agreement, the user needs to see the document which has the value. There is an intersection here. It also follows that Agreement Managers may not have access to all context areas so they would not be able to see or create agreements for data in those areas which is a good thing. 

However, this also means that if an Agreement Manager was also a guest in a context, they would be granted view access by default to that content and you may not want that. If my rule is that a role, program manager or others is by default an unrestricted principal, then I am forced into a custom evaluator class. To put it another way, unrestricted principal do not all need to be agreement managers but all agreement managers need to be unrestricted principals. You also need to have at least 1 person for each security label value unrestricted principal (phew) as an agreement manager. 

[jbailey]

That "feature" is documented in this case:
https://www.ptc.com/en/support/article/CS304529?source=search

This is pretty annoying, because their workaround assumes you are only using groups to restrict folks. With limited direct support from PTC on SL's, limitations on functionality... This should be a free feature instead of a paid license. 🙂 

[jbailey]

Also, PTC doesn't recommend agreements as a way to grant people long-term or permeant access.