Thanks for presenting on today’s design forum. Some questions that came to mind during your presentation:
Will the module supply a “granting” web page for users to log into and grant privilege to client?
Will authorized apps be included in User resource (i.e., be able to enumerate as well as remove authorized apps via REST User resource)?
Any chance we can fix login redirection in the process? OpenMRS 2.x doesn’t yet support redirect after login.
Any chance this will be a first implementation of alternate authentication scheme?
Will this be an enhancement of RESTWS module or a separate module used by RESTWS?
What is the initial deliverable – i.e., what is the minimum functionality to be developed before we could have a usable OAUTH solution (I’m assuming this is a very simple OAUTH server with the simplest authentication supported)?
When will this initial deliverable be done (i.e., you should be delivering this minimal functionality before developing other additional functionality)?
@burke, @darius@surangak Thanks all for the giving the suggestions and feedback on proposed OAuth Module.
@maany Thanks for the informative presentation about the module. The discussion points about OAuth module will be definitely helpful with our module design. Let’s have a call soon and incorporate things discuss in the call.
Please find my thoughts and comments inline.
Actually user may get the token from the token endpoint by going through the browser redirection or providing necessary username, password along with client key and client secret through rest request. There are four major grant types available in the OAuth spec which suits for different cases. For example, Implicit grant type is mostly suitable for getting access token for pure JavaScript base applications. Because, it’s hard to store client secret and key securely within front end java script application. Hence user will redirect to OAuth provider login which asks for the username and password for the user. With the successful attempt, provider will return the access token to the registered call back as URI fragment. Like wise different grant type has different use cases which may involve with browser redirection or not.
After successful authentication, OAuth provider will return access token for the user. Depend on the grant type, user may get only access token with limited validity period or access token with refresh token which user can use refresh token to generate new token after token expired. Scopes also comes to play in here.
I think you are mentioning about the applications that are created when user register a particular application. For this, we may provider simple rest API. Otherwise creating a application via login through the OpenMRS will be needed.
This is something that we will need. Otherwise we need to have a simple form to take username and password to check whether user is authenticated and permitted.
Actually OAuth mostly plays on API security and it will be a authentication and authorization scheme.
We can have enhancement for RESTWS via configuration option to select either basic auth or OAuth2. We should be able to do this via filter.
We are planning to finish our first prototype very soon for get feedback. Will be use FHIR for it. @maany has done good amount of work on the prototype. @maany can you provide more details on the current implementation? Please feel free to reply after exams done.
We will be implement two or more major grant types and display how user can use OAuth2 to access APIs. :).
I am sorry I couldn’t reply sooner as I am in the middle of my final exams. Thanks Harsha for the answers I would like to add my thoughts to @harsha89’s points
Yes, the module will provide a granting page for the Authorization Grant Type and Implicit Grant Type. The grant page will look like :
Step 1 - user authentication:
Step 2 - user granting authorization to third party application:
Yes, A new table will be created in the database using the user_id as foreign key. It will maintain a list of authorized apps for every user (Many to Many relationship, A user can have many authorized apps and an app can be used by many users). It will be possible for users to revoke authorization at any time.
Step 1:
Step 2:
Thanks for bringing this up. I agree with what @harsha89 said, I will try to fix these. An alternate approach would be to provide a separate login.jsp (for logging in the user) and authorize.jsp (for granting access) in the OAuth module’s OMOD layer. So, the OAuth module will be controlling the login’s flow for incoming REST calls. I will comment more on it once I prototype this part of the project
OAuth could be implemented as an alternate authentication scheme. But I really feel that it is not required as OAuth is not a new Authentication Scheme. Rather, it is a third party application authorization framework that will be utilizing the existing Basic Authentication to authenticate the user. @harsha89 what do you think?
OAuth 2 will be a new module. Its main responsibility being issuing and validation tokens for third party apps making REST calls to our servers and managing the activities of these apps. As @harsha89 said and I mentioned in the presentation, the RESTWS module will have to add a filter to redirect incoming calls to the OAuth 2 module for validating the tokens. (This way users can invoke services through access token without exposing their credentials, also we can identify the client that is making the REST call and we have the control to allow or deny the service, track their activity/stats)
The minimum functionality includes Client ( i.e third party application) Registration, Client management (issue client secret/ remove client/ revoke authentication by users) and any one of the four available Grant Types. I am almost done with the Client registration and management part for the prototype. I will be implementing the Authorization Code Grant Type first.
I think I need 2 more days in a “hackathon mode” to complete the prototype. I will resume the work on 30 May, after my exams end
To get the wider picture of what the OAuth module would do and how it fits in, I prepared a Prezi last month. It should take about 5 minutes to go through. Here is the link:
Also, I am facing some problems to get hibernate to identify the annotated classes as entities (MappingException) while running tests for the prototype. . Here are the details of the issue : https://wiki.openmrs.org/questions/83854163/hibernate-annotations-and-tests-in-module
When you guys are free, could you take a look and point me to the right direction.
I hope you will support the OpenMRS 2.x UI and not just the legacy UI.
I’m presuming that calls will be coming from external applications that will provide an OAuth token and your module will need to execute these calls as if authenticated as the user. That’s why I assumed that you would be providing an alternate authentication scheme. Basic Authentication requires a username & password, which neither the external application nor your module will be able to provide.
FYI – the AlternateAuthenticationScheme is actually both authentication & authorization, since it allows custom-defined credentials to provide custom authorization:
We should be able to do this via filter.
. Here are the details of the issue : 