Authentication Improvements

OpenEMR Development
#21

@sjpadgett, Sure. That commit was PoC which worked well enough for our immediate list of auth providers. But from little experience we gained, there are subtle variations implemented by each - OAuth2 of Google and Facebook are same at protocol level but setup and operational options are quite different. As such idea was to replace hardcoded patch to auth.inc by a wrapper class that can process a token issued by trusted external provider and grant access. Perhaps you can unify FHIR and login based on a single method? I should also note PR#2440 was related to this to enhance log entries as we would want to be aware and in some cases have option to act on use of this alternate access method.

Finally, the big picture is this will be the building block for integration beyond login. Once the plumbing for external networks is available, various products by multiple services are available to the application.

PS:
To be clear, feel free to do whatever. We do have a module based version working except for auth piece. But I would not want to rock the boat for this.

1 Like
#22

Iā€™m looking at the branch you had committed, did you make any changes to make it work with the latest version of OpenEMR? Iā€™ve been trying to copy it from there to the latest version but I get a blank page and mod_fcgid: stderr: PHP Parse error: syntax error, unexpected end of file in /public_html/interface/login/login.php on line 417

#23

Are you applying patch on top of current version? The branch should work by itself but then you would be several features behind. The branch affected standard login.php and auth.inc. You could try replacing login.php and auth.inc but no confidence that it will work due to encryption changes. We have assigned someone to move this from PoC to module.
At the risk of offering redundant caution to all experts, this will never be a single checkbox based option. Each installation will need to establish trust with every needed provider and enable desired options offered by that provider before any tokens are issued. But having gone through some setups, we feel this to be as good if not better alternative to in-built authentication.

#24

I was trying to incorporate the changes to the current version. Tedious work though. Iā€™ll try to download the branch itself. I noticed there are some db references in login.php in the changes you made, donā€™t I have to do the db creation as well to make hybridauth work?

#25

A little late to this conversation but still want to chime in. It t seems the thread went from ā€œShould we have a discussion about doing 3rd party authenticationā€ to ā€œhow are we implementing 3rd party authenticationā€

I, for one, am completely with @sjpadgett on this one, introducing 3rd party auth into the codebase opens up so much unnecessary potential risk. There is no good reason any practice needs to use their Facebook login credentials to access an EMR.

I think we should squash this idea and not allow this kind of insecurity. Phishing attacks are already big issues in healthtech, could you imagine if I could gain access to your FB account and because of that get into patient records? Thatā€™s an attack vector we should not offer.

#26

Actually @robert.down you are not too late. Hereā€™s my take on this about 3rd party authorizations. Right now apart from the password based authentication OpenEMR supports MFA (2FA). I have no issues with it, but some doctors donā€™t like it since there is no way to gain access to the OpenEMR if they 1. loose the password or 2. 2FA device. This is why Iā€™m looking for adding Google account authentication as another layer of protection.

#27

The design called for an entry in the log so we can periodically scan the log and alert user about account activity. There were no db updates as existing column was used (currently open PR#2440). That thing has not gone anywhere so if you are retrofitting, you can drop all logging related code. Our revised design will now leave standard log unaffected to minimize change footprint.

#28

Hi all. Iā€™m so glad we are having this discussion.

@cyril, Perhaps a fingerprint could be added to Rodā€™s MFA.

Still, I agee, we should sideline any authentication where authorization does not occur within openemr domain.

I still have to come to terms with how we want to authorize and authenticate applications interfacing to openemr.

For direct API we currently auth based on user and that users allowed permissions. This presents several issues namely, users releasing their credential for perhaps application access. Currently we only support users and while an admin could piggyback Users by creating a specific user to authorize an application access, this seems flaky.(of course iā€™d prob do it that way then:))

I donā€™t need to go through all the downfalls of our current mechanism but, will outline an approach from our API POV.

Today we use the password grant type with the only scope requirement being site id and sending back a temporary token for the session. Imo, we should be assigning a dedicated application/api token with a secret generated from a one time key. Username and password would still be used to authorize the token and secret.

This leads us to how to manage the scheme. I believe @mdsupport had suggested consolidating all our users whether patient(portal), provider(user) and now API and applications into one resource by assigning roles i.e patient, user, api and so forth. ACL already provides a very good mechanism for managing permissions where we just expand a bit. Iā€™m thinking from an administrative pov, this is an excellent idea.

We then leverage our current Users UI by presenting the correct form necessary to handle generating the specific auth requirements. Easy peasy, right!:slight_smile:

For the auth flow requirements we would follow the specific OAuth pattern for auth type ie password, client etc grant types based on the requested auth realm. Returned allowed scopes would then be based on the requested scopes and the ACL allowed scopes.

Another role type, server, becomes important for server to server interop where we will need to record the distant servers auth requirements and specific tokens and passwords. At minimum, this removes all the globals necessary to document such things. Think FHIR, labs, procedures and exports to distant clinics or institutions. All these UIā€™s could be consolidated into one place.
I still like the idea of developing our own authorization server to handle all these various schemes along with allowing a three legged oauth that is only authorized by our own auth server.

Just some thoughts.

1 Like
#29

I can understand users pushback for 2FA but outside authentication does not actually add another layer of protection, it adds a layer of vulnerability

1 Like