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. 
2 Likes
@burke I have been playing around with Okta for the past hours I guess I messed up some configurations 
. 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
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
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.
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.
- How do we expect to generate an openmrs mail for the user eg noah@openmrsuser.org
- Do we need to involve the use of an idp or we use the default atlassian id system
- 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
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
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
For email relaying a colleague recommended the CloudFlare offering: https://blog.cloudflare.com/introducing-email-routing/
Thanks @jwilliamsatlassian! @cintiadr Iām confused, sorryā¦ soā¦ where are we at w.r.t. having SSO stabilized so we can finally move onto Atlassian Cloud?
Reading through this thread, it looks like the step weāre on is identifying a viable method for redirecting emails so we can register everyone within a single domain ā e.g., openmrsuser.org. So any services (like Atlassian) could have and use an email for each user (e.g., for notifications, password resets, etc.), but we donāt have to manage email accounts for everyone. From @cintiadrās comment in May:
Iām assuming weād need a solution/service for email redirects that:
- Has an API so we could automatically add/update/remove entries.
- Ideally, only redirect emails from a predefined set of senders, so only emails from select services would be redirected and all others silently dropped or returned as undeliverable (to reduce the chance of becoming a source of spam). This would also prevent people from using or depending on the email alias as a general email address (itās sole purpose would be for giving providers like Atlassian email addresses for everyone within a single domain that we ownā¦ ideally, userās wouldnāt need to know about it).
@jwilliamsatlassian suggested Cloudfareās email routing; however, it appears to be in beta with some limitations (like not working for a subdomain, not working for international domain namesā¦ not deal breakers) and doesnāt (yet?) offer an API.
Iāve used a service like Fastmail for personal email redirection, but assume we will need something like one of the services @ndacyayisenga mentioned earlierā¦ preferably something more robust than using postfix, since email can be tricky if you donāt want to become a spam engine or have your emailās all end up in peoplesā spam folders because you didnāt handle something like DMARC correctly.
@cintiadr, would it help to come up with a temporary email redirect solution in order to test the viability of IDP/SSO/OAuth/SAML?
3 Likes
I havenāt implemented MailGun for redirection(MailGun calls it Routes) but have used them as a mail relay and had a very positive experience. They have a robust API (Routes Specific Docs) and I never had mail rejection issues after moving to use them as a relay.
Greetings,
There exists a degree of ambiguity as to whether we are still associated with Keycloak, and despite some efforts towards it, there is presently no apparent means to assign users/groups (beyond Keycloak) to Atlassian Access or other applications through System for Cross Domain Identity Management (SCIM).
While there is a potential solution in the form of scim-for-keycloak, the proprietor of the aforementioned repository (Captain-P-Goldfish) has stated that it is not capable of provisioning users outside of Keycloak to third-party applications. You may find additional information regarding this matter in this discussion thread.
Currently, there is a created issue for both Red Hat and Keycloak regarding the implementation of SCIM functionality. Please see the following links for further details:
https://issues.redhat.com/browse/KEYCLOAK-2537
The below is just a thought though
It may be worth considering alternative identity providers that offer full SCIM support in conjunction with Atlassian Access. Some of these options include,
- Auth0
- CyberArk Idaptive (formerly Centrify)
- Google Workspace
- JumpCloud
- Microsoft Azure Active Directory (AD)
- Okta
- OneLogin
- Ping Identity.
A comprehensive list of supported identity providers can be found here.
We are starting to experience the reality of support for self-hosted Atlassian being withdrawn. Given that all support for self-hosting ends in February 2024 (which is fast-approaching), we need a strategy for migrating Confluence & JIRA to the cloud.
Iāve been trying to play with postfix + ldap, but havenāt made much progress yet. It looks like postfix can use an LDAP store. While Iām not eager to host our own postfix server, it seems like a system configured only to deliver mail from Atlassian address(es) to the email address found in LDAP at <valid-username>@user.openmrs.org would be feasible and scoped small enough to avoid becoming a spam relay.
The alternative would be to look through the supported services @ndacyayisenga listed above and see if any our feasible. For example, something free or inexpensive without the quota limits like weāve run into with Google Workspace.