Skip to main content
All CollectionsSettingsIdentity Provider
Configuring Single Sign On in Kno2
Configuring Single Sign On in Kno2

Setting up Identity Providers for SSO

Stacy Lane avatar
Written by Stacy Lane
Updated over 8 months ago

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.

Network

Select your desired Identity Provider (supported SSO Identity Providers are Microsoft Entra ID (Formerly known as Azure AD) and Okta).

Identity Provider

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.

Example Microsoft Entra ID Configuration Values

Entra

Example Okta Configuration Values

Okta

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

Metadata URL

(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.

Authentication Settings

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.

Save

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

SSO Integration Activated

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

  1. For user management - users are managed in two places.

    1. The Network Administrator must complete the following for users that login via the SSO URL:

      1. Create and manage users in their IdP. Only users created in the IdP can login using SSO.

      2. Create and manage users in Kno2. Users that exist in the IdP but not in Kno2 will not be granted access. The username must match in both systems.

      3. Send the SSO URL to all users that should login via SSO.

      4. 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.

Authentication Settings

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 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

  1. A user has logged on to the IdP.

  2. The user requests access to a protected SP resource. The user is not logged on to the SP site.

  3. Optionally, the IdP retrieves attributes from the user data store.

  4. 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

  1. The user requests access to a protected SP resource. The request is redirected to the federation server to handle authentication.

  2. 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.

  3. 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.

  4. 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)

  5. 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.

  6. (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.

Did this answer your question?