Single Sign On

Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using.

Koddi can leverage your enterprise/application SSO provider to sign into the Koddi platform as well. Your Koddi team will help you get this configured as part of the implementation process.

Koddi can support the following SSO solutions:

  • Auth0
  • Google Workspace
  • Microsoft Azure Active Directory
  • Microsoft's Active Directory Federation Services (ADFS)
  • Okta
  • OneLogin
  • Salesforce
  • Others as needed

Configuring Koddi as SAML Service Provider

To configure Koddi as the service provider (SP) in a SAML federation, you will need to create a connection with Koddi and then update your SAML identity provider (IdP) with the connection's metadata.

You'll need to collect some configuration metadata from the IdP to create a connection with Koddi:

  1. Sign In URL: The URL where SAML authentication requests are sent. This is also called the single sign-on (SSO) endpoint.
  2. Sign Out URL: The URL where SAML logout requests are sent. This is also called the single logout (SLO) endpoint.
  3. X509 Signing Certificate: The public-key certificate required by the SP to validate the signature of the authentication assertions that have been digitally signed by the IdP. Koddi accepts the .pem and .cer formats.

🚧

Your Koddi team will share a secure way to send us this information.

Using SSO with Embeddables

If you are using a Koddi embeddable, you can use the token endpoints to authenticate for the embeddable.

Koddi embeddables utilize window.postMessage for receiving messages with an auth token. This method provides a way to safely send cross-origin messages between window objects. It allows a parent page to send messages to a page contained within an embedded element. The method also provides a way to specify the origin of the request. The application using the embedded element specifies where the token should be sent and the Koddi embeddable can check where the message was sent from to ensure we’re only responding to messages from valid origins.

Once the Koddi embeddable receives a message from a valid origin, we will store the token. The Koddi embeddables can then use the token to make authenticated requests.