Wiki Spaces
Documentation
Projects
Resources
Get Help from Others
Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
Primary mentor | |
Backup mentor | Harsha Kumara, Suranga Kasthurirathne |
Assigned to | Sanatt Abrol |
Interested People | Pascal Brandt |
The initial work on OpenMRS OAuth module has carried out in the Implement the OAuth2 Support for Web Services APIs during the previous GSoC. The objective of this project is to migrate existing module to latest OpenMRS 2.x release and make all the OAuth grant type to work. This functionality should be demonstrated with the FHIR module. The new release also opens door to using higher versions of Spring Security OAuth2 project with the module which needs to be explored. Another major goal is to make FHIR module work with SMART applications which needs OAuth2 Authorization code grant type based authentication. So the plan is to improve our OAuth module to implement this capability and do required enhancements. Note on current state of module : The OAuth2 module is currently configured to implement all grant types specified by the OAuth2 protocol. The module utilizes the Spring Security OAuth2 project and runs on OpenMRS 1.11.4 (max) due to restrictions of underlying API's that are incompatible with higher OpenMRS versions. We are mid-way migrating to a complete RESTful interaction between the front-end and back-end ( It is easier to make REST calls using JavaScript to fetch back-end data and render it rather than implementing custom spring data binders for current data structures used in the module). This also falls in line with the OpenMRS 2.x migration objective and is backward compatible with older versions of OpenMRS. To test the module, you can leverage OMODBypassController to register sample clients and generate client credentials while the UI-based client management functionality is made RESTful.
Mayank Sharma Harsha Kumara Suranga Kasthurirathne
Goals
What - Make the OAuth2 module more easily accessible to the implementers and developers in our community.
Why - As we have already moved to a REST based model with the Platform 2.x and Reference Application, the OAuth2 module needs to catch up.
How -
Add new REST endpoints : The module is currently configured via JSP pages embedded with server side code. In order to develop various clients/ applications that seek authentication via OAuth2 module, the registration process for such applications should be possible via REST endpoints. (for instance Android/iOS apps, OWA's etc should be able to register and interact with the OAuth2 module in a pure RESTful manner). Therefore, it is required to introduce REST endpoints OAuth2 module allow for Client Registration, Editing of client credentials and other miscellaneous configurations that are currently being done via the LegacyUI.
Upgrade Dependencies : The OAuth2 module is currently using Spring Security and Spring Security OAuth2 v1. It works only for Platform 1.11.4 or less and hadn't been upgraded to work with higher versions. As we have moved to Java8, Spring 4.x, Hibernate 4.x with the Platform 2.0 release, the OAuth2 module needs to be migrated to the latest tech stack. Please refer to Platform Release Notes 2.0.0#ModuleDevelopers to learn more about the migration process related to OpenMRS Platform. See [5] and [6] as well.
Role and Permissions: At present, any OpenMRS user can register as a Client Developer. A new OpenMRS Role with relevant Permissions needs to be registered during module installation. These roles and permissions have to utilized during Client Registration (for instance, only Client Developers should be able to register clients; Only admins should be able to see list of all clients; Only)
Switch to Annotations where possible: Annotation based configuration is more common in the new spring security releases as compared to their xml counterpart. They are easier to understand. At present Spring Security and Spring Security OAuth2 are configured purely via xml. We need to identify places where it would make sense to switch to Annotations instead.
Use-case implementation: Identify and Implement use-cases for different grant types. For instance, a basic SMART app can demonstrate using the OAuth2 module's Authorization Code Grant Type besides the interaction between OAuth2 and FHIR modules. Similarly, OWA module based app can demonstrate OAuth2 module's Implicit grant type while the OpenMRS Android Client can exploit the Resource Owner Password Credentials use case.
Expected Deliverables
An OpenMRS OWA demonstrating the implicit grant type flow (Bonus Karma points, if time permits)
Sounds Interesting? Here's how you can get started
Additional Tips for Proposal
While not mandatory at all, it would be great help if you include the following in your proposals:
Requirements