SAML with Okta

This guide walks through configuring Okta as the identity provider for a Kindo SAML connection. It assumes you have a SAML connection set up in SSOReady — typically through the self-serve setup link described in Single Sign-On (SSO) Setup — and shows where each value in Okta comes from and where it goes.

Create an application in Okta

Okta mediates all login interactions through an Application. Once you finish setting it up, your users may see it as a tile in their Okta accounts.

1. An Okta administrator selects Applications > Applications in the left navigation panel.

   

2. On the page with the bold Applications header, select the dark blue Create App Integration button right under the header.

   

3. In the modal that appears, select the SAML 2.0 radio option, then press Next in the lower right corner.

   

4. The header changes to Create SAML Integration. Give the application a display name — Kindo, or your own name for the Kindo deployment.

   

5. The remaining options on this page aren’t especially important; select Next, which finalizes creation of the application and moves you to the SAML settings.

   

Enter SSOReady details in Okta

Hitting Next lands you on the Configure SAML tab. Both required values come from the SSOReady page for your SAML connection.

1. At the top of the page, Okta asks for a Single sign-on URL. SSOReady calls this the Assertion Consumer Service (ACS) URL; it ends in /acs. Copy it from SSOReady and paste it into Okta’s Single sign-on URL field.

   

2. The next field reads Audience URI (SP Entity ID). SSOReady calls this the SP Entity ID; it sits directly under the ACS URL in SSOReady and usually looks just like it, minus the /acs ending. Copy it from SSOReady and paste it into Okta’s Audience URI (SP Entity ID) field.

   

3. Before leaving this tab, scroll down to Attribute Statements and add these three attributes, so the SAML assertion carries what Kindo expects. SSOReady does not rewrite incorrect incoming SAML attributes on your behalf; without a correctly mapped email attribute, login and JIT (Just-In-Time) provisioning fail.

   Name	Value
   email	user.email
   firstName	user.firstName
   lastName	user.lastName

   

4. Scroll down and hit Next in the lower right corner.

5. Okta closes with a brief feedback form. Select I’m an Okta customer adding an internal app, skip the remaining questions, scroll down, and press Finish.

   

Enter Okta details in SSOReady

Finishing the wizard routes you to a page with your application’s name at the top. SSOReady needs three pieces of information from it: a Redirect URL, an IDP Entity ID, and a Certificate.

1. Scroll down a bit and hit More details — it’s not always easy to see.

   

2. Directly under the More details button, there’s a URL marked Sign on URL with a Copy button. SSOReady calls this the Redirect URL. Copy it and paste it into SSOReady as the Redirect URL.

   

3. Scrolling further down, you’ll see a similar line for a URL Okta labels Issuer. SSOReady calls this the IDP Entity ID. Copy it and paste it into SSOReady as the IDP Entity ID.

   

4. Finally, SSOReady requires a certificate. Further down on the same page, Okta labels it the Signing Certificate. Press the rectangular Download button, which downloads an okta.cert file, and upload that file to SSOReady as the Certificate for this SAML connection.

   Note

   Okta shows several related buttons on this page that do not produce what SSOReady needs — use the Download button on the Signing Certificate row.

   

Once you’ve uploaded the certificate, the SAML configuration is complete. Confirm the connection appears in SSOReady’s connection list as described in Single Sign-On (SSO) Setup.

Caution

Users cannot sign in until an Okta administrator assigns them to the application.