I have configured Confluence (on-prem Server version) to use Okta Single Sign-On (SAML), using these instructions: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Using_the_Confluence_On_Premises_SAML_App.htm (as well as the configuration instructions generated by Okta during its configuration process).
It works great if I click on the application chiclet in Okta--the user is logged in using Okta and SAML. HOWEVER, if I go directly to the Confluence site, Okta is not invoked at all, and I am able to enter my AD credentials and log into Confluence, as if it had never been configured to use Okta. We want to require users to log in with Okta (among other reasons, it requires Multi-Factor Authentication).
We have also configured our on-premises JIRA server to use Okta in a similar way, and it DOES invoke Okta when the user goes directly to the JIRA URL (this is the behavior we want).
Does anyone know if the behavior I am experiencing with Confluence and Okta is normal and the best I can hope for at this time? Or have I misconfigured something?
Thanks, everybody, for suggesting alternative products for SSO. However, our company is intent on utilizing Okta, so we would rather not switch to a different SSO provider for this one use case.
I was able to get the issue resolved with the help of Okta support. The trick was to apply the same parameter value for link.login.url in the /opt/atlassian/confluence/confluence/WEB-INF/classes/seraph-config.xml file as the login.url parameter provided in the Okta Confluence SAML application setup instructions.
I am experiencing the same issue in my organisation. I have updated the seraph.config.xml file. But still the same issue. when entered confluence url it directs to https://confluence.example.com/login.action?os_destination=%2Findex.action
but from Okta applications I am able to access Confluence.
Appreciate your support
I ran into all of the issues above even after adding the the same value for link.login.url the users were not getting logged in correctly. I eventually found out that the user who setup the application connector in Okta set the username value incorrectly. After I set it to use the AD SAM account name and triggered the update Application User name in Okta the SSO is working as it should.
The way Okta implements this is kind of braindead, unfortunately. There should be documentation you can look at in the Okta admin portal (the public documentation is ancient.) Basically you need to modify the login.jsp page code to do a redirect to Okta. It seems you skipped that step.
I would recommend using a 3rd party App from Marketplace instead. We really like the Aps from Resolution.de, and their customer service is excellent. They aren't free, but you don't have to do hackery to the Confluence code. This makes upgrading easier. They also allow you to use the Internal user directory, which the Okta provided method does not.
thanks for recommending our plugin.
@Ben_Shirley I appreciate you want it get up and running with the OKTA's own JAR file. And Dave's answer is right - you need to modify the login.jsp
I know there are many people using the OKTA Jar happily but there is also quite a few which move to a commercial plugin for support / feature reasons.
So if that is an alternative for you - it would be great if you look at our plugin too. Not just because we are the most installed one - but because we allow you to actually synchronise Users & Groups from OKTA - similar to Atlassian's LDAP sync. So it's a real synchronisation not just creating the User during the first login (and never disabling it) that OKTA's JAR does or most of the other SAML Plugins in the Marketplace.
Here is a Guide Link to our Guides for OKTA: https://wiki.resolution.de/doc/saml-sso/latest/all/setup-guides-for-saml-sso/okta
Here is the specific one for with the User Synchronisation: https://wiki.resolution.de/doc/saml-sso/latest/all/setup-guides-for-saml-sso/okta/okta-with-user-sync
Also if you want to stick with OKTA's JAR but really would like to have the User Synchronisation that is possible too. We have also published that functionality as Standalone in the Marketplace for these kind of use cases:
P.S. Full disclosure - if it wasn't obvious already - I work for resolution, a marketplace vendor
I work for miniOrange, one of the top SAML SSO solution vendors for Atlassian. You can try our app to configure SAML SSO with Okta. It's easy to set up and the end to end setup can be done in just a few minutes.
Once configured, you can set it up so that all the unauthenticated traffic on Confluence or Jira will be redirected to Okta for SSO.
Here are the step by step guides for an end to end SSO Setup with Okta:
You can generate a free trial license for the apps here:
If you face any difficulty during the setup, you can raise a support request from the plugin itself or send us a query at email@example.com
We'll schedule a call with you to assist you in setup.
If you are going to use only our SAML authenticator (ours is a 5-in-1 solution) - we provide discounts for this specific case to recognise that the extra costs our app has embedded in the price when used with NTLM and Kerberos, are not required for SAML, X.509 and HTTP headers authenticators.
Our support is 24x7. Feel free to reach out to us if you have any questions.
Hello Confluence Community! What if i told you that you could have a healthier life and be 100% meet-less? This month, we're promoting a healthy, balanced work diet with Confluence. We la...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events