GSoC 2020: Advancement of OAuth2 Module and Improvements in SMART OWA

Tags: #<Tag:0x00007fa3f64dcbb8>

Hi, I created this topic for those who have questions and worries concerning this Gsoc project idea. I have alot of worries. I hope it helps us all.

Hi @joachimjunior, I keep seeing the “OAuth2 module” popping up in conversations, but what does it do?

In particular how does it compare to OAuth 2 Login?

@dkayiwa, do you know?

@mksd I have some idea on this. So the OAuth2 module is for protecting the FHIR resources and exposing it to the SMART Apps after authorisation through the OAuth2 authorisation server.

https://wiki.openmrs.org/display/projects/Advancement+of+OAuth2+Module+and+Improvements+in+SMART+OWA

Thanks @sidvaish97.

And why not shielding all accesses to OpenMRS like OAuth 2 Login does?

Was there a need to segregate the invocations of FHIR resources from other application accesses?

@ibacher, would you know?

@mksd Yes so for the SMART Apps to be able to access the OpenMRS data its a requirement to have OAuth2 protecting the FHIR resources

Its a sort of standard for all EMR’s to have if they want the SMART Apps to be able to Plug and Play

What I’m saying is that OAuth 2 Login protects all resources, FHIR or not FHIR.

It currently supports multiple scopes (as seen here for example) and runs against Spring Security 2.3.5.RELEASE.

Maybe @ibacher can explain this better.

Hi @mskd, I think @sidvaish97 has said what i had in mind.

May @ibacher will help us with clarifications.

For the OATH2 module, i think it works alright. But the task ahead is is to upgrade the version to Spring Security OAuth2 2.x ensuring that the module works fine against latest OpenMRS release because currently the OAuth2 module works on Spring Security OAuth2 version 1.0.5.

I hope this helps :slightly_smiling_face: !

So, my idea here is to have a soft touch with what we are doing. It should be extensible enough to use OAuth2 to shield all accesses to OpenMRS resources (I mean, this is just a matter of changing the URL configuration).

There are also slightly different goals, I think. OAuth2 login, as I understand it, is for providing login using, e.g., Google or whatever instead of having OpenMRS responsible for authentication. With this project we’re actually trying to make OpenMRS act as an OAuth2 server (again, primarily so we can utilise SMART on FHIR in a single-server setup).

Does that clarify things a bit?

In other words, what we’re doing is somewhat orthogonal to to the OAuth2 login module.

Yes, if this module turns OpenMRS into an authentication provider, then it’s definitely a very different ball game. But I think the naming should reflect that. It should literally be named ‘OAuth 2 Server’ or something.

Why do that tho, is it because in this SMART setup OpenMRS (so the EMR) is supposedly where users are maintained and where roles are assigned to users?

On the other hand when it comes to systems integration, one should assume that there is already a centralised place where users are managed and roles are assigned (an Active Directory typically, or equivalent.)

You’re probably right about that; I didn’t name the module. In fact, given a choice, I’d probably call it “openmrs-module-smart”, because all of the OAuth2 stuff is really just incidental to being able to support SMART.

Yes, in as much as that’s the default configuration of OpenMRS and the pattern that used for many installations. It’s not my ideal state of things, however; I’d really prefer to have authentication handled by something like Keycloak or another OAuth2 provider, but my first target is to ensure we can launch SMART apps from within OpenMRS and this is the path of least resistance.

Indeed, I’d hope that was the case!

Why not using this module alongside OAuth 2 Login configured for Keycloak? Isn’t that getting you closer to the real end game?

1 Like

If this was completely new work, that would be the approach, but this is building on an already existing module. The real focus for this GSoC project is:

  1. Integrating the SMART on FHIR components with the FHIR2 module.
  2. Providing a better experience for registering and maintaining SMART applications.
  3. Providing a way to integrate SMART applications into the OpenMRS UI

Getting bogged down in setting up and configuring Keycloak or another provider distracts from those goals.

@ibacher Is it possible add scope for social media ids(facebook, gmail, twitter) to login the OpenMRS system. Hopefully SMART supports for this functionality as well. It helps health works no need remember separate password and also openMRS no need to maintain passwords.

That’s definitely outside of the scope of this project; however, the OAuth2Login mentioned by @mksd above already exists and supports this functionality, so I’d have a look at that.

@ibacher Oh its great to see we have keycloack. It’s already an Oauth server which can handle all oauth flows.

I think we can possibly use client secret auth flow which is provided by keycloack to expose fhir resources to SMART apps?.

Btw is oauth 2 login app mentioned @mksd does it works as a middle layer for keycloack?

How does it works all the users stored in openmrs user db stored in keycloack as well ?

There’s a pretty exhaustive README for that module, did you go through it? There’s also configuration guides to make it work with Google API and Keycloak.

I’m not sure what you mean by “middle layer” in this context. Keycloak is an authentication provider, if you decide to use OpenMRS with it, then OpenMRS must become a Keycloak client and should stop owning and performing the authentication process. ‘OAuth 2 Login’ turns OpenMRS into a client that authenticates with a provider over OAuth 2.

Yes, and there is no choice because OpenMRS does not fully support Spring Security.

1 Like