Create 20240530-meeting.md

content/collaboration/communication/monthly-meetings/2024-meetings/20240530-meeting.md

@@ -0,0 +1,108 @@
+---
+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 getting nervous, but seems it's just the schedule
+
+### Next meeting
+
+27th June - Rolf will not be available

content/collaboration/communication/monthly-meetings/2024-meetings/index.md

@@ -11,3 +11,5 @@ title: 2024 Meetings
 [28th March 2024](/collaboration/communication/monthly-meetings/2024-meetings/20240328-meeting)
 
 [25th April 2024](/collaboration/communication/monthly-meetings/2024-meetings/20240425-meeting)
+
+[30th May 2024](/collaboration/communication/monthly-meetings/2024-meetings/20240530-meeting)