Limitations of Migrating from OpenMRS ID to a new SSO System

[ndacyayisenga (TAYEBWA NOAH)]

Hi all, Following the GSoC project Migrating from OpenMRS ID to a new SSO System we got urgent limitations.

The primary goal of the project was to integrate an identity provider with

• OpenMRS Atlassian cloud(jira and confluence)

• OpenMRS discourse ie OpenMRS talk

The suggested idps were either Keycloak or Azure AD.

The limitations we may have as we plan to achieve the goals of our project

To integrate atlassian cloud with any Identity provider we need to use atassian access which is an organization-wide subscription that connects your Atlassian cloud products to your identity provider.

The following are limitations from atlassian access

• Atlassian Cloud only supports provisioning updates for users with verified domains. Changes made to users from a non-verified domain will not be pushed to Atlassian Cloud. Learn more about Atlassian verified domains [here]

• Atlassian Cloud does not support group renames today. This means that any changes to the displayName of a group in Azure AD will not be updated and reflected in Atlassian Cloud.

• The value of the mail user attribute in Azure AD is only populated if the user has a Microsoft Exchange Mailbox. If the user does not have one, it is recommended to map a different desired attribute to the emails attribute in Atlassian Cloud.

If OpenMRS is to use Atlassian cloud we need to have a verified domain/ verified domains and this won’t allow users to login from different mail domains ie @gmaill ,@yahoo, @hotmail among others which is quite inconveniencing.

Bullet No3 of the limitations

The value of the mail user attribute in Azure AD is only populated if the user has a Microsoft Exchange Mailbox. If the user does not have one, it is recommended to map a different desired attribute to the emails attribute in Atlassian Cloud.

What they are meaning here is domain mapping. This means we can use a broker to map many domains to atlassian cloud but these domains also have to be verified. Actually the best way I found understanding domain mapping in our case is using miniorange brokering. In that case miniorange acts as a broker to many different idps that handle different verified domains. something that can be found here What is Identity Brokering - miniOrange

Atlassian Access is the main culprit here which does not process any response (received either from miniOrange Broker or directly from IDP like Keycloak, Azure AD) for users with non-verified domains. All those solutions only work for the user with a verified domain.

So even if the miniOrange sends the user information to Atlassian Access for sync, Atlassian Access won’t process it.

Don’t know whether as OpenMRS we have a centralized domain probably @grace @jennifer @dkayiwa know better about this. This would mean that all users have to own mails of a verified domain.

The two solution my small eyes are seeing

1. • Getting a centralized domain where all user mails could spin from
2. • We host our own atlassian instances and we only change the idp since the idp looks to be the biggest problem. This solution doesn’t require a verified domain

Gathered this information while I was in sync with @cintiadr

cc @burke @grace @jennifer @herbert24 @kdaud @dkayiwa @ibacher @sharif

[grace (Grace Potma)]

Thank you very much for this, Noah. Looking forward to Burke & Cintia’s response.

[cintiadr (Cintia Del Rio)]

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.

[cintiadr (Cintia Del Rio)]

So, based on your message, it would seem that Microsoft Docs are saying that the atlassian connector will NOT push the user to Atlassian Cloud if the domain is unverified. But that directly contradicts Atlassian docs.

Azure documentation points to atlassian documentation, which says that third party domains is allowed.

If you manually provisioned users from outside your domain (e.g. third-party staff) before November 15, 2020, you can automatically sync them now. Learn about syncing users outside your domain.

When you set up user provisioning, you create a directory for your users. All users and groups in your identity provider from your verified domain(s) or from outside your verified domain(s) sync to your organization's directory, as shown in the diagram.

I think the documentation in Azure AD is out of date, probably for more than a year. Atlassian connector docs seem pretty certain that users from unverified domains should be automatically synced.

---

Now, we aren’t interested in a domain mapping. Or having multiple verified domains. Or having multiple IDPs I guess. We aren’t capable of verifying domains that we don’t own, and also we won’t be able to do a mapping between all existent domains to ours. Doesn’t seem a practical move at all.

[ndacyayisenga (TAYEBWA NOAH)]

Hi all, hope all is well where you are. Also, thanks for the heads up @cintiadr.

@cintiadr you are correct, Atlassian access requires that we first Verify a Domain. Once we have a domain verified we can then configure an external User Directory for user provisioning (SCIM).

Once this is done we can then automatically provision users from within and outside of this verified domain. However, there are a few caveats:

1. These accounts (Gmail, Yahoo, Hotmail) will not be considered a “Managed Account” and user attributes will not sync.
2. SAML SSO log enforcement would also NOT be possible as these users are not “Managed Accounts”
3. We will also not be able to make ANY changes to these accounts once synced

One of my suggestions to achieve our goals would be to use atlassian’s built-in “Invite User” function in the https://admin.atlassian.com portal:

When you add a user to your Users list, you’re inviting a user with that specific email address to your site. If the user with that email address has an Atlassian account, they’ll now be able to log in to your site. If the user doesn’t have an account, we’ll walk them through the Atlassian account signup process. Although they’re logged in to your site, their account exists outside your site so that they can use that same account to log in to other sites. see this here

Users will be sent an email invite to your site where they can then create an Atlassian Account if they do not have one yet.

With this approach, we can be sure Users can absolutely create an account themselves. They would just need to navigate to https://id.atlassian.com and complete the account creation process.

You can create an Atlassian account yourself. Just go to https://id.atlassian.com/ and complete the process. We’ll email you asking that you verify your email address. see this here

@cintiadr @grace @burke @dkayiwa @kdaud @jennifer @ibacher let me know whether this makes sense to our community

Sincere regards

Noah

[burke (Burke Mamlin)]

So, my simple-minded understanding is:

• We can tell Atlassian Access that jdoe@openmrs.org is a new user (new to Atlassian) who can access our wiki (because we own openmrs.org).
• We can tell Atlassian Access that we want jdoe@example.com to be able to access our wiki as long as jdoe@example.com already has an Atlassian account.
• We cannot tell Atlassian Access that jdoe@example.com is a new user (new to Atlassian) who can access our wiki, since only example.com can do that.

Do I have this right?

[ndacyayisenga (TAYEBWA NOAH)]

Thanks @burke for the response:

@burke

• We can tell Atlassian Access that jdoe@openmrs.org is a new user (new to Atlassian) who can access our wiki (because we own openmrs.org).
• We can tell Atlassian Access that we want jdoe@example.com to be able to access our wiki as long as jdoe@example.com already has an Atlassian account.
• We cannot tell Atlassian Access that jdoe@example.com is a new user (new to Atlassian) who can access our wiki, since only example.com can do that.

Your 3 steps explained my idea very well

My question is, Could we opt for something like that?

cc @cintiadr

[cintiadr (Cintia Del Rio)]

@ndacyayisenga

Once this is done we can then automatically provision users from within and outside of this verified domain. However, there are a few caveats:

1. These accounts (Gmail, Yahoo, Hotmail) will not be considered a “Managed Account” and user attributes will not sync.
2. SAML SSO log enforcement would also NOT be possible as these users are not “Managed Accounts”
3. We will also not be able to make ANY changes to these accounts once synced

(1) is fine

(2) is known. I’m not looking for SSO anymore

(3) that’s where I’m not sure. I don’t care much about any attributes other than passwords. Can you do a POC here?

@ndacyayisenga

One of my suggestions to achieve our goals would be to use atlassian’s built-in “Invite User” function in the https://admin.atlassian.com portal:

If we do that, first we will have to create some code to call that from whatever is our ID system. Which is fine, not a deal breaker, but not what I desire.

But we are going completely against what we need here. We are talking about two different users, that are independently maintained, with different passwords. If users are going to be creating users by themselves, we already have that. There’s no need for us to do anything, they go to the website and create it. This isn’t the solution I’m looking for.

[cintiadr (Cintia Del Rio)]

I still would like to see a POC with Azure AD, SCIM and jira cloud with non verified domains.

I’d like to have that so we can see the actual limitations of that. I don’t care that the name isn’t updated. I care about passwords, users being deleted and created, the lot.

Can you set this up for us?

[burke (Burke Mamlin)]

@ndacyayisenga

My question is, Could we opt for something like that?

Making it semi-automated (automatically inviting users to create an Atlassian account) would be better than nothing, but ideally we wouldn’t force users to create another account (i.e., one on Atlassian) when signing up for an OpenMRS ID.

Any chance we could give new users without an Atlassian account an email alias? That is, jdoe@example.com signs up for an OpenMRS ID, we determine from Atlassian (or from Joe) that he doesn’t already have an Atlassian account, and we register him with Atlassian as jdoe@my.openmrs.org without actually creating an email account at that address? We could use a service like fastmail.com to receive all emails to *@my.openmrs.org and forward password reset requests from Atlassian to valid OpenMRS usernames, ignoring everything else.

[cintiadr (Cintia Del Rio)]

@burke

We could use a service like fastmail.com to receive all emails to *@my.openmrs.org and forward password reset requests from Atlassian to valid OpenMRS usernames, ignoring everything else.

I’m treating this as our plan B, or C, or something. I’d rather we don’t have to create a ‘redirect’ email service in a way. As soon as you send email (even as redirects), you get all the problems of having an SMTP server: allowing a couple of spam emails can undermine our reputation and get us booted from all our providers. And we want to allow jira/confluence to send emails, so we would need to redirect everything coming from there.

Also, it’s not clear if we’d be able to get discourse with a different email…

Before we go that route, I want to exhaust and evaluate all our possibilities, so we choose the one that is less troublesome.

I really want to have a POC for SCIM with emails outside the domain to see how it behaves.

[ndacyayisenga (TAYEBWA NOAH)]

@cintiadr @burke @grace @kdaud

Lets try this out. Anyone can now login to my atlassian cloud account with any random mail domain.

Here it is http://bluesoccer.atlassian.net/

Follow the following steps to create an account

1. one (click on signup for an account)

   

2. two (Enter your email address of any domain)

   

3. three(verify your email)

4. four(You are redirected to atlassian)

5. five(You are requested to join my site)

6. six(You already have an atlassian account)

   

7. seven(Me as a site admin, I will surely have you in my site)

   

[ndacyayisenga (TAYEBWA NOAH)]

It doesn’t matter what mail domain you use, it works for all

[jwnasambu (Juliet Wamalwa)]

It doesn’t matter which email domain you use as long us as you already have an account.

[jwnasambu (Juliet Wamalwa)]

@ndacyayisenga you are right!

@ndacyayisenga

It doesn’t matter what mail domain you use, it works for all

I was just affirming your statement above. Not everyone has an openmrs email and so the system is open to any email domain.

[burke (Burke Mamlin)]

It works! And it was a pretty straightforward process using existing Atlassian credentials. It could work if it’s our only option, but, it would be great to have an approach where people don’t have to manage separate OpenMRS & Atlassian credentials.

[cintiadr (Cintia Del Rio)]

I’m still not convinced it’s our only option.

We have several avenues to explore, and this is the order I’d like:

• azure AD with SCIM
• keycloak with SCIM (if azure POC works)
• investigate email/domain redirect options

Using independent logins has been what we’ve already been doing so far. It’s really not what I’d like to rollout.

What I’ve been asking is to explore the SCIM. I’d like a POC

[ndacyayisenga (TAYEBWA NOAH)]

Hey @cintiadr @burke

User provisioning works(SCIM). I got a POC with Okta

1. Create an account here https://dev-7596793-admin.okta.com in my Okta portal. You will be sent an email to verify your account. Immediately you own an account in my Okta portal, you will automatically be pushed to my atlassian cloud site.

2. After creating an account in my Okta portal, Login to my atlassian cloud site https://gsoctrial.atlassian.net using the same credentials used while creating an account on my Okta portal. Your account will be reflected in Atlassian Admin

The form used to register in Okta can be customized ta as many user attributes as you may want

NOTE Am still finding out how to re-direct one of the above links so that we can use only one link in the entire process

[cintiadr (Cintia Del Rio)]

That didn’t work for me.

I tried to setup okta, worked fine. But if I try to login again, I get 403s.

I tried to login to jira, and it says invalid username and password.

can you check if my user was pushed to atlassian?

[ndacyayisenga (TAYEBWA NOAH)]

@cintiadr Am not certain whether you are using the right credentials to login because I already have you in both Okta and Atlassian Admin