Hello,

What kind of security and permissions configurations were you looking to store outside of the database?

Regards,

Jon

For instance, on the "Study Permissions" page you can export an XML of the permissions you have set in the GUI. You can also import an XML file that will set the permissions. We would like to set this up so that it does not go through the GUI, but rather at boot or build.

So, to answer your question, any kind: study level, folder level, dataset level, etc. Perhaps even group definitions and user roles.

Thanks,

Ariel

Hi Ariel,

I'm afraid we are going to need more details as to what you're doing in order to give you the best answer here. We need to know the full scenario. Otherwise, it is difficult to give you the correct answer without understanding what you want to do and why.

Within LabKey, permissions are setup on a per-container basis. Having permissions setup at build time the moment the server gets installed with LabKey is unusual since when a server gets installed, no containers exist beyond the default Home container/project.

Are you looking to have permissions cleared out and reset when the server restarts again based on some pre-defined permissions that were placed in some XML file? What is the purpose of having the need to have your version of LabKey automatically build permissions the instant that it installs or starts up?

Please provide us with as much detail as possible with what you're working on here and what challenges you're facing to where you feel that this option is the way to go. I believe once we're on the same page and we understand the full scope of what you're working on, we can give you the best information possible.

Regards,

Jon

Hi Jon,

I appreciate you clarifying the information you need to answer the question. I'll do my best to explain. The overarching concern is to be able to create reproducible, easily deployable environments, but not necessarily identical data. For instance, a different instance of an identical environment would not have the same users, or data, but would ideally have the exact same roles and groups defined, as well as the permissions they have on particular tables, views, wikis, graphs and other elements.

Based on LK documentation, the admin usually sets permission through the GUI interface. However, you can export the definitions in an XML file. You can also import an XML file. One way to create reproducibility would be to document a series of steps to reproduce the series of steps, boxes filled out, buttons clicked etc. to reproduce a certain setup. Another would be to export the permissions from a model installation, and import those permissions into the others.

We are trying to set up a working practice to minimize configuration steps done through the GUI. Rather we want to have as much as possible in the versioned code base. For instance, we are not creating any tables or lists through the GUI. That all takes place on build. Many of our static pages, views, graphs etc. are also defined in the code base rather than the GUI.

In a similar way, we would like to have the following setup:
1) There is a file *somewhere* in the code base called "roles.xml" or "roles.sql" if it is a query. This would define the roles at build.
2) There is a file *somewhere* in the code base called "groups.xml" or "groups.sql" if it is a query. This would define the groups and their roles at build.
3) There is a file *somewhere* in the code base called "permissions.xml" or "permissions.sql" if it is a query.
4) This last document would define the permissions the various roles and groups have on tables, views, pages etc. These tables and views are already defined at build time. So there will be a hook for the permissions at build.
5) These documents would be versioned in the git repository for our module. We can clone our module into any LK install, and all of these roles, groups and permissions will be identically set along with the tables, views, pages, graphs and other elements that are defined in our code base.

I hope this is a better explanation. Please let me clarify any points if they are still cloudy.

Thanks much,

Ariel

Hi Ariel,

Thank you for the additional details. So what about the structure of your LabKey instance? Even though you stated that the users and the data wouldn't be the same, but the roles and groups would be in addition to particular tables, wikis, etc. Is the project/folder structure going to always be the same every time?

For example, let's say that you built your current instance with three projects. The first project has 3 sub-folders, the second project has 5 sub-folders and within each of those sub-folders, there are anywhere from one-to-ten folders, and the final project has only one sub-folder.

Is it expected that these folders and projects will always be consistent to where if you installed your version of Labkey on a fresh box, it's going to automatically create those exact folders in that exact structure as well as a default?

Regards,

Jon

We would like to establish a continuous integration process and repeatedly and reliably propagate our implementation of LabKey features to various environments (like Dev, QA, and Production).

Is there a way for us to store permission assignments to objects (user group to object) in a file that we can place in source control and then release to various environments?
 
Developers work in their local environments on a feature/task until they are complete. This will include creating new LabKey tables, setting up views and reports. Part of this entails assigning permissions to various groups against these objects. For example, a developer may create a new report that is only available to lab-technicians. When the development is complete, the developer pushes their changes to our source control repository. Where would a developer store their permission assignments so that they can check it into source control?
 
Periodically, a QA build is pushed from source control encompassing all of the changes that need to be reviewed by the customer.
 
Eventually, we will release features into production, along with the permission assignments (user group to object).

Hi Ariel,

Aside from the folder import/export mechanism, we don't currently have a mechanism to automate the transfer of permissions like this.

However, it would be possible to build a tool that could manage this from an XML or other resource using client APIs like those on LABKEY.Security, including getSecurableResources(), getPolicy(), and savePolicy():

https://www.labkey.org/download/clientapi_docs/javascript-api/symbols/LABKEY.Security.html

Your own modules could use an approach like this based on an administrator hitting a certain page on the server, or run automatically server-side Java code as part of the module upgrade process.

Thanks,
Josh

Hi Josh,

Thanks for clarifying the current capability. We are considering the idea of writing our own code to perform this task.

Ariel