GSoC 2022: Limitations of Migrating from OpenMRS ID to a new SSO System

I think I got the same experience as @cintiadr. I successfully created an account at https://dev-7596793-admin.okta.com/, but going to JIRA was like signing up for a new account at id.atlassian.com (asking me to confirm via email and create a new password). Returning to https://dev-7596793-admin.okta.com/ (even by logging in through an incognito window) now yields a 403. :confused:

2 Likes

@burke I have been playing around with Okta for the past hours I guess I messed up some configurations :thinking:. Its behaving mysterious compared to first experience I had with it after the initial configurations. The interesting thing is that I already have you in Okta and atlassian. Am looking for solutions on how to take 403 error down

1 Like

Hey @burke @cintiadr

Updates from this way.

If you’re not using SAML and hoping users can login directly to Atlassian, the table on this page indicates that the cloud connector may not support pushing passwords

A user can successfully create an account in Okta and can be successfully pushed to Atlassian cloud but the password is not pushed. This is Why Last time you created accounts in Okta and you were successfully pushed to cloud but you were not able to login in Atlassian cloud.

The reason as to why mine worked in the first place is all the users I used to test had gmail accounts so I was using google to login. By default the google account syncs its password to atlassian cloud as the new password.

Resolution

After creating an account in Okta, you will definitely exist in both Atlassian and Okta but to login to Atlassin you need to create a new password for Atlassian to be able to login.

How to test this

Currently under my Okta Directory, the Self-Service registration functionality is disabled in my

trial account compared to the previous account I had. I was advised to send a message to the Okta support team but they haven’t enabled it yet.

Previous account

image

Current Account

What I did was I created an account for @cintiadr and am gonna do the same for @burke. These accounts already exist in atlassian through user provisioning. To login, Enter you email, click on continue and after click on Can’t login in? login link.

image

You will be prompted to create a new password for the that user(email) and you will be able to login.

My new atlassian site is https://gsocfinal.atlassian.net/

1 Like

Awesome, that’s the whole question I needed answered. I couldn’t understand how password sync would happen with SCIM, and I didn’t understand that it would deal with authorisation (but not authentication). That’s why I’ve been asking you for this POC since early april.

I guess it makes it pretty clear how SCIM is implemented; users are pushed to atlassian, but password is isolated. It can be potentially part of our solution, but it was important to understand how it worked.

I believe it’s time to park SCIM to start exploring other solutions. This POC, even if it’s with okta, gave us a clear understanding how it works.

====

Now that SCIM is well understood, it would be nice to learn about how can we get a service to redirect emails. For example, email ‘cintiadr@openmrsuser.org’ would be redirected to my personal email, configurable. I wonder what possibilities we have there.

1 Like

The dumbest way I know of is using postfix, but there should be a better way than restarting it on every new person signing up:

https://www.cyberciti.biz/faq/linux-unix-bsd-postfix-forward-email-to-another-account/

1 Like

There are a few things I need to be clear with as we investigate on Forwarding an email to another email account.

  1. How do we expect to generate an openmrs mail for the user eg noah@openmrsuser.org
  2. Do we need to involve the use of an idp or we use the default atlassian id system
  3. Which default mail will the user initially register with.

I just feel I need to understand the workflow on how this is expected to work.

Sincere Regards from this way

Noah

Ok, let’s see if I can explain.We have two options to explore:

  • SCIM: we don’t use our own domain, but rather each user come with their own domain
  • IDP / SSO / OAuth / SAML: we have our own domain and allow people to use it to login

We explored SCIM, and now we understand how it works.In order to explore any other option (IDP/Oauth/SAML), we do have to have our own domain. That’s trivial, we just have to buy it. But I do not, DO NOT, want to provide an email box to people with said domain. But I still want people to receive emails from jira, confluence and talk.

So we need to find something that can forward emails. Jira will send emails to cintiadr@openmrsuser.org , but in reality we will have something that will redirect that email to cintia@gmail.com . What’s that something? To be investigated.

Before we can try IDP/SSO options, we need to find options to redirect emails. I’d think the first step is googling services, applications and everything that offers that. We need to have something that we can automatically add users, change their emails, and ensure it will redirect to the right place.

How do we expect to generate an openmrs mail for the user eg noah@openmrsuser.org

We won’t. We need a service that will answer any openmrsuser.org email and redirect them to the right place. We will need to know what ways to register a new email redirect there are.

Do we need to involve the use of an idp or we use the default atlassian id system

Not relevant now. We have to solve the email redirect before trying anything else.

Which default mail will the user initially register with.

Not relevant now. Literally we need to find out options to redirect emails before we can evaluate IDPs or registration.

@cintiadr thanks for the detailed explanation.

FWIW, we could investigate the best among the following options

1. Forward Email

2. Mailgun

3. Cloudflare

4. Pobox

5. ForwardMX

6. ImprovMX

7. @EmailForward.mx

8. SimpleLogin

Hey @cintiadr @ndacyayisenga! This is James with Atlassian. I am so sorry we’re so late joining the conversation. If you’d like assistance with a POC on the email re-routing or if there is anything we can do to assist please don’t hesitate to reach out.

1 Like

Thanks to reach out @jwilliamsatlassian.

@grace @jennifer @dkayiwa is it okay we still go on with this or it’s on pose for a moment

Cc @burke @cintiadr

Hi @jwilliamsatlassian !

I’d love some assistance, for sure. I guess first thing would be double check our thoughts. Did we miss anything? Is this how SCIM works, only providing authorisation but not authentication?

If so, yes, I’d love a POC of email forwarding that offers the least amount of effort to us, but that we could afford even with 10k users.

Hey @cintiadr,

That is correct. SCIM on it’s own will be Authorization but not Authentication. When coupled with SAML or another SSO technology you could implement Authentication as well if necessary.

I will investigate options for an email forwarding POC and report back early next week.

Thank you, James Williams

4 Likes

@jwilliamsatlassian Will SCIM produce the same functionality when used in conjunction with SAML. I mean allow users from non verrified domains still?

Regards, Noah

The implementation of non-verified domains would be on each identity client. I know that for example Atlassian Access wouldn’t allow non-verified domains.

1 Like