---
title: ICAT Collaboration Meeting 30th May 2024
date: 2024-05-30
chair: Rolf
scribe: Louise & Patrick
---

## Attendance
Attendees:
- Rolf Krahl
- Salman Matalgah
- Louise Davies
- Kirsty Syder
- Malik Almohammad
- Patrick Austin
- Santhosh Anandarama
- Viktor Bozhinov
- Alan Kyffin
- Allan Pinto

## Agenda

## Site Updates

### SESAME

Past week finished cyber secyrity assessment. Trying to find weakness in SESAME, ICAT in particular. Report in one week, will share the ICAT section with the collaboration.

Starting writing the paper for NOBUGS.

Question about ICAT F2F: is there a time for this or will it be rescheduled this year
- LD: We discussed whether there will be enough attendence at NOBUGS for us to meet in effect there.
- RK: IIRC, some of us will meet in NOBUGS anyway. By definition, ICAT F2F. There is also a general metadata catalogue F2F. Don't know if there will be anything specific in addition to that.

See last month's collaboration meeting minutes for info

### HZB

Nothing to report.

### ISIS

Certificate update on dev machine. Faced a couple of issues with openssl and Java versions but now successful.

Work in progress for user office, complete in the next two to three weeks. Development and testing.

LD: Slight change in who manages ingestion for ISIS. Technically, who is responsible will change.

### DLS

Running a graduate project to prototype getting scientific metadata into ICAT. Previous project was focussed on MX, this will be more generic and look at more science domains.

### Sirius

Almost achieved first beamline generating first nexus file. Will then have data to ingest into ICAT. Hired collaborator to focus on ICAT fulltime. They are working on deploying some components of ICAT+. Already have icat.server, DBs etc. Trying to understand DataCite and other components of ICAT+. Expect to finish this by end of July. Once concluded, try and ingest nexus files.

## Component Updates

### icat.server

Last snapshot of icat.server (which made entity info static) shouldn't have had any breaking changes, but broke when working with python-icat. PR in for a reversion. Just need to test the fix on a test instance

Rolf: still a discussion on whether the exposed base entities were intentional
Alan: the removal of them was unintensional
Rolf: probably rarely used, Parameter one is probably most useful. If no compelling reason to remove, I'd like them to remain

Can probably close issue against python-icat

### ids.server

Markus working on refactoring code, making progress. Rolf noticed while reviewing method putAsPost (post variant of put call). Comment it was needed for TopCAT v1 (GWT version). So probably should remove. Does anyone use putAsPost? If no one wants it, will deprecate and remove it in ids v3

## AOB

### authn.oidc

Patrick: looked at oidc authenticator - who is using it? Rolf?
Rolf: not in production - plan to. HZB doesn't have proper ID management - there's currently a review on that but likely going to be SSO and thus OpenID connect protocol.
Patrick: come up in the context of DLS wanting ORCID login. ORCID has oidc support.
Rolf: have it running in test deployment and it works. You need to implement oidc protocol e.g. endpoint, and at end of protocol you get access token, authn.oidc just verifies access token.
Patrick: Need to think how it works with ORCID, either authn.oidc alone and program around it, or fork authn.oidc for our usecase
Rolf: 2 options, current authenticator & new ORCID one - will have problem with matching users, or have own identity provider for facility doing that matching
Alan: dunno if DLS user office has ORCIDs...
Rolf: would need to ensure DLS user office has same login as ICAT
Alan: frontend could use OAuth to get the user/ORCID
Patrick: primary motivation is for "open" users, side effect that existing DLS users can login via ORCID. DLS users expected to use their DLS login
Rolf: drawback is same user that has regular account who logs in with ORCID might have expectation to end up in the same account. Would have to communicate to users to login with their normal account not their ORCID account. authn.oidc - wouldn't need to populate user table, would work like authn.anon
Louise: it's a slightly more higher effort anon login, maybe with user tracking
Patrick: would need to think whether we could actually track users.
Rolf: logs would show the username, session id would also be associated

Rolf: you need something that speaks OIDC
Patrick: isn't that authn.oidc?
Rolf: no
Louise: you used apache oidc module? if I remember from last F2F meeting
Rolf: exactly, it's easy if you use apache, make a simple login endpoint/script

Rolf: happy to share/help with that

### NOBUGS

Rolf: Malik, have you had feedback on submission of your abstract?
Malik: no, on their website it said end of next month
Rolf: hadn't heard anything yet and was wondering, but seems it's just the schedule

### Next meeting

27th June - Rolf will not be available