We are using JIRA and Confluence download versions. Both applications are connected to LDAP server. In addition to that we also have sysadmin users, which are in the internal directory, not in the LDAP. In case LDAP server is not reposnding, we can always login using sysadmin credentials to administrer some things inside JITA or Confluence.
We are also using OKTA, but not for JIRA and Confluence. There is a plan to introduce OKTA to Atlassian products as well. The question: is it possible to have access to those sysadmin accounts with OKTA integration enabled? I am trying to test this on my local, and because I have replaced seraph with the one for OKTA, every time I am accesing JIRA, it redirects me to company.okta.com, verifies my login and then I am logged in as myself. When I press log out, I am back at OKTA's page. But how can login as sysadmin, as this user account is not in OKTA, and there is a will to leave him outside of OKTA.
Vik, we are working on the same problem you are having. Multiple user directories and we only want to use Okta with one directory. The way the sample Okta Seraph authenticator works it is all or nothing. What I said was to use different accounts that are all defined in Okta.
Using Okta selectively by directory has no an out-of-the-box solution. The problem is that the integration should be in the login dialog rather than in the seraph authenticator. The authenticator should do what it does, see if the user is already authenticated and if not, redirect to the logon screen. The logon screen should have a button (ala ServiceNow) to let the user select whether to supply credentials or use Okta.
I haven't had time to work on this lately but my thought is to partially implement the Okta supplied seraph authenticator but leave the login.url parm set to login.action so that an unauthenticated user will get the Atlassian login screen. If the user has already been authenticated (clicked the JIRA chicklet in Okta) then they should pass through the authenticator. So it will be a partial SSO implementation. Once I can test we may need to make some tweaks to the seraph code but haven't got that far yet.
Have you looked at any of these products? That last one seems to have the ability to allow a local authentication in addition to that via Okta.
I'm not endorsing anything. We haven't tried any of them yet. Curious if they solve the problem we have.
At Summit 2016 I was able to talk to the Atlassian developers who are working on the SSO implementation for Data Center and explained the directory problem. Since then I have noticed that the Atlassian sites now use a two step logon screen, 1) enter user ID, 2) click next. The would be the prerequisite to selective SSO implementation by directory. So fingers crossed. Sadly SSO is only released in Data Center versions at this time.
One other thing I have not had time to try out yet is: in the Okta App configuration, you can set a URL to be used if the user is not assigned an app. That URL would be the Atlassian logon.action URL. I just don't know if this will help if the user (sysadmin) does not have an Okta account at all.
The Okta documentation directly states how you can have certain users or groups that are exempt from logging in via Okta - https://support.okta.com/help/articles/Knowledge_Article/29583593-Using-the-Jira-On-Premises-SAML-App
I set up Okta on-prem for JIRA and Confluence and having no issue with the system admin accounts logging in without Okta accounts since they are in a group "service-accounts" which I then put into the okta-config-jira.xml file as follows:
<configuration> <applications> <application> <md:EntityDescriptor.... Redacted </md:EntityDescriptor> </application> </applications> <spGroups> <groupname>service-accounts</groupname> </spGroups> </configuration>
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG