We plan to release the OAuth2 module against openmrs-core 1.10 which runs on Spring 3.0.5.RELEASE.Spring Security OAuth is an active project under the spring foundation and provides out of the box API for implementing OAuth2 Authorization Server and Token Management.
The first stable release of Spring Security OAuth project (1.0.0.RELEASE) depends upon Spring 3.1.2.RELEASE.
For the mid-term presentation for the OAuth2 module, I managed to run an external OAuth2 authorization server based on [spring-security-oauth][1] using Spring 3.1.1.RELEASE.
Unfortunately, downgrading the spring version further to 3.0.5.RELEASE in the spring-security-oauth2 based project leads to build failure.
That’s because class [RequestMappingHandlerMapping][2] is missing since it was introduced in Spring 3.1 and it is used by the spring-security-oauth 1.0.0.RELEASE
As a result, integrating spring-security-oauth project into the OAuth2 module fails. I have tried a few futile permutations such as making the module depend on spring 3.1.1.RELEASE (module build and gets installed properly but handler mappings fail to work).
An alternative to this was the [Apache OLTU project][3]. Unfortunately, it is not under active development and hence we cannot expect any support for any issues that might show up.
As suggested by @harsha89, we are now focusing on developing our own OAuth2 API which is similar in structure to Spring Security OAuth2 project. In near future, when we migrate the module to more recent releases of openmrs-core (preferably based on Spring 4), it would be easier for us to use the latest version of Spring Security OAuth project in the OAuth2 module.
As of now, we plan to write classes and interfaces that declare the same fields and methods as those in the latest release of spring-security-oauth. We would then provide an implementation for these methods that works with Spring 3.0.5.RELEASE. This would ensure that the database structure for the OAuth2 module (for storing tokens, authorization codes) is not modified when an upgrade is performed.
We could really use your advice on what is the best way to proceed from here.
So in a nutshell, we can’t use Spring backed OAuth unless we build the OpenMRS OAuth module against the OpenMRS master.
Right now, @maany is basically writing our own alternative to Spring OAuth, which may be complicated, and not the best option as we should be using a third party library for this purpose. If we were to write an OAuth module that uses OpenMRS master and using spring OAuth, then anyone hoping to use FHIR against OpenMRS 1.10 or 1.11 wont be able to use OAuth, unless they’re willing to upgrade to OpenMRS master…
As explained by @maany the best approach would have been move to spring security if we are based on latest OpenMRS master as we done the upgrade. But we can’t move to it as we need to support 1.10 or 1.11 for getting feedback on the implementers.
Our plan is to build OAuth module with similar OAuth token endpoints and the data modal align with spring security OAuth which will help us to migrate to spiring security with less effort in future.
Is OAuth a strict requirement to make FHIR work, or is there some alternative (that I assume is hackier but quick to implement)? Also, OpenMRS platform 1.11.x has Spring 3.2.7, so that should be sufficient, right?
My recommendation (based on quickly skimming this topic) is:
make FHIR + OAuth work against OpenMRS Platform 1.11+
do a quick hack so that FHIR + “some other placeholder auth mechanism” works against OpenMRS 1.10
But definitely try to avoid doing the full work of “writing our own alternative to Spring OAuth” if there’s any alternative to this.
@darius I totally agree with you. AFAIK It’s not a strict requirement that FHIR should have OAuth to work.
We can do like this, OAuth server will be external server hosting latest version of OpenMRS. So OAuth module will be installed in the latest master with spring security. For now we can configure FHIR to talk with our OAuth server and do the token validation. Once FHIR in latest master anyone can install both modules in one container without having two separate OpenMRS servers. This will reduce lot’s of time.
Authentication - Users/Clients may be authenticated in any way desired. For web-centric use, OAuth is recommended
So yes, FHIR may not necessarily need OAuth. However, We do need OAuth to support SMART apps - which raises the question that other FHIR compliant systems that want to communicate with us would strictly require OAuth.
@harsha89, i’m not sure if I followed your explanation… are you saying that we need to implement two separate servers to get it working on the current spring version?
I’m not sure how much effort this task requires, but how about:
Primary focus: getting OAuth working against OpenMRS 1.11.x using Spring OAuth and
Secondary focus: write our own code for supporting OpenMRS 1.10?
I’m also concerned how folks will respond to “our own OAuth” vs. “Spring frameworks OAuth”… when it comes to security, you know how folks can be …
Thanks for the suggestions @darius, @harsha89 and @surangak. I would like to confirm one point here.
So in my module’s api layer’s pom.xml, I added a dependency for spring-framework 3.1.1. I then build and installed the module on OpenMRS 1.9.8 (which uses Spring 3.0.5) and it worked fine. The only issue was that none of the URLs were being mapped to the controllers and a 404 error showed up for every request that was previously working.
If I could fix this and assuming there are no other bugs that pop up in using a higher version of Spring in a module than the OpenMRS platform, I could simply use the latest version of Spring security OAuth in OpenMRS 1.10.x
Yes @surangak , in this scenario, every OpenMRS 1.10.x implementation would be supplemented by a new server hosting OpenMRS 1.11.x or higher and having the OAuth module installed. The 1.10.x server will send requests to 1.11.x server for OAuth related calls. This undoubtedly simplifies the development of OAuth2 module, but the implementers would have to set up and configure the 1.11.x server for OAuth.
So yes, FHIR may not necessarily need OAuth. However, we do need OAuth to support SMART apps - which raises the question that other FHIR compliant systems that want to communicate with us would strictly require OAuth.
I think we eventually need to migrate to 1.12 in future. As I migrate the module to latest version. there is no major changes needs to support for java8 and latest version of OpenMRS core from module perspective. We can have two branches of the module which will work with latest or 1.11 + OAuth support and 1.10x maintained version which enable implementers to try it out. Since Spec is not finalize it yet, people still want to try this out until proper version release and go to production.
There won’t be two versions of OAuth module. 1.10.x will be use basic auth and if there is a requirement on OAuth we will need to configure OAuth in seperate openmrs instance and do validation of token using OAuth interceptor of the OAuth configured version of the FHIR module.
As I heard from the @maany, this framework gives interfaces which need to be implemented from our side. But these interfaces and token endpoints are standard ones which enables people to OAuth with standard set of interfaces. @maany can you comment on this?
The framework provides interfaces via which we can implement our custom login for authorization code,token generation and their persistence to name a few. There are default implementations of these interfaces that we can use as well.
