SAML Support in Kenna for Single Sign On

Kenna Support for SAML requires configuration on both the Kenna and customer side of the connection including the exchange of Issuer and Identity Provider information. 
Basic requirements of our implementation:
1. NameID is required as part of the SAMLReponse object.
2. The assertion must contain an email address. Attribute field names must be one of the following:
This sometimes may need to be added as a custom attribute in your Identity Provider configuration.
Users are created in Kenna using the email address that corresponds with the SAML userid. An email is sent to the user advising them that they have been added to the platform and can connect using their SAML credentials. 
Configuring your Identity Provider service:
From your SAML provider, you will need to configure Kenna's "entity ID (sometimes referred to as "issuer"), which should be:

You will also need to send us a copy of your public X.509 certificate, or the URL for your metadata.xml, which contains it.  We will use that to generate a fingerprint to validate your SAML responses.

You will need to provide us with your IdP SSO Target URL, which is the URL we will route your unauthenticated users to for authentication.

There will also be an "assertion consumer service (ACS) URL", which is where your SAML provider will post back to, which is:
Note: Kenna will provide the value of UUID.
Once you've sent us your X.509 cert and IdP SSO Target URL, we can complete the fingerprinting and enable SAML on our side.  By default, we only allow either password or SAML authentication, but not both.  Support can help temporarily enable both authentication methods during your transition period.
Note that Kenna does not have an explicit metadata.xml, which some Identity Providers require when creating a new 3rd party service. If required, please contact your Identity Provider support for assistance on generating a metadata.xml for use with Kenna. Please also note that Kenna does not encrypt the assertion or sign the SAML request, however the traffic itself is still encrypted via https/tls.
Enabling SSO authentication on your Kenna account:
When this is first enabled on your account, we'll keep your direct login form enabled, so that users are still able to access Kenna in the event they experience issues with the SSO connectivity. Once you're comfortable with your SSO authentication to Kenna, you can contact support to have the direct login form disabled; this will require all Kenna users to log in via SSO.
Once SSO is enabled on your Kenna account, the following features will immediately be disabled (even while the direct login form is enabled):
  • New user password setup emails: new users will instead receive a notification that they have an account in Kenna, but will not be able to set a password (as SSO is enabled). For this reason, it is recommend you do not create new Kenna users until you have verified SSO is working as expected in your Kenna account
  • Password reset functionality: existing users will not be able to reset their password on the direct login forms. If this becomes an issue, please contact Kenna support.
Contact (or click here to submit a ticket through the Help Center) to retrieve your Client ID and to enable SAML for your account.
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.