According to the README, Authentication module registers a custom DelegatingAuthenticationScheme which delegates to another AuthenticationScheme that is configured at runtime. So, in this case the Authentication mechanism needs to be delegated to OAuth 2.0 Login Module
Further in the README it is said that “Configuring
the default scheme is a matter of setting
the authentication.scheme configuration property to
the schemeId of a configured scheme” & the schemeId here will be the class name of the AuthenticationScheme that should be instantiated. So the class name here will be org.openmrs.module.oauth2login.OAuth2UserInfoAuthenticationScheme
To set the AuthenticationScheme the below lines were added to /var/lib/OpenMRS/openmrs-runtime.properties:
@nischith - OpenMRS core allows for modules to override the default authentication scheme with a custom authentication scheme by registering a spring bean of a specific class. Unfortunately, core does not account / allow for this to happen in more than one module - there is no way to specify what should happen if multiple modules do this. There is no explicit “sort order” and there is no ability to configure this.
The authentication module strives to work around this limitation by adding an authentication scheme implementation that delegates (DelegatingAuthenticationScheme) to another class that implements the AuthenticationScheme interface based on how this is configured at runtime (either explicitly in code or via configuration in the runtime properties file).
The oauth2login module (as far as I am aware) was built to always assume that, when installed, it is the authentication scheme that should be used.
In theory it should be possible to change the oauth2login module to depend upon the authentication module such that the oauth2login scheme is not registered as a spring bean but configured as the bean to delegate to from the authentication module’s DelegatingAuthenticationScheme, but I haven’t looked at other conflicts that might arise.
Another option is that we change core to allow for more than one module that provides authentication schemes to be installed simultaneously.
FWIW, I’d love for the authentication module to support oauth2 authentication natively, and merging these two efforts together. That would be another possible path.
For now, as things are designed, it is likely not possible to use these 2 modules together.
@mseaton Thanks a lot for taking the time out to clarify things. So, it is clear that these two modules were developed independently and unless some fundamental changes are made, it will be difficult to make both of them work together.
openmrs-module-oauth2login brings in the much needed SSO (Single Sign-On) capability but I think with just this module there is no way of tracking User log-in/ log-out timestamps and similar statistics (for these things there is a dependancy on openmrs-module-authentication)
To make the two modules compatible, I think almost all the changes need to be made to openmrs-module-oauth2login as explained here:
From here on, I don’t really know how the decision making happens at OpenMRS to make this a reality, but if it does happen, it would be wonderful for implementations!
If a plan does get chalked out, I would be happy to contribute.
It would be for the @Platform_Team to take this piece on their roadmap and start laying out specs and actionable tickets. From that point on dev work may be kick started (maybe by you?) and be reviewed by the Platform Team.
Best would be to discuss this over an upcoming TAC call - @grace?