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.
@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
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.
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.
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/
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 ‘firstname.lastname@example.org’ would be redirected to my personal email, configurable. I wonder what possibilities we have there.
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:
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 email@example.com
- 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
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
firstname.lastname@example.org , but in reality we will have something that will redirect that email to
email@example.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 firstname.lastname@example.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.
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.
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
@jwilliamsatlassian Will SCIM produce the same functionality when used in conjunction with SAML. I mean allow users from non verrified domains still?
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.
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?
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.
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:
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,
- CyberArk Idaptive (formerly Centrify)
- Google Workspace
- Microsoft Azure Active Directory (AD)
- Ping Identity.
A comprehensive list of supported identity providers can be found here.