aHere is a step-by-step guide on how to setup Sana as a SAML 2.0 application in Okta.
SSO configuration with Okta
Create and configure a new app integration
1. Create a new SAML 2.0 App Integration
2. Enter the desired app name and optionally upload app logo, and then press Next.
3. Enter the following information to the respective fields in the SAML Settings screen replacing example with the actual domain you got from Sana.
Single sign on url: https://example.sana.ai/x-realtime/auth/saml/acs
Audience URI (SP Entity ID): https://example.sana.ai/x-realtime/auth/saml/metadata
4. Add the following attributes with the exact casing
email : user.email
firstName: user.firstName
lastName: user.lastName
The attribute statements must exactly match the above settings, otherwise accounts will not be created in Sana when a SAML request is sent. The configuration should look as follows afterwards:
If things are configured on Sana, you can press the “Preview the SAML Assertion” response button at this stage and see an assertion response.
When everything is ready, press Next.
5. In the feedback form, select “I'm an Okta customer adding an internal app” and provide feedback if you like to.
6. When creation process is finished, you will be redirected to the newly created apps Sign On tab. On the bottom right, click “View SAML setup instructions” button where you will get the following screen:
7. Provide your Integrations Specialist or Engagement Manager at Sana with all the information here:
Identity Provider Sign-on URL
Identity Provider Issuer
X.509 Certificate
8. We will set your Sana app with this configuration and then you can test the setup at your domain at https://<example>.sana.ai or by simply testing directly from your Identity Provider (IdP).
Troubleshooting Common Issues
1. User is not assigned to the client application
This means that your company's IT team has not added you to your company's Okta instance. To resolve this, you'll just need to ask your company's IT team to add you to Okta.
2. No attribute value for email, firstName, or lastName
This means that the configuration was set up incorrectly. Please double-check and ensure that the format of the attribute statements matches what is specified in Step 4 above.
3. Invalid Credentials or Ticket
Ensure that the system clocks of the IdP and SP servers are synchronized. Significant time differences can cause SAML assertions to be rejected. If there is a significant difference (clock skew) between the IdP's and SP's system clocks, even a valid assertion might be rejected. For example, if the SP’s clock is ahead of the IdP’s clock, it might see the NotBefore time as being in the future and reject the assertion as not yet valid.