This user's guide aims to provide a basic resource for understanding and operating the Lattice Manager and Lattice Security through MRALD.
A deep technical explanation will be avoided in this document, as the aim of this is to give a broad understanding, of how to use and operate the lattice security using tools supplied with the MRALD system.
For a more in-depth
discussion about Lattice security, please refer to the following
paper .
A COI is a group of people that have a common interest and trusted sharing relationship. A COI can be as small as two researchers collaborating together, or encompass a whole organization with a common goal, such as the Human Brain Project (HBP). A COI that has x member organizations.
The COI is extremely useful for stating sharing policy, because it is a natural granularity for sharing actions. In the internet age, it would be painful to declare access privileges for each and every user individually, and the default of ?all or nothing? (i.e., global access or full privacy) is unappealing as well. Using predefined COIs, however, it is possible to share data with a lab of 20 people in a single action.
For data sharing we define a structured sharing communities (SSC) model that formalizes how data can be shared using the COIs. An example of this structured sharing model, otherwise called a sharing lattice, is shown in Figure 1.
The highest COIs are the most private, least risky. However, these enable the least sharing, while the lowest COIs are the most public, most risky, and enable the broadest scope of sharing. Intermediate COIs offer data owners a particular balance between the benefits and risks of sharing. Over time (e.g., with publication), data can be shared more widely by simply reassigning it to a lower COI.
In the structured sharing communities SSC model, two COIs can be related by a downward arrow, denoting a sharing relationship. Specifically: the higher COI, can share data into the lower COI, and can access the data in the lower COI as well. Thus, in the lattice of six related COIs in Figure 1, the data in any lab's COI is visible only to the members of that lab. When Lab A and Lab B share collaborative data downward into Collab-AB, it becomes visible to both A and B, but not to C. Any data in the Research Group 1 COI is visible to all three labs, but not to the general public (e.g., anyone on the Internet). Finally, Public COI data is visible without restriction.
Each piece of data can have one or many COI's assigned to it. The exposure of the data is determined by the sharing relationships that currently exist, and the level of COI that is assigned to the data. Each user is also assigned to one or many COI's. The data that they have permission to view is dependent upon the existing sharing relationships of their assigned COI, and the data that is viewable by these COI.
The Lattice structure provides a visual representation of the structured policy. It displays sharing relationships, using an intuitive visual representation, that closely represents how people actually conceptualize the sharing of data.
A typical Lattice Structure is shown below:
When a person, such as Administrator, looks at the Lattice Structure, it will initially look like this:
There is one node, representing the Public domain. This would represent publically accessible data, such as Census data.
The Admin, belonging to Lab A, starts by creating a node representing his group. He does this by clicking the 'Add' button, shown, and selecting 'Lab' from the Node type.
He enters the name of his group, Lab A, in the Specify Name box. This name should uniquely represent his group with his community. He clicks on 'Create Graph' which will generate a new visual representation of his sharing relationships. This produces a graph as shown.
He assigns himself to this group through the 'Manage People' form. By updating the form as shown.
On returning to the Lattice Manager, the top right hand corner, now shows the community to which the Administrator belongs, which is Lab A, in this case.
He knows that Lab A has current sharing relationships with Lab B, Lab C and Lab D.And therefore creates the nodes corresponding to each of these groups, in exactly the same way that he created Lab A.On clicking the 'Generate Graph' the resulting graph is shown:
Each of these groups are referred to as a Community of Interest, or COI.He has two existing collaborations, one with three members, Lab A, Lab B and Lab C, and so creates a new node called 'Collab 1'. He selects 'Colab' from the type of node, as this node represents multiple groups.He wishes to show that Lab A, Lab B, and Lab C all belong to this group, and so selects 'Add Parents' check box, for each of these groups as shown.
On clicking the 'Generate Graph' he now sees the relationships are visualized as shown.
He also has a sharing relationship with Lab D, which Lab's A and b are not a part of. So he creates another collaboration 'Collab 2' that only had Lab A and Lab D as members. At this point he has created the lattice for all his sharing communities.
However, he wants to also share data to a wider community, that his group is a member of, and that has many members.This wider group, Org X, is an organization that all Lab's A,B,C and D are a member of.So he represents this by creating the Organization Org X, in the same way that he created the collaborations, except the node type is set to Organization.
Note: The node type is always denoted by the color of the node. The color assigned to each node type is listed along the bottom of the graph.
To make Lab A,B, and C a member of Org X, he now has two choices, he can make the collaboration 1 a member or, make his individual Lab a member of Org X. This will depend on how he wishes to share data.In this case, he specifies that the Collaborations, Collab 1 and Collab2, will be members of the Organization.
The lattice now looks like this.
This effectively represents all the groups sharing relationships.
At this point, we have a Lattice Structure. But so far the existing data is not set up to take advantage of this security. The data in the system, needs to be associated with this structure, or else the security model will not work.To associate the data with the Lattice structure, the first step is to identify, which tables you wish to have follow the Lattice Security model.
All table have the option of being open, or following the Lattice Security model. It is not always necessary or even desirable to have all tables follow this security model. For example, it would not be worthwhile to have security on a table containing US States.
Once the tables are identified as being part of the security model, the next step is to notify the system of this security intent. In the following example, this simple step is carried out by having the administrator click on the 'Add Labelling to Table' link on the Administrator Tab.
The following page appears:
To select a table for security, the administrator merely need to select the check box beside the listed table. And select Proceed.The success page will notify the administrator of the tables being successfully incorporated into the security model. An explanation of how this happens, it outside the scope of this document. All the data is now within the security model. Each row of data in each of the tables will automatically be labeled with a security label.In this case the system will default to the COI that the administrator is assigned to. Therefore in this example, all data will be labeled with the Lab A label.
In order to be able to reassign the visibility of data, the user needs to change the COI. To facilitate this the User can build a form that specifically allows him to access the pertinent data and reassign the associated COI. The administrator builds a form using the special Create Data Labeller Form link on the admin tag. For more details on Form Builder functionality please refer to the following Form Builder Help
He follows the same procedure for building a standard form in MRALD. For details please refer to. It is important to note that only tables that have been set up for Data Labelling security can access this functionality. Once the form has been created he can access this form through Personal forms. It is recommended that an experienced user, such as the Administrator pre build these forms and make them accessible by providing a link on the main page. On clicking the link to the Form, in this example Label Subjects, the following page appears.
This page is exactly the same as a normal MRALD form, with the addition that Set Label, is an option for output. Highlighted in the figure above. On selecting this option, and filtering the data approprately using the normal Filter options on the form the user will be presented with the following form.
Only the data that the user has ownership of, will appear. This ensures that only the owner of a particular dataset can change who has access to that data. The user refines the dataset, using the checkboxes on the right hand side, to that which he wishes to change access. The user then selects from the drop down list, to select the appropraite COI that he wishes to assign to the data. Once he selects 'Set Label' all data marked with a checkbox, will now be accessible to anyone with access to the corresponding COI. In this case the User has selected 'Stroke' so that all users with access to the particular COI will be able to view this data.
Once the data is set up with security labels, the people using the system also have to be assigned a COI to which they belong. The administrator knows that three researchers will be using the system.
Two of the researchers belong to Lab A, but one does not belong to his institution, and is a member of Lab B.
He therefore assigns the two researchers in Lab A, to Lab A. He does this by having the researchers register themselves to the system. Once they are successfully registered, the administrator accesses the People Manager form. He retrieves all the data about both researchers, and click on the Update beside each one.
The following page appears.
Note: Only a person with administrative rights is able to access this form. A person without Administrative privileges, will only see a page informing them that they do not have the sufficient rights to access the page.
The administrator changes the group that the User is assigned to by, selecting the relevant COI from the drop down listed beside “User COI”.In this case he assigns the two researchers to Lab A by selecting Lab A from the drop down list.
On clicking Update, he is informed that the update has completed successfully.The third researcher he assigns, in the same way, to Lab B.The researchers are notified that they are now assigned to the right COI, and can now safely enter data.
Researcher B has been working with one of the researchers in Lab A for 2 years, and as a result has accumulated 100 images that he wishes to upload into the system. He loads the data into the system using the appropriate forms. The data will be loaded with his COI. In this case Lab B. At this point the other researcher, in Lab A, will still be unable to see those images, as they are assigned to Lab B. When the Lab A researcher looks for the images at this point, he will not see any data there.
The researcher from Lab B, goes to the appropriate form, in this case Update Volume Labels, and retrieves all the data that he has uploaded. In the 'Output Formats' option at the bottom, he selects 'Label Data'.The following page appears. He can see a listing of all the data he has loaded, along with a list of the labels assigned to this data. He wishes to relabel them to Collab 1 (which both Lab A and B are a member of). Which he does by clicking on the Select All, and selecting Colab 1 from the drop down list box at the bottom.
He then presses Proceed. A page appears notifying him of the successful update of the security labels.The researcher in Lab A, now goes back to the system, and without taking any action, can now see all the data that has been assigned to Colab1. He now has access to all 100 images.He then enters in 100 images that he has accumulated through a different research project, and leaves the labels set to Lab A. (As the data is defaulted in the system to the have the same security as the User entering the data).
He can now see all 200 images, in the system, and the researcher from Lab B, can see 100.At this point researchers from Lab C and D register to the system. The administrator receives a message, automatically generated, that two researchers wish to join the system. He merely assigns them to the appropriate COI, and sends them a message notifying them of this.
Researchers from C and D both enter in 100 images each. The researcher from Lab C relabels 50 of them to Colab1, and leaves the rest with label Lab C.As he is a member of Colab1, he can also see the 100 images that the researcher from Lab B entered earlier. So researcher from Lab C can see the 200 images, the 100 images he entered, plus the 100 entered earlier by the researcher from Lab B.The researcher from Lab B, now sees that he can see 150 images, the 100 he entered plus the 50 entered from the researcher from Lab C.The researcher from Lab A can see 250 images. The 100 he entered and the 150 entered by both the other researchers.
Lab D enters his own 100 images and keeps them assigned to his home COI, Lab D. At this point there are 400 images in the system, that each of the researchers can see a different subset of , dependent upon the security assigned to them, and the security assigned to the data.
The researcher from Lab A does further research with Lab D and loads in the associated 50 images, that he assigns to Colab 2. Lab D can now see his 100 images plus the 50 entered by researcher from Lab A. The researchers in Colab 2, after futher research, decide to publish their results to the restricted community, Org X. The researcher from Lab A, reassigns the data to Org X. Now both researchers from B and C, can access these images. This allows for them to look at the results and provide further insights.
After a year, the researchers from A and D decide to write a paper and make a subset of their images accessible to the public. They reassign 25 of these images to the Public COI.
Now 'casual' users, that just have public access to the system, can see these 25 images in the database, without being assigned a COI.
This shows that over time the data becomes more and more public, and is seen by more people, but at all times the owners of the data are in complete control over who has access to their data.