I feel like having user data stored in mongo AND OpenLDAP to be a tad redundant, by a tad I mean a lot.
Question for @elliott and @plypy: What was the rationale behind having both mongo and OpenLDAP – I feel like the whole purpose of dashboard is now obsolete since we Torpedoed Google Groups in favor of Talk-- at least in part – we still need it for some functionality such as Global Navigation Bar. The other features such as Discourse SSO, and oauth — seem like they could be done via Crowd.
… Sharp question indeed and my answers are:
The current design do have redundancies that I do not deny, yet it came with reasons.
@elliott and I wanted to make the user data schema more easily to extend, and as it’s hard to do so in LDAP so we migrated the whole data to mongo, which seemed to be a nice option, and managed to synchronize both ends.
I was a newbie developer that time, so I didn’t think too much before carrying out the design. And later in early this year when I tried to rewrite the LDAP module of Dashboard v2.0, I suddenly realized that how stupid I was… There seems to be a better design that store basic stuff in LDAP for authentication and use mongo to store additional attributes. But after a while, I realized it’s actually not too bad as we have two copies of basic data and we could use one for backup, so I didn’t put that forward. 
Except the redundancy, it’s actually handier, for us the developer, as it’s relatively easier to manipulate the data on mongo over LDAP.Moreover, the integrity of data could be guaranteed more, like the uniqueness of email address.
But it’s also true that it brought some difficulties for the admins. Especially for the ill-designed Group in mongo side. The whole idea of Group only has meaning for the Atlassian products. It’s totally useless to store them in mongo except DashboardAdmin group which could be easily replaced.
So in all, briefly, yes, we still need mongo, but certain things shall be fixed.
Addon: for SSO, OAuth2 or other potential small extensions. I think it’s still easier to implement them ourselves own.
Can we consider one of these two as backup? I mean in the point of view of “Database Backups”, it is usually not a used instance of database. It should be a snapshot. If we need to have backups, we need to take backups of both LDAP and MongoDB. So if we are going to continue with these two, wouldn’t it be grate that we migrate all the user attributes to MongoDB and keep authentication LDAP. WDYT?
From my perspective, Mongo is what we actually want to use, and OpenLDAP is a necessary evil.
LDAP pretty much has to stay around because of Crowd and the applications that use Crowd, e.g. Confluence and JIRA. So unless our situation with Crowd changes, we’ve got to keep copying username, first+last name, email address, and password hash over to LDAP.
To answer your question @r0bby, I don’t think there’s much hope for OAuth/SSO to migrate over to Crowd. Some of our authentication strategies (Discourse and Desk.com) are somewhat proprietary. Crowd isn’t a core product of Atlassian’s and I don’t expect much development on it from them: it exists to enable single sign-on for their applications, and nothing else.
So I agree that Talk has supplanted the “social user profile” ideas we had for the Dashboard at one point. The need is for OpenMRS ID to support as many authentication strategies as possible. Keeping Mongo around allows us flexibility in the future—we aren’t restricted by limitations to the LDAP model.
Hi @elliott, Thank you very much for the explanation. My thought as well was to keep all the user attributes in MongoDB. What I didn’t sure about was, actually, are we using the minimal set of attributes in the LDAP to support Crowd and Atlassian products which are using LDAP. So as @elliott has explained it seems like we do. So we need to keep both. @r0bby, @plypy, @elliott, how can we find out the DB schemas used in both? It will greatly help in finding out the best solution for the project here.
Let’s move the discussion to the GSoC thread