Creation of Authorization Rules on a new ICAT instance (v5.0.0)

[Allan Pinto]

Dear colleagues, 

 

I hope this message finds you all well. 

 

I have a new ICAT instance running up and I need to create authorizations rules and ingest them into this new instance. I wonder if there are some tools and documentation that help me to do this, please. I found this java code, https://github.com/icatproject-contrib/example-rules/blob/master/RulesManager.java but I am not sure if this can help me or how to use it. I am using the ICAT 5.0.0. I would appreciate it if someone could guide me on this issue, please. 
 
Thank you! 

 

Best, 

Allan Pinto 

[Rolf Krahl]

Dear Allan,

Am Mittwoch, 14. August 2024, 19:49:43 CEST schrieb Allan Pinto:
>
> I have a new ICAT instance running up and I need to create authorizations
> rules and ingest them into this new instance. I wonder if there are some
> tools and documentation that help me to do this, please.

Authorization in ICAT is a very broad subject that includes several
subtopics, including:

+ The semantics: how does authorization in ICAT work in general? How
do the rule system work? What kind of rules do you need for your
use case?

+ The syntax: how are the rules formulated?

+ The tooling: what tools can be used to create the rules in ICAT?

+ Best practices: what are the dos and don'ts?

Elaborating on each of these would go beyond of what I can esily do in
an email.

Also note that each facilities has their own requirements and we all
do things a little bit differently. There is no one size fits all
standard solution.


If you are looking for a concrete example, you might want to look at
the `init-icat.py` script [1] from the examples for python-icat. It
mimics the basic initialization of a new ICAT instance, including
populating the Rules table. The ideas behind the individual rules are
explained in the comments.

Actually, this script grew out of my own experimentation when I
started to setup ICAT for HZB. It has been converted to an example
script for python-icat later on and is also still be used in the
python-icat test suite.

But please use some common sense and ypur own critical judgement
before adopting these rules. They were based on my initial ideas,
when I started to design the authorization for HZB's ICAT, almost ten
years ago. Not all of the initial ideas turned out to be very useful
in practice. The rules in my production instance have been developed
further since then and I didn't bother to reflect all the changes in
the example script. For some of the rules in the example script, I
wouldn't formulate them the same way again today. I still have it on
my internal TODO list to review, document, and partly reformulate the
ruleset in HZB's production ICAT.


Please feel free to ask if you have any questions on the script or any
specific questions on authorization in ICAT in general.

> I found this java code,
> https://github.com/icatproject-contrib/example-rules/blob/master/RulesManager.java
> but I am not sure if this can help me or how to use it. I am using the ICAT
> 5.0.0.

This is a rather old piece of code, written by a very experienced ICAT
admin, Tom Griffin. It could still work in principle, since the ICAT
API didn't fundamentally change since then. But it is not complete in
itself, I assume, you would need to build it using the ICAT client
package [2]. E.g. you would need to create a maven project that
includes ICAT client as a dependency. I can't tell you anything more
than this, because I mostly use Python rather than Java at the client
side of ICAT myself.

HTH & Best regards,
Rolf


[1]: https://github.com/icatproject/python-icat/blob/develop/doc/examples/init-icat.py
[2]: https://repo.icatproject.org/site/icat/client/5.0.0/

--
Rolf Krahl <rolf....@helmholtz-berlin.de>
Helmholtz-Zentrum Berlin für Materialien und Energie (HZB)
Albert-Einstein-Str. 15, 12489 Berlin
Tel.: +49 30 8062 12122

[Alex de Maria]

Dear Allan,

As Rolf rightly says, each institute can have different rules depending on its needs. Nevertheless, in my experience, it's not uncommon for many rules to be the same across institutes. 

In any case, we can all agree that the rules are critical and need to be carefully defined since no one wants to make public data that shouldn't be. Fortunately, it's not something we need to modify often. 

At the ESRF, we basically copied the rules that were being used at ISIS around 2014 (provided by Tom G.), and since then, we've only needed to add a few more (most of them in order to support the techniques).

The way we ingest the rules is by using a script that is provided with icat.server (https://github.com/icatproject/icat.server/blob/master/src/main/scripts/rules.py). There are some advantages/disadvantages compared to python-icat but the result should be the same.

Example:

rules.py load http://icat:8080 db username ${ENV_ICAT_ROOT_USER} password ${ENV_ICAT_ROOT_PASSWORD} < /tmp/icat.server/ESRFrules.authz

ESRFrules.authz is the export of the rules by using the same script (rules.py). Our rules can be found here:

https://gitlab.esrf.fr/icat/icat-compose/-/blob/gitlab-runner/rules/ESRFrules.authz

This Dockerfile shows how the procedure is done step by step:

https://gitlab.esrf.fr/icat/icat-compose/-/blob/gitlab-runner/rules/Dockerfile?ref_type=heads#L29

I remember it took me some time to understand how to define rules, and this presentation from Tom Griffin helped me a lot:

https://icatproject.org/pdf/collaboration/communication/face-to-face-meetings/copenhagen-2016/rules.pdf

I think it would be great if we could share the same set of rules (or most of them). This would ensure the compatibility of the software developed on top of ICAT, as well as make it more efficient to detect and fix potential bugs in the rules.

Good luck and let us know if we can be of any help,

Cheers,

Alex

PS: let me know if you have no permission to gitlab.esrf.fr and I can grant you access in case you are interested

--
You received this message because you are subscribed to the Google Groups "icatgroup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to icatgroup+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/icatgroup/89dcbb7b-7ec2-4f39-a6e5-fbed43ace962n%40googlegroups.com.

[Allan Pinto]

Hi Folks,

Than you very much, Rolf and Alex, for sharing your experiences and these valuable information and links that certain will help us a lot here at Sirius. Giving more details of our current situation, we already defined our Data Policy which is under analysis by board of directors. I took a deep inspiration on PANOSC Data Policy Framework and we made some adjustments taking into consideration our infrastructure. 

As we are hurring to get ICAT in production mode for people using it, I have decided to keep the all comming data as embargoed for now. I think that is not be a problem because we will have a very few data coming to ICAT in the next couple of months as the Sirius is undergoing a long maintenance period to receive a new superconducting radiofrequency cavity. When our Data Policy is approved, I will then formulate the rules and ingest them into our ICAT instance as suggested by you. At this moment, I am preparing myself to do that by understanding the whys and hows. That is the reason why I reached you out. I will carefull study all material that you pointed out and I will let you know If I have any question.

Thank you!

Cheers,

Allan Pinto

PS. I have access to the ESRF's GitLab Alex. Thanks a lot ;-)!