Limitations of Migrating from OpenMRS ID to a new SSO System

Community
3

Let’s get a couple of definitions first.

We want to have an unified ID (with data eventually migrated from the current ID system) that will allow a user to login (using same mechanism/credentials) to the following systems:

  • Jira cloud
  • Confluence cloud
  • Jira server
  • Confluence server
  • Discourse (hosted by us)

Eventually we’ll migrate away from the Jira and Confluence servers, but for the moment they are needed. ID migration is a dependency to move away from the servers.

Due to the complexities, this proof of concept is being started in Jira Cloud, as that’s where we anticipate the biggest issues.

Our first attempt is to exhaust all options that allow users to bring their own emails from whatever domains they want.

There are two approaches to login users in Jira cloud:

  • SSO route: either using SAML (default) or OAuth (miniorange), a user from a verified domain will be redirected from/to a centralised system, that will be responsible for login. This option is discarded for this first experiment, as we want to allow users to login from unverified domains
  • User provisioning (via SCIM): a third party system will be the source of truth for users, and will push updates to Jira. Documentation seems to imply that this can be done for unverified/third party domains.

So far, so good. We will be exploring SCIM options in Jira cloud and see what we can do. Of all the systems we have in that list, Azure AD seems to be one worth experimenting, as the cost isn’t exorbitant. That sounds like a good first try; the second option will be using KeyCloak with SCIM plugins.

We will not explore any IDP solutions or brokers, as we know they do not work with unverified domains in Atlassian Cloud. At this point, we are only focusing on SCIM, not SSO.

We are currently attempting to verify the following POC:

  • Create a user in Azure AD manually
  • Ensure this user is pushed to Jira Cloud
  • Login to Jira Cloud

That’s step 1. If we do this, it means we understood SCIM and we did the bare minimum.

The second step will be find out how to get the email in Atlassian cloud reflect a different field than the main email in Azure AD. As per docs:

If the user does not have one [Microsoft Exchange Mailbox], it is recommended to map a different desired attribute to the emails attribute in Atlassian Cloud

We need to discover how to do this. Step 2 will be successful when:

  • Create a user in Azure AD manually, and enter the unverified email in a random field
  • Ensure this user is pushed to Jira Cloud, the random field shows up in Jira Cloud as their email
  • Login to Jira Cloud

Those are the two initial steps. As this is a POC, we are experimenting with our possibilities.

1 Like