Aww Gesh, I just don’t have the energy or typing skills to get into that debate.
yep, looked into a couple years ago. It has some potential. Bottom line for me, i’m somewhat content with assigning app tokens and secrets for the API’s. It’s user interface to support that needs to be done. At least, to move forward a smidge.
Thank you for moving this to a different topic. Something that needs to be worked on is the authentication of OpenEMR and I was planning to looking into getting Firebase Authentication API integrated since the MFA setup has a limitation of no way to recover if you lose the device used for it.
I’m assuming you’re running an App interfacing to our API’s or logging on for some purpose.
Would not Firebase be more for authenticating your app logon than openemr login?
I have been trying to replicate your integration from the previous post (GitHub branch), but I keep running into 500 errors. I had to clone the specific commit as well, since the latest version of the branch still gives the 500 error. Is this setup still running on your end?
We haven’t upgraded to current version. Will take a look in next couple of days.
Looks like this was a proposed solution but was never integrated into openemr. I don’t remember seeing this last year.
@mdsupport , was this reviewed by anybody. What was the outcome when you purposed. Whatever the case, from my quick once over, I think it could be integrated and still address some of my concerns.
I’d need to look closer but nicely done…
I actually tried to clone that branch and run it, but I think the 500 error was due to not importing the HybridAuth plugin, which I’m working on it right now.
Chances are the 500 was a result of a PHP error. Error log should tell…
Agree would be nice to refactor this into most recent codebase: src/Common/Auth/AuthUtils.php
Sorry, we did not include instructions from the code into the forum post. The commit is merely the integration layer between emr and hybridauth.
Some providers such as Google and Yahoo may use multiple protocols for their APIs and as naming convention we append the protocol’s name to the adapter’s
Follow instructions starting with Google steps that generate authentication related objects.
Rename template yaml file in config directory and replace/add items from prior step.
Hybridauth allows default callback urls as well as adapter specific callbacks. Regardless of your choice or adapter specific behaviour, after successful authentication Google needs to invoke login/hauth_check.php.
For successful passthru, we lookup either users.email or users.direct_email to locate one (and only one) emr user. Multiple hits are treated as no hits.
At the end, you should see login screen display small icon for each enabled adapter.
By clicking on ‘G’ icon, you will use your current Google session (and related email address) as emr login. Each auth provider controls various aspects of this process. For example, if you currently have no active session Google will offer login screen followed by prompt on your phone or whatever additional MFA you have set for your google account.
There is provision in the code for patients email as well to enable patient portal integration. But that branch does not take it further.
Okay, sorry I did see this soooo, the present is a new day to see if we can’t get this implemented/integrated. I suppose I could go ahead and do the integration if @mdsupport you don’t want to do the PR and/or you want to authorize me to use your work. I’d hate to see this opportunity pass by again!
@cyril How are you coming with your project?
@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.
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
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.
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?
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.
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.
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.
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!
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.
I can understand users pushback for 2FA but outside authentication does not actually add another layer of protection, it adds a layer of vulnerability