Good. In such a case having a realm export would be enough, though in case any changes are made to the config via Keycloak UI one needs to remember about a new export. If we are not going to automate the realm backup, we need to make sure that it is documented to update it after making changes, which shouldn’t happen that often once things are setup.
Yes, I meant to remove ‘DEV_MODE’.
Does KeyCloak use postgres for operations and synchronize it with LDAP? If so and the postgres store can just be re-populated from LDAP, that may be fine; however, it might be worth testing how long it takes to start up with tens of thousands of LDAP entries. If that’s slow, then backing up KeyCloak’s postgres database might help.
<aside>On a related-note (having lots of users, many of which are noise/spam), I’m hoping this transition will revive the possibility of addressing two issues we missed with OpenMRS ID: (1) tracking the timestamp of last successful login and (2) ability to explicitly label accounts as spam. But, getting SSO working and migrating to Atlassian Online is our top priority.</aside>
Yes, the local database can be re-populated with LDAP. However, the synchronisation appears not done at startup but rather on demand.
@raff, could you please assist me in preparing LDAP? I have already updated the image to the latest version in my PR: PR Link However, the latest image is 3 years old. Is it okay? or shall we go with bitnami/openldap ?
Also, it seems that LDAP has already been published here: adaba.openmrs.org/vars Could you please guide me on how to set up LDAP? I am unclear about the setup process.
Btw, I set up Keycloak to automatically import the realm when it starts up so that we don’t have to bother with manual configuration settings.
Yes, we will need to upgrade to something more recent. Let’s test it out with bitnami/openldap.
It’s a production deployment of ldap. It uses this docker-compose, which is configured at this line. Basically in docker-compose you configure how to startup a service and in ansible/…/vars you copy over that docker-compose to the instance to start it up and configure nginx here.
For staging we need to revive ldap-stg. It can be placed here. Just copy over how it’s done for production on adaba, but use ldap-stg docker-compose.
I’m happy to announce that we have a working staging setup for Atlassian JIRA using our SSO.
It can be tested by going to Log in with Atlassian account and trying to login with your_openmrs_id@id-stg.openmrs.org. It will redirect you to our SSO where you need to create a staging account (not needed when we move to production), await an e-mail confirmation and login.
As part of the setup we create an alias for the e-mail you provide in the form of your_openmrs_id@id-stg.openmrs.org so that JIRA notifications can reach your real e-mail.
I needed to completely reconfigure Postfix for that to work. It no longer uses our smtp, but acts as a pure alias service that relays e-mails to target smtps only for user aliases existing in our ldap. Other e-mails are bounced. I’m not a mail expert, but I feel that I also need to restrict access to our smtp to Atlassian services only so that aliases are not used to spam our users? Unfortunately it was not possible to configure smtp credentials in Atlassian so Postfix needs to run as an open smtp client and we can only restrict access by IP. Or do we want to keep aliases available for everyone to use?
@jayasanka what’s the plan for https://id.openmrs.org? I’m assuming the form is going to be replaced by a button pointing to a create account form in Keycloak. Have you created such a page for Keycloak? I’m not seeing it in the Keycloak setup. Also I’m not seeing reCaptcha on the create account form in Keycloak?
What’s the approach for logout? Currently when you logout from Atlassian you are not logged out from Keycloak. I see no way to logout manually or even switch to a different account on Keycloak in the current setup.
Has this been thought through and I am missing something?
This is fantastic news, Rafal! I’m incredibly grateful for your hard work on this. 
Regarding the login process, my original idea was to use Keycloak as an intermediary page for login, rather than treating it as a standalone application, unlike how current OpenMRS ID functions. This would involve handling user registration and password resets, etc during the login process for products.
However, we do have the option to utilize Keycloak’s account console if we find the need for a separate user interface. In this case, we must consider whitelisting the appropriate pages to maintain consistency with our current login theme. The current theme only supports the login pages. I will delve into the theming possibilities later this week. I’m also interested in hearing @burke’s thoughts on this matter.
After a bit of investigation, for the time being, we’ll have to live with no single logout. If you log out of JIRA then you are not automatically logged out of SSO and if you log out of SSO, you are not automatically logged out of JIRA. This is a limitation of Atlassian Cloud and there’s an open issue for that https://jira.atlassian.com/browse/ACCESS-592 It’s strange it’s still not supported in the cloud, because a self-hosted instance does support it. Once Atlassian adds it, we’ll be able to switch it on instantly since it’s supported by our SSO.
The issue with no single logout is that, when you log out of JIRA and then try to log back in, you are automatically granted access, because SSO has a still active session. It’s problematic if you share your computer with others as there’s even no way to switch user.
For this reason we need a user console in order to be able for the user to explicitly logout from our SSO so let’s theme it. @jayasanka I’ll appreciate your help with that. It doesn’t need to be as nice as sign up/in screens. We’ll deprovision the old id service and have a link from https://id.openmrs.org to the user sign in/up and user console.
Given the adjustments I needed to make in the setup and needing to provide a themed user console the migration will take longer than planned. I think we are aiming now for mid November. Appreciate your patience.
This is terrific progress, @raff! Is there a way we can avoid users having to type in username@id.openmrs.org – i.e., start at KeyCloak? I think @jayasanka mentioned a URL earlier that could be used to simplify the flow for users. Ideally, users would register an account at id.openmrs.org and wouldn’t have to know about our little DNS hack other than seeing @id.openmrs.org after their OpenMRS ID in the Atlassian tools.
Is there a reason it couldn’t use our Mailchimp SMTP for sending email? Limiting ourselves to receiving emails from Atlassian to id.openmrs.org feels relatively safe (small attack surface); however, running a full email relay sounds much scarier. Receiving email is fine, but I’d rather not “own” the SMTP side, since improperly configured SMTP servers are a spammers favorite meal.
I was assuming id.openmrs.org would take you to the KeyCloak login/registration page. OpenMRS ID used to allow you to manage mailing list subscriptions, etc., but those features are old history. Presumably, id.openmrs.org would be the page you’d see when signing on and would offer a way to optionally logout. In the future, we could use leverage it’s role within the authentication flow to share breaking news or (rarely) as people to update missing information (e.g., “As you’re logging into OpenMRS services, would you mind taking a second to link your github account to your OpenMRS ID?”).
This is fine. When Atlassian supports it, we can certainly benefit from a true logout. But we can pretty easily train people how to properly logout if they’re on a shared computer. We just need to make sure we have an easy way for people to logout (e.g., a clear button on id.openmrs.org that takes them to something like this link).
+100 to all Burke’s comments above.
We won’t be able to hide it completely. If someone goes directly to Projects - OpenMRS Issues and tries to login, one still needs to type user@id.openmrs.org to use our SSO to authenticate. We could have shortcuts to the atlassian access login link from some pages or even a DNS redirect to this link from e.g. OpenMRS ID - Sign in and not having to type user@id.openmrs.org in such a case. I don’t see a way for Atlassian Access to go directly to our SSO when user clicks login in JIRA without typing user@id.openmrs.org first.
Atlassian Cloud doesn’t support using custom SMTPs. They only send out e-mails with their SMTPs. Fortunately they provide a list of IPs for their SMTPs so we can whitelist them on our Postfix instance and thus making @id.openmrs.org only relay e-mails from Atlassian. There was no need to use Mailchimp from Postfix, because it can relay e-mails directly to the recipient’s SMTP without intermediary Mailchimp smtp (saving us some $).
Sounds good to me. @jayasanka will you be able to theme OpenMRS ID Account Management so that it can be used as a replacement for id.openmrs.org? It would be great to incorporate in the theme the header from id.openmrs.org that points to different services issues, wiki, etc. Will you be able to complete it this week?
tl;dr this is fine. We can use links to make it easy for people to get authenticated to Atlassian tools without having to know this workaround and people will learn over time. We just want to minimize people having to think about it.
Yes. It’s unfortunate we can’t simply use openmrsid@openmrs.org; however, we’re already using this for Google accounts and can’t afford an unlimited number of accounts. Having people see openmrsid@id.openmrs.org on Atlassian sites and having it to use it if logging into Atlassian directly is the compromise we’ll have to make. The most annoying moments will be for users who assume they should be able to login using openmrs.org and for people with existing openmrs.org addresses they are already using to access other community websites in Atlassian’s cloud (like @grace & @jennifer).
I wish we could simply use openmrs.org, but it would require us to pay $$$$ every month for Google accounts that are not being actively used or take full ownership & responsibility for handling & delivering all openmrs.org email, which would demand better than 99.9999% reliability (which we can’t guarantee).
That’s fine as long as we can constrain the senders (i.e., avoid creating an open relay) and the costs over time of keeping these relayed mail from being treated like spam (because we don’t jump through every regulatory hoop properly) is less than the small cost of using Mailchimp’s SMTP.
Hi @raff ,
I’ve whitelisted the Account page as requested, for now I’ve done minimum changes. later we can improve it. I think we can redirect this page when someone visit id.openmrs.org.
@burke, The announcement option is now configured to permit the publishing of announcements directly from the dashboard without editing any files. All you have to do is to type something in the HTML Display name field. I’ve documented this on the readme file.
m@jayasanka and @raff I’ve been following this thread since the beginning and a huge thank you for all of the great work!
Wondering if you’ve thought about sharing your progress through a showcase at our upcoming Community Meeting & Showcase at the end of November? 
@jennifer I’m happy to support @jayasanka if he wants to walk us through the setup or else I can lead it.
I’m happy to announce that we now have the new SSO at id-new.openmrs.org and talk.openmrs.org is already using the new SSO.
I will now proceed with JIRA migration to the cloud. Once it is done we’ll replace id.openmrs.org with the new SSO entirely.
Another update. I’ve adjusted Postfix to use our mailchimp smtp so that we don’t have to deal with e-mails from JIRA being treated as spam as @burke suggested. Senders are constrained to Atlassian’s smtp servers.
Having notifications and authentication via @id.openmrs.org in JIRA cloud working, I can migrate our JIRA user e-mails to @id.openmrs.org now.
