I’m Isuranga Perera an undergraduate student at University of Colombo School of Computing. I participated GSoC 2017 and worked on implementing WS-Trust specification for WSO2 Identity Server. In addition to that I have worked on few features and Issues of Identity Server after the completion of GSoC 2017.
After going through the project objectives and guidelines I was able to come-up with some ideas for the project.
Password reset can be achieved with 2 approaches
Password reset via email
Password reset via challenge questions
Flow of Password rest via email
User clicks on the forgot password link/button
User is sent a verification email with a verification token (this should be a profile bound token which can be used for a single time and should have a expiration time)
User clicks on the verification email.
User is redirected to a password reset page after verifying the token is legitimate and not expired.
User sets the new password
Flow of Password reset via challenge questions
User clicks on the forgot password link/button
User choose “password reset via challenge questions” option
User answer the predefined set of questions.
If user successfully able to answer question user will be redirected to the password reset page. ( User may not have to answer all questions correctly. only to a percentage???).
As I see the main goal of the project is to implement email service. As I see we can wrap the JavaMail service and include some additional capabilities like
Custom Configurations
Custom templates (Users may introduce new templates so that this module can be used with other modules as well.
@wyclif@burke I went through some resources to get a better understanding of incorporating JSR 919 with OpenMRS Platform. So instead of implementing a email service only for password reset and account creation process we can implement a more generic service where other modules can use to send their emails with different templates. So I propose we use velocity template engine along with spring and Java mail. So others can use their own templates when sending mails. In addition to that we may need to expose a set of APIs to manage configurations, send emails, set templates etc.
As I see another problem with the password setup process is some factors such as password strengths, password patterns cannot be configured dynamically. Some organizations may need password with 10+ characters long while others need 5+ characters long. So instead of hard-coding these requirements we can introduce a configuration where system admin can customize password properties as they need.
The next thing is account locking. Even though it is not included in the scope this can be implemented within the GSoC period as it completes the security flow.
Hi @isuranga I don’t think the description literally means we are creating an entire email service just for password reset, think about it as; create a mechanism for password reset that’s email based, send email feature already exists in OpenMRS.
The password setup process is also already configurable in OpenMRS i.e setting allowed characters, required length etc and therefore that’s not likely to be re-implemented as part of this work.
Hi @wyclif@burke
Thanks for the clarification. Actually there was a task “Incorporate JSR 919 mail capability into the OpenMRS Platform”. Thats what confused me. So no need to add JavaMail support to OpenMRS platform since it is already there. In addition to that it has support for Velocity engine which we can used to create the email template.
Additionally there is an task to add email field to users table. In addition to that the token which is bound to the user profile should be in the database along with the expiration time as well. If so how do we do that. Do we have to create a separate table or just add it to the users table (Better approach would be to create a new table). Please provide your guidance here.
Hello @wyclif One of the point on the project description says.
Deprecate the use of user’s secret question and secret answer within the Platform.
I Wish to enquire if there is an assumption that all users do have email?. Also what of systems implimented to work only on local network. I think the emailing password reset should just be as a flexible addition to the already implimented version.
I think the first step would be “Hello world” for email capability – i.e., simply the ability to generate an email from OpenMRS. Steps like:
Adding a mail.jar – I’ve seen a common pattern (e.g., Atlassian products) that requires mail.jar to be manually added. It’s curious that it’s not bundled. Perhaps there’s a licensing issue or some other reason that they don’t include mail.jar by default?
Deciding in where SMTP configuration details will be stored. The most likely places would be in the runtime properties file or as global properties. Assuming we use global properties, it would be nice to obfuscate the password rather than store it as plain text.
Ensure we can support TLS / Secure SSL – i.e., the most prevalent best practice for secure email. It should not only work with Gmail, but most common SMTP servers.
Add a simple method to the Administration service to send an email. It should require a send email privilege.
Make a quick throw away module to send a hello world email from OpenMRS to prove it works.
Once we can generate email, then we can add users.email. Unless something has changed, I believe, based on some googling, email addresses can legally be up to 254 chars, so varchar(50) would not be sufficient. We would then need to make sure this new property can be set/retrieved via Java and REST.
With basic SMTP support and an email address property supported on User, we could then start building a mechanism/workflow for resettting a user’s password via email.
@burke I believe in core we already have a mechanism to send email and there is already GPs for storing SMTP settings, so I think what you are suggesting already exists.
@harisu I agree that we probably need to keep the secret answer and password alternative too because not every implementation works over a public internet connection.
Oh. It looks like it would benefit from some (any) documentation. I thought that service was for internal messages. I see there’s an email-based implementation of MessageSender. We will need to be able to guarantee the message is sent via email and not using some other form of MessageSender.
Thanks for the pointers. I still as yet have not grasp how the JSR-919 will operate after taking a look at the files you’ve presented and some googling.
I mentioned JSR-919 just to ensure we use the JavaMail standard rather than some custom, niche, or proprietary approach to sending mail. In other words, use javax.mail, which it appears MailMessageSender will take care of for you.
Hi @isuranga , @wyclif , @burke, I was searching about Password reset option in the Android Client. I wanted to know if this Project was completed and what APIs were used/created for Password reset via Email?
It will be very helpful for me.
Thanks.
Thanks @harisu, I went through your previous contribution in GSOC18 and that was awesome. I am looking forward to extend those parts into the Android Client as well.
Thank you very much for your guidance.
I thought that service was for internal messages. I see there’s an email-based implementation of