Onna offers Single Sign On (SSO) integration through SAML 2.0 (Secure Assertion Markup Language) with a variety of compliant identity providers allowing you to leverage your existing user base and authentication mechanism to use the platform. There are only a few steps required to configure your IdP using the Onna Admin dashboard. 

This guide walks you through setting up Onna as a Service Provider (SP). You will fill-in information about your Identity Provider (IdP), the external 3rd party which your users will sign-in through and will return credentials back to Onna in the form of a SAML assertion. On the other end, you will also need to configure your IdP to establish communication with the Onna SP.

To get started, login to the Admin dashboard with the proper administrator user and click on the Preferences tab:

Head to the Configuration tab in the second menu. This will show the following page

Expand the SAML option by clicking on it. This will reveal the following fields: 

The following settings are configurable under the SAML section.

IDP Issuer: The identity provider’s URL

SSO URL: The single sign on URL of the SAML Identity Provider Login page that your users will be redirected to for logging in.

Certificate: The public x509 certificate of the SAML Identity Provider.

The next step is to configure your IdP so that it can establish communication with the Onna on-premise service provider. There are only a few items you need to fill in with the main ones shown below. Please replace {your-domain} with your actual domain name:

Onna Audience Restriction URL: https://onna.{your-domain}/auth/oauth/saml/metadata?idpId={IdPName}

Onna SAML Assertion Consumer Service: https://onna.{your-domain}/auth/oauth/saml/?acs

Name id format:

The required nameid format is "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", so an email address is needed to identify the user in the system.

In case the userId is an employeeNumber or some other kind of id, an attribute is required instead of the email address so we can identify the user correctly in the system. That attribute should be called "user_id".

Optional attributes

  • user_id : To be used in case the userId is not the email address
  • sn:  Surname
  • cn: Common Name
  • email: To be used in case the userId is not the email address

Example configuration below (okta):   

Did this answer your question?