All Collections
IT Departments
Single Sign-On (SSO) Configuration
Single Sign-On (SSO) Configuration

How to integrate Single Sign-On (SSO) with your institutions identity provider (IDP)

Jacob Robinson avatar
Written by Jacob Robinson
Updated over a week ago

Knack uses Single Sign-On (SSO) to integrate with your institution's identity provider (IDP) to enable on-demand creation of User accounts, simplify User account management with the elimination of password creation for Users, and invoke your institution's required security policies maintained on the IDP (e.g., 2-factor authentication (2FA)).

Knack uses Keycloak as an identity broker and has integrated with many types of identity providers including Shibboleth, Active Directory Federation Services (ADFS), Azure Active Directory, custom SAML providers, and more.

Supported Protocols

  • SAML 2.0

  • OpenID Connect 1.0

Attributes

  • NameID - persistent ID desired but transient ones can be supported if there's another persistent attribute that can be utilized

  • First Name - givenName

  • Last Name - sn

  • Email - mail

  • Student ID - eduPersonUniqueID

  • Other attributes may be required depending on the scope of the engagement

Commonly used names for attributes are listed. Knack can handle mapping these, or any custom attributes, to any incoming name as needed.

Configuration

  • Assertion and AuthnRequest signing is supported

  • Encryption is supported for Assertions and can be enabled if required by your IDP

Configuration Process

The SSO setup process is typically accomplished asynchronously but can also be worked through simultaneously on a call as needed.

  1. Your Knack Partner Executive will initiate communication between the provided IT contacts at the institution and Knack's engineering team to start the setup

  2. IT contacts should provide identity provider (IDP) metadata to Knack to reference for setup

  3. Knack configures a unique Service Provider (SP) endpoint for your IDP based on the provided metadata and configures mapping of attributes

  4. IT contacts should then configure the SP set up on their side

  5. The basic integration between Knack's identity broker and the IDP can then be tested. This is only a test against the identity broker and is not something that is seen by end-users of our applications. No end-user accounts are created through this test flow:

    • Access this link https://login.joinknack.com/auth/realms/knack/account/ and select your institution's name on the right side to initiate a test login

    • Log in with your identity provider

    • If successful, this will land you in a simple portal that displays the properties of the user that logged in; all the fields should be populated

    • If a failure occurs, Knack can inspect the SAML response received, since naming and mapping of attributes is often the problem

  6. Once the setup has been tested, additional configuration is performed on Knack's side to make it available to end-users

Did this answer your question?