If you have purchased Single Sign On (SSO) and the feature has been enabled by the Kno2 team, a Kno2 Network Administrator should complete the following steps.
Configure Identity Provider Settings in Kno2
Navigate to Settings > Network > Identity Provider.
Select your desired Identity Provider (supported SSO Identity Providers are Microsoft Entra ID (Formerly known as Azure AD) and Okta).
Once you’ve selected an Identity Provider from the dropdown, all values necessary for setup will be displayed. Click on the clipboard icon or manually copy the values for the next step.
Configuring Your Identity Provider Portal's Settings
Using the values copied from Kno2, configure your Identity Provider settings.
Please note: Kno2 supports Service Provider (SP) initiated login.
Identity Provider | Configuration Instructions |
Microsoft Entra ID | Microsoft Configuration: https://learn.microsoft.com/en-us/entra/identity/saas-apps/kno2fy-tutorial Entra ID and Kno2fy Configuration: Microsoft Entra ID Configuration for Single Sign On | Kno2® Knowledge Base (kno2fy.com) |
Okta | Okta Help Center: Okta Help Center (Lightning) Okta and Kno2fy Configuration: Okta Configuration for Single Sign On | Kno2® Knowledge Base (kno2fy.com) Video Tutorial: Kno2 Product Walkthrough: Setting up SSO with Okta (loom.com) |
Example Microsoft Entra ID Configuration Values
Example Okta Configuration Values
Finalize Identity Provider Configuration in Kno2
Your Identity Provider portal should provide a Metadata URL upon completion of configuration. Copy the URL into your Kno2 Metadata URL field to complete setup for your Identity Provider and SSO. This allows Kno2 to automatically retrieve certificate and other connection data.
Example Metadata URL
https://login.microsoftonline.com/contoso.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml
Metadata URL field
(Optional) Turn on non-SSO login
Once an Identity Provider has been configured, you can enable the ability for non-administrator users to login without SSO. This allows them to continue to login using their Kno2 username and password.
Please note: If the above setting is not enabled, if a user attempts to sign in without SSO, they will receive a generic error.
Save the Identity Provider Configuration
Click Save to finalize the Identity Provider configuration.
Copy the SSO Login URL
Once configured, a URL will appear at the top of the screen. Provide this link to your users to allow them to login with the new SSO setup.
Example SSO Login URL
https://app.kno2fy-test.com/account/login/starklabs-3
Connection Name
For networks that utilize SSO and Kno2 Desktop, a connection name is needed for setup.
The connection name can be found during Identity Provider configuration. Everything after the final colon in Identifier is the connection name.
Example Connection Name
https://app.kno2fy-test.com/account/login/starklabs-3
The connection name is starklabs-3
Managing SSO without SCIM setup
For user management - users are managed in two places.
The Network Administrator must complete the following for users that login via the SSO URL:
Create and manage users in their IdP. Only users created in the IdP can login using SSO.
Send the SSO URL to all users that should login via SSO.
If the network is configured to allow standard Kno2fy login, any existing user logins will continue to work as expected, even after SSO is turned on.
When terminating or disabling users, the Network administrator should update the user account in both the IdP and the Kno2 system.
When updating usernames, the Network administrator must update both systems as well.
Any organizations that are connected to the network after SSO configuration is in place will inherit all of the network configurations.
IDP vs SP Initiated SSO
Note that the system only supports SP Initiated SSO due to security concerns. For more details regarding the difference, please see below.
IDP vs SP Initiated SSO Differences
IDP vs SP Initiated SSO Differences
IDP Initiated SSO
From PingFederate documentation: We’re here to help
In this scenario, a user is logged on to the IdP and attempts to access a resource on a remote SP server. The SAML assertion is transported to the SP via HTTP POST.
Processing Steps
A user has logged on to the IdP.
The user requests access to a protected SP resource. The user is not logged on to the SP site.
Optionally, the IdP retrieves attributes from the user data store.
The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.
SP Initiated SSO
From PingFederate documentation: We’re here to help
In this scenario a user attempts to access a protected resource directly on an SP Web site without being logged on. The user does not have an account on the SP site but does have a federated account managed by a third-party IdP. The SP sends an authentication request to the IdP. Both the request and the returned SAML assertion are sent through the user’s browser via HTTP POST.
Processing Steps
The user requests access to a protected SP resource. The request is redirected to the federation server to handle authentication.
The federation server sends an HTML form back to the browser with a SAML request for authentication from the IdP. The HTML form is automatically posted to the IdP’s SSO service.
If the user is not already logged on to the IdP site or if re-authentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on.
Additional information about the user may be retrieved from the user data store for inclusion in the SAML response. (These attributes are predetermined as part of the federation agreement between the IdP and the SP)
The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP. NOTE: SAML specifications require that POST responses be digitally signed.
(Not shown) If the signature and assertion are valid, the SP establishes a session for the user and redirects the browser to the target resource.