I step up user provisioning with Okta. Am able to create accounts with okta and users are successfully pushed to atlassian cloud. After users create accounts and they are pushed to atlassian, I mean their user accounts exist in both atlassian and Okta but they are not able to login to atlassian using the same credentials used while creating their accounts.
Hey @noah, I’m assuming you’re using SAML to auth into Atlassian. First thing to check is that the relevant users are assigned to the app.
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 - so you will have to setup SAML.
Does this mean SAML will work alongside user provisioning(SCIM). My main goal is that users from unverified domains can login to my atlassian cloud instance as well as create accounts for themselves through Okta.
Do I need to configure user provisioning(SCIM) with SAML at the same time?
Hi @noah
Yes, SAML and SCIM work side by side. SCIM handles the user lifecycle management. SAML handles signing in.
If you’re enabling user self registration on Okta, when they register and set a password in Okta, SCIM should then create their corresponding Atlassian account (assuming everyone gets access to your Atlassian.
When they sign in at Okta with the password they set during registration, Okta tells Atlassian to trust the login and not prompt them using SAML.
@abole All I need is that users from both verified and non verified domain can be able to create accounts using okta and are able to sign in to atlassian using the same credentials they used while creating acconts
Yeah should be doable @noah. Contact support to get self service registration enabled (if it isn’t already) and set it up. You can choose whether to validate email addresses or not during during registration (NIST 800-63 guidance is to validate a communication channel.)
If your goal is everyone that signs up get access to Atlassian, assign the Okta default “Everyone” group to the Atlassian app (easiest / least secure if not everyone in your company needs access). Otherwise you may want to setup a new Atlassian specific group and either:
manually assign people to it (e.g. daily)
use a group rule if there’s attributes you can use
setup a workflow to do it for you (also will depend on attributes)