GSoC 2020: 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

@ibacher,

Concerning improvements in SMART OWA UI, can we add some little fields which would require some DB modifications ? That’s adding some little functionality which will need some alterations in the DB. Or it’s just required to improve the UI for existing functionalities ?

Oh Wow… This just answered the question I wanted to ask.

@mksd

My bad . I think I got you OAuth login module that will replace the login flow of openMRS.

Isn’t it worth trying moving forward with keycloack.

Easy to define set of roles for the platform. Easy checking the roles and give access. I think currently we are manually checking the user roles of the users. But it’s easy to decode the token and identify the role of a user so it will be a more generic way for the modules of openMRS.

It depends on the context. Yes if you’re integrating OpenMRS in an entreprise setup.

Careful. Because Spring Security is not implemented in OpenMRS, therefore you can not manage role assignments outside of OpenMRS. There’s limitations as to what can be done:

  1. You can create users with a mechanism that lets the authentication server provide the ‘seed roles’ when creating users. But that’s just for the user creation moment in OpenMRS.
  2. For already created users, roles must be managed within OpenMRS.

About 1, that’s almost implemented in OAuth 2 Login, look at this:

createUser(user, RandomStringUtils.random(100, true, true),
  Arrays.asList(new String[0]))

The last argument that you see now being provided as an empty list is meant to be a list of OpenMRS role names. The authentication provider could provide such list through a custom attribute of the ‘user info’. That was the plan when this was implemented and it was de-prioritised, but the last mile here is very easy to run.