Skip to main content
owlie
Sign Up Free

Configure Okta SAML SSO

Who this is for​

Okta and Owlie administrators configuring Okta as the SAML identity provider for one Owlie tenant.

Goal​

Create an Okta SAML application with Owlie's tenant-specific SP values and complete a test login.

Prereqs​

  • Okta administrator access
  • The SAML SSO overview
  • An Okta test user whose primary email belongs to an Owlie allowed domain

Success criteria​

Choosing the configured SAML label in Owlie redirects to Okta and returns an authenticated session to the same Owlie tenant.

Create the Okta application​

  1. In Owlie, open Tenant Settings → Authentication → Login methods and copy the ACS URL and SP entity ID.
  2. In Okta Admin Console, open Applications → Applications, select Create App Integration, choose SAML 2.0, and continue.
  3. Give the application a recognizable name such as Owlie - Production.
  4. Set Single sign-on URL to the Owlie ACS URL and Audience URI (SP Entity ID) to the Owlie SP entity ID. Keep the values byte-for-byte exact.
  5. Set Name ID format to EmailAddress and Application username to the user's email.
  6. If needed, add profile attribute statements for email, given name, surname, and display name.
  7. Finish the application and assign the test user.

Configure Owlie​

  1. From Okta's application Sign On setup instructions, copy the Identity Provider metadata URL.
  2. In Owlie's SAML 2.0 panel, enable SAML SSO, set a Display label, add Allowed domains, and choose Metadata URL.
  3. Paste the URL and select Fetch metadata. In Confirm SAML metadata trust, compare the current and incoming entity ID and SSO host, then verify the signing certificate's SHA-256 fingerprint, subject, and expiry. Owlie deliberately does not verify metadata signatures in v1.
  4. Select Confirm and save trust. Owlie re-fetches and refuses to save if the trust changed after preview. Choose the appropriate email-trust and JIT settings, then select Save changes for any remaining edits.
  5. Open https://<tenant>.<root-domain>/auth/login in a private window and choose the Okta label.

Default configuration​

  • Use Okta's primary email as NameID and metadata import for initial setup.

When to change it​

  • Add explicit Owlie attribute mappings only if Okta uses custom claim names.
  • Select Refresh metadata when Okta rotates signing certificates; Owlie does not poll it. During an overlap, an unusable old certificate is skipped while a valid sibling remains usable.

Impact and risks​

  • An Okta app assigned to the wrong people broadens who can attempt sign-in; Owlie's allowed domains and JIT setting still determine whether an identity can be created.

Example​

An Owlie - Production app uses the production tenant's ACS/entity ID and assigns a pilot Okta group before organization-wide rollout.

Troubleshooting​

  • Audience or recipient error: compare Okta's audience and SSO URL with the Owlie panel exactly.
  • Unknown certificate: refresh Okta metadata after a planned certificate rotation.
  • No Owlie account: enable JIT or pre-create the identity with the same email. If SAML links were reset while asserted-email trust is off, automatic linking is deliberately refused; the reset cannot merge duplicate identities.

Assumptions & Questions​

  • Okta labels above reflect the current Admin Console. Confirm them against your Okta edition and record any tenant-specific claim transformation.

Next steps​