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 and OpenMRS FHIR module. 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
- 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
- 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
- Work already completed under phase 01 of the FHIR module
- HL7 FHIR wiki
- OpenMRS FHIR GitHub Repo
- SMART enabled oauth
- OpenMRS REST Module
Getting issue details...
I would like to discuss more about this project. I found two dead links, can you please fix these two.
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.
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?
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.
Why we allow any grant type? Is that because, for the time being, we going to allow any user with a valid access token?
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.
I added the rest web service module and tried to consume web services.
But it throwa a exception
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.
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.
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?
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
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.
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.
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
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.
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.
You can contact me through firstname.lastname@example.org. Also go through the OpenMRS guidelines on participating to GSoC. You will need to do couple of contributions to the platform.
Thanks. I will get back to you soon.
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.
TLS means that you should be able to request the token through htttps. So it's there .
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.
Sure let's move the discussion to OpenMRS talk .
Ok, I'll start a new topic there.
I would like to contribute in this project. Is this project done?