OKTA single sign-on, but not for all users

[Roman Serazhiev]

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.

Thanks.

[w2oscondonN · Accepted solution]

I have had this work for me in the past: In Okta, open the record for your account and change the user ID for the application you'd like to login as. Good luck!

[Roman Serazhiev]

Hi,

Not actually what I wanted, but I have already talked to Atlassian, and this is the only way for now until they allow multiple authenticators in seraph.

Thanks.

[Vik Solem]

Any word on this?  We also have local admin accounts that are needed, which will be un-usable if OKTA is implemented.

[Andrew Shahan]

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>

[David Yu]

Re-opening an old issue here, but are you sure that Stanza actually works? Testing 3.0.6, it seems you can use any user regardless of what's in the Stanza.

[Markus Lindemann]

https://confluence.atlassian.com/jirakb/enable-auth_fallback-to-bypass-saml-in-jira-data-center-869009810.html has an approach for essentially allowing you to bypass the SAML authentication which you could use for the local admin account.

[Max]

This one is for Atlassian Data Center core feature, not for Okta

[WPSC]

You can also use the URL https://company.okta.com/login/default and you will be able to choose the account to use rather than always being logged-in as yourself.

[Vik Solem]

I don't see how this allows login to a JIRA local-directory account instead of to an active directory account.  Am I missing something?

[WPSC]

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.

[Vik Solem]

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.

• SAML SingleSignOn for JIRA
  • by resolution Reichert Network Solutions GmbH for JIRA Server 6.4.9 - 7.1.8
• SAML 2.0 Single Sign-On for JIRA
• • by Bitium, Inc for JIRA Server 6.0 - 7.1.8
• SAML Single Sign On for JIRA
  • by miniOrange for JIRA Server 7.0.8 - 7.1.8

I'm not endorsing anything.  We haven't tried any of them yet.  Curious if they solve the problem we have.

[WPSC]

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.