New user logging system for Scout @Solna

[northwestwitch]

Our current system (gmail with clinicalgenomics.se domain, in place to make use of the 2FA) is very expensive, so we should switch to another logging system (LDAP, ..?). At the same time we should keep in mind that all the scout event logging works with user emails, so we should probably make changes to the events collection if we are going to modify the email associated to each user.

A very good solution would be one that maintains the emails as they are. Perhaps LDAP could work in this sense!

[dnil]

Is this now a legacy system, or is it still in use for the clinic but not research? I have seen emails from prod requesting new users to register their work email for a free Google OAuth2 identifier. That is both "free" and and keeps backwards compatibility.

It is tempting to use the hospital LDAP, but that would not work for the research users. But we could naturally host a small LDAP (or OAuth2 I suppose, though less pressing) of our own for our users. Ideally this would be combined with a reverse proxy side dynamic passthrough (envoy?) so we could be rid of the static IP address filter.

[dnil]

It's a standard IT component - should be possible to get some good support with that if need be! 😁

The reverse proxy access gating is less standard I suppose; last time I checked envoy was the realistic option, but it does seem nginx has something similar now. https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-subrequest-authentication/. I have no idea how good/hardened it is - we should pass that on to some real IT person...

[dnil]

Is this now a legacy system, or is it still in use for the clinic but not research? I have seen emails from prod requesting new users to register their work email for a free Google OAuth2 identifier. That is both "free" and and keeps backwards compatibility.

I was not present when the solution was decided on, but from what I've heard we chose it to have full control over the accounts used by the clinicians and to enforce 2FA on all these accounts. I don't think we let anyone register with their work email. I'll ask prod, and maybe you can have a look in the collection if there are any non-clinicalgenomics emails?

They are not that well used at least. There are some for UDNI cust163 that I was involved in (all are effectively closed), but also other external/research (like cust042) and perhaps a single region email left (cust144).

[dnil]

But like @northwestwitch says, they are not LDAP, but "private" OAuth2 registration using an email held by their employer.

[karlnyr]

I would never ask users to use any other email other than the "clinicalgenomics.se" one. The reason why such a question arose earlier was the presence of users with a "gmail.com" address. However, production did not add these users. This is also a pressing issue, as we gain more and more users, and the "purge" I did last time will soon be needed again if not new solution is found.

[dnil]

Sounds great @karlnyr - that was probably older and most likely purged addresses already. I'll check back with the UDP ppl at some point regarding cust163: it is hardly urgent, but their external users will not be coming back anytime soon. The next hackathon has already happened in Nijmegen, and even if they return here, it will be with other users. I dont think I'm guilty of cust042 and cust144 - they may be leftover from an interim procedure that were active during the last purge?

[Vince-janv]

My initial idea was this:
If we're using the clinicalgenomics.se google solution solely for enforcing 2FA, then we could simple implement a 2FA library (like pyotp) and let them use their own emails (has to be nicer for them right?)

As you mention this would imply asking each user to provide their email and go through the collection to change them. This seems like a pretty non-invasive solution, but would require some coordination.

What do you think?

[dnil]

And easily allow setting contacts to external services like ClinVar and MatchMaker.

[dnil]

@Vince-janv To investigate other options, would an own LDAP for "CG customers" with 2FA be an option? Scout would already have support for that and we could focus on migration.

[Vince-janv]

Great suggestions. I'll need to look into each of them. To me LDAP is quite a big service that might be overkill for just authenticating to scout.

There is also the looming hospital merge to consider. The SITHS-system could then be used for logging into the clinical instance of scout. But we would still need a sign-in method for research. This is a bit into the future though

[dnil]

Precisely; we have been saying the same thing a few times around (and also considered sharing auth from the hospital before the merger plans) but never found a good solution to sharing research. LDAP doesn't have to be a big thing, but it certainly can be a huge system. No pre-study objections to brewing our own with pyOTP or similar - it might be easier and just as safe - I just don't know it!

[Vince-janv]

Will read-up and sleep on it before taking any decisions 😁

[northwestwitch]

Do we need 2FA if we have LDAP? Isn't LDAP auth + Scout DB auth enough?

[dnil]

Nah, we should have 2FA; usually we would have it with a card reader connected to LDAP in the hospital setting. But it could be the regular phone authenticator RSA shared-secret as well.

[northwestwitch]

Hello again. I found this tool and it seems pretty solid: https://github.com/authelia/authelia. Should work nicely as a service with podman and it has a nice web interface. I'll try to set up a demo in the coming weeks