Abstract
The purpose of this project is to implement the OAuth2 support for the OpenMRS Webservices APIs. OAuth2 is welknown and popular standard in securing the webserives APIs where user can invoke services through access token without exposing their credentials. OpenMRS has two main web services projects which are OpenMRS restful web services module[5] and OpenMRS FHIR module[1]. So the main target is to implement the OAuth support for platform where OpenMRS act as a OAuth provider.
This requirement is mainly coming from OpenMRS FHIR module which OpenMRS has recently undertaken a commitment to implement FHIR in order to ensure better interoperability between healthcare systems. The OpenMRS FHIR module was developed as part of these efforts. Currently, there is need to support the OAuth2 for the FHIR Module.
Specification : https://tools.ietf.org/html/rfc6749
Requirements
- Good Java skills
- Familiarity with J2EE web programming (e.g., JSPs)
- Ability to learn and work with OpenMRS REST APIs and FHIR Module with HAPI
- Familiarity / willing to learn OAuth
- Soft skills to interact with the HAPI and FHIR community and OpenMRS community in order to gather requirements and technical feedback
Project champions
Objectives
- Go through the OAuth specification and understand OAuth2 and it's grant types
- Go through the available samples in web to understand the implementation(6).
- Develop OAuth based security module for OpenMRS
- Come up with set of UI mockups for application creation and authorization
- Create a new module following Creating Modules (improve the documentation if needed)
- Apply for a repository at https://github.com/openmrs and a JIRA project
- Create tickets in JIRA for tasks to be completed during GSoC
- Design and implement the module API layer
- API layer need to have a validateToken method which takes incoming token to check whether it's valid or not. The service will be a spring service where FHIR Module and Web Service module call to validate the incoming token.
- Design and implement the module OMOD layer
- OMOD layer should support for following endpoints (Twitter API tutorial will helpful in understanding below endpoints https://dev.twitter.com/oauth/overview). During the implementation we may simplify the endpoints
How FHIR and REST Module Interact

- Developing a client and demonstrating how different OAuth grant types can be support from the OAuth module
Discussion
Resources
- Work already completed under phase 01 of the FHIR module
- HL7 FHIR wiki
- OpenMRS FHIR GitHub Repo
- SMART enabled oauth
- OpenMRS REST Module
- http://blog.facilelogin.com/2012/08/wso2-oauth-20-playground-with-wso2.html
-
TRUNK-381
-
Getting issue details...
STATUS
24 Comments
Sashrika Waidyarathna
Hi,
I would like to discuss more about this project. I found two dead links, can you please fix these two.
Harsha Kumara
Hi Sashrika,
You first link is need to be corrected as you mentioned.
Second link seems down.
I'm happy to discuss with you on the project. Please contact me if you need any clarifications on this. Ask any question regarding the project.
Thanks,
Harsha
Sashrika Waidyarathna
Thanks Harsha,
So many things to get clarified
. First I'll ask some high level questions to get an understand about the project.
As a typical scenario, I think these are the tasks that we have to complete.
Is this the very general workflow that need to be implemented?
Harsha Kumara
Hi Sashrika,
The tasks and the workflow that you mentioned above is correct.
Basically we need to support for the all the grant types specified in the OAuth specification. Client should be able to get access token through any grant type.
Thanks,
Harsha
Sashrika Waidyarathna
Hi Harsha.
Why we allow any grant type? Is that because, for the time being, we going to allow any user with a valid access token?
Harsha Kumara
Hi Shashrika,
If we support OAuth2 specification, we need to support for all the grant types. Each of the grant type has their own pros and cons. For example Implicit grant more usable in front end javascript applications as it not require application key and secret. Also it's valid for certain time period. Likewise if we support OAuth2, we need to support all the grant types. But it shouldn't be a much effort if you can implement a one grant type.
If the token is valid, then there is no issue with accessing the APIs. Also we need to focus on OAuth2 scopes too and how we can adopt them to our implementation.
Thanks,
Harsha
Sashrika Waidyarathna
Harsha,
I added the rest web service module and tried to consume web services.
using http://localhost:8081/openmrs-standalone/ws/rest/conceptdatatype.
But it throwa a exception
Harsha Kumara
I'm not quite sure why you get this exception. Message indicate that resource doesn't exist. May be you can check underline OpenMRS version to check whether it's compatible with the REST module.
You can try FHIR module easily.
Sashrika Waidyarathna
Oops. That might be the case. It says that REST module recquires 1.9.0 or 1.8.1 to run. But i have 1.11.
Sashrika Waidyarathna
Harsha,
I went through thread about this project. https://groups.google.com/a/openmrs.org/forum/#!topic/dev/Pwy5YqMzH0A.
So what has been the final decision now? As per my knowledge, I believe there is no need of making openmrs.org a Oauth provider. because eventually what the end users going to consume is OpenMRS server web services. When that server instance is down, users will not be able to consume its web services. So if we can make OpenMRS server a Oauth provider by implementing an additional module, that seams enough. So there is no need of making openmrs.org a Oauth provider and worrying about its availability and security issues.
Because when the OpenMRS server is down end users cannot get an access token/authentication code nor use the web services. Base on that, I think there is no point in making openmrs.org a Oauth provider , just to add authentication to "OpenMRS web services".
What is your opinions?
Harsha Kumara
Hi Sashrika,
It's about providing OAuth login capabilities for openmrs.org. Which you login to jiras through your openmrs ID. So it's a separate thing.
. We though of adopting openmrs.org OAuth capabilities if it existed. So as reply suggest there is no OAuth provider implementation existed for openmrs.org.
Hope I'm clear to you
Thanks,
Harsha
Sashrika Waidyarathna
There i found some discussions about whether to make openmrs.org a Oauth provider or allowing external Oauth providers into the picture. Thats why I raised that concern
.
Any way i started to going through the OAuth2.0 specifications that you have posted here. Seems like it is a good document. Earlier i went through Google Oauth provider documentation. I'll get back to you after that.
Thanks!
Harsha Kumara
Great. Finally we come into conclusion that we need to be the OAuth provider
. So we need to get this module up to support FHIR and REST webservices to expose through OAuth2.
Sashrika Waidyarathna
Great! That was the doubt in my head. And I found an interesting thing in the RFC specification.
This is the thing what we now trying to do. Thing was i haven't seen such a system where the authorization server becomes the client as well
Harsha Kumara
Yeap client and authorization server are two different things. Client may be a js app, mobile app , sdk or any other client app. Requirement is to provide the OAuth2 support for exposed APIs of a OpenMRS server.
I think the RFC says. two things. What we going to do is becoming the both service provider and the resource provider same time. Some application uses other vendors like google, yahoo and etc as external OAuth provider so you need to have account on those vendors too.
Zakaria Amine
Hi Harsha,
I am interested in this project. I have worked with OAuth in some previous projects for accessing Google APIs, and I think it is a great mechanism of accessing resources from third party applications. I would like to discuss in more details the specifications of this project.
Regards,
Zakaria Amine
Harsha Kumara
Hi Zakaria,
You can contact me through harsz89@gmail.com. Also go through the OpenMRS guidelines on participating to GSoC. You will need to do couple of contributions to the platform.
Thanks,
Harsha
Zakaria Amine
Thanks. I will get back to you soon.
Zakaria
Sashrika Waidyarathna
Harsha,
1) IETF specification says, the access tokens should be transmitted though TLS. But AFAIK OpenMRS server doesn't implement TLS. So how we going to address this? Will we need to implement TLS in OpenMRS?
2) Shall I move this discussion to OpenMRS talk platoform? There we might be able to get the others opinions as well.
Thanks!
Harsha Kumara
TLS means that you should be able to request the token through htttps. So it's there
.
Sashrika Waidyarathna
Really, I am not aware of that
. Because i have only used OpenMRS using the standalone version and deploying the war file. There i never see HTTPS. I thought it only supports HTTP.
Harsha Kumara
Sure let's move the discussion to OpenMRS talk
.
Sashrika Waidyarathna
Ok, I'll start a new topic there.
user-c72cb
Hi Harsha,
I would like to contribute in this project. Is this project done?