Don't see Configuration -> Settings -> Okta in 3.16.7

hi there,

We just upgraded to 3.16.7 in an aim to enabling OKTA. However, we don’t see “Settings” under Configuration:

Was the UI option added later than 3.16.7?

Thanks,
Dong

Hi @dong_xue,

Thanks for getting in touch!

Support for Okta was added in 3.16.0, however, at this point the only way to configure any of the external auth providers was via the octopus.server.exe configure command as detailed here: https://octopus.com/docs/security/authentication/okta-authentication#Oktaauthentication-ConfiguringOctopusDeployServer

The ability to configure this via the UI is available in 4.0.11 and later.

Regards,
Paul

Thanks Paul for letting me know this so quickly.

1 Like

Hi Paul,

One more question, for the call:

Octopus.Server.exe configure --OktaIsEnabled=true --OktaIssuer=Issuer --OktaClientId=ClientID

would setting “–OktaIsEnabled=fals” bring us back to the original authentication safely? We may need to test the enabling Okta out during off hours and would like to be assured that if necessary, we would be able to return to the original state without Okta.

Thank you!
Dong

When you enable the okta authentication initially, the current username and password login method will also remain active so you can continue to login using that method as a fallback option.
Once you are happy that the new auth method is working you can disable this using octopus.server.exe configure --usernamePasswordIsEnabled=VALUE

Regards,
Paul

Hi Paul,

Thanks for that.

Could you explain “–oktaClaimNameType” a bit more for me please, maybe some use cases? The reason I am asking is because we have a corporate account in OKTA (mycompany.okta.com) and our employees’ emails are like “@mycompany.com”. However, our Octopus Server was installed and configured with a different domain (myoctopusdomain.com) and all users sign in Octopus with the names from the second domain, e.g. “joe@myoctopusdomain.com”. These Octopus users were registered in Octopus with their normal corporate emails however.

We are not too sure if Okta is going to work if we keep everything as default.

Any insight would be greatly appreciated,

Dong

Sure, this is from the UI description of that field, which is a little clearer:


Essentially, Octopus will be attempting to match the Octopus Username field against the Okta preferred_username claim.

What this means is that Octopus treats the local Username as a fixed point, for your scenario, the second domain (x@myoctopusdomain.com) will need to exist somewhere within the Okta profiles in order for Octopus to perform a match.

Or, you will need to update the Octopus usernames to match what is already in Okta.

Hi Paul,

Based on the following statement from your documentation, I think we are going to be OK because the Emails are the same from our Okta account as well as our Octopus user account.

“Already have Octopus user accounts?
If you already have Octopus user accounts and you want to enable external authentication, simply make sure the Email Address matches in both Octopus and the external identity provider. This means your existing users will be able to sign in using an external identity provider and still belong to the same teams in Octopus.”

We are going to give it a try as long as we are guaranteed to be able to roll back to the previous logging method without Okta if necessary. Thoughts?

thank you!
Dong

That’s correct, you can enable and disable it using the above method without any issues.