Tags | SAML | Authentication | SSO | Okta |
ADMIN PRIVILEGES REQUIRED
This documentation is for Stack Overflow for Teams Enterprise. Free, Basic, and Business users can access their documentation here. Find your plan.
Overview
These instructions describe how to integrate your Stack Overflow for Teams Enterprise (SOE) site with Okta as your identity provider for authentication. Once configured, your users will be able to use Okta and the Security Assertion Markup Language (SAML) for Single Sign-on (SSO) authentication into your site. You can learn more about SAML in our SAML Authentication Overview document.
THIS ARTICLE APPLIES TO STACK OVERFLOW FOR TEAMS ENTERPRISE ONLY.
Other Stack Overflow for Teams users should read this article instead. Find your plan.
NOTE: In SSO terminology, Okta is the identity provider (IdP) and your SOE site is the service provider (SP). We'll use the terms IdP and SP throughout this article.
SOE supports the following features with Okta:
IdP-initiated SSO
SP-initiated SSO
Just-in-time provisioning
Force authentication
When setting up SAML authentication, you'll configure your SOE site and the Okta IdP in a back-and-forth process. We recommend having a browser tab open to each site.
NOTE: To configure SSO with Okta, you'll need administrator access to both Okta and SOE.
Create a new Okta SAML application
In Okta, click Applications, then Create App Integration.
Choose SAML 2.0 as Sign-on method.
On the "General Settings" tab, enter an App name. If desired, upload an App logo.
Configure Okta SAML settings
On the "Configure SAML" tab, configure the following fields:
Single sign-on URL Enter your SOE SAML URL (https://[your_site].stackenterprise.co/auth/saml2/post).
Audience URI (SP Entity ID) Enter any unique value. We suggest using your SOE SAML URL (same as above: https://[your_site].stackenterprise.co/auth/saml2/post).
Default Relay State Leave blank.
Name ID format Select Unspecified.
Application username This field identifies the user record, so set this to a user attribute that is unique and will never change (for example: Okta username).
NOTE: It's important to select an Application username source field that is both unique and unchanging. A user's email address, for example, is unique but not unchanging (an updated email address would result in SOE creating a new, duplicated account for that user).
Set attribute statements
Attributes are user information values passed from Okta to SOE as part of the login process. You'll need to define at least two SAML attributes: user email and name. This involves giving each attribute a name (which you'll later enter into SOE) and choosing which Okta values to attach to each attribute.
Define the SAML attributes Name and Value as follows:
email The user's email address. Set Value to user.email.
displayName The user's name as it should appear in SOE. If you have a custom Okta field with the full user name, set Value to that field. You can also concatenate fields using the
${user.firstName} ${user.lastName}
formula.
You can also define optional user job title and department attributes. Populating and sending these attributes on login allows you to use SOE's Connectivity feature.
jobTitle (optional) The user's job title. Set Value to user.jobtitle.
department (optional) The user's department. Set Value to user.department.
After configuring attributes, click Next.
Save and test SOE SAML settings
To complete the SSO setup, click Save Settings on the SOE authentication settings page.
When saving settings, SOE will first perform an authentication test. If the test succeeds, SOE will apply your new authentication settings. Logged-in users stay logged in, as all active user sessions remain valid.
If the test fails, SOE will not apply the authentication settings. You'll stay on the SAML settings page so you can troubleshoot and correct problems. This test acts as a safety net to keep invalid authentication settings from locking users (yourself included) out of your site.
You can also click Test currently saved SAML configuration to display technical details about your SAML authentication. You'll find these helpful for understanding what information your IdP and SOE exchange.
Forced authentication (optional)
You can force your users to sign in with SSO every time they log in by telling SOE to ignore previous user authentication sessions. To do this, you'll need to change configuration settings in both Okta and SOE.
In the Stack Overflow Enterprise Application in Okta:
Go to the "Sign On" tab.
Click Edit Settings.
Uncheck the Disable Force Authentication option.
Go to the SOE admin settings "Authentication" menu.
Under "Security settings", check Force reauthentication.
SP-initiated SSO
Once you've fully configured your Okta application, the user sign-in process will start with your SOE site and proceed as follows:
The user navigates to your SOE site (https://[your_site].stackenterprise.co), which initiates the sign-in process.
The Okta sign-in page appears, prompting the user to sign in with their Okta credentials.
If the user credentials are valid, Okta redirects the user to their home page on your SOE site.
Getting help
Properly configuring SAML authentication can be tricky. For more information on troubleshooting, see the SAML Authentication Troubleshooting article. You can also reach out to Stack Overflow support for help.