Kount customers can integrate Single Sign-On (SSO) technology to authenticate end-users that have been provisioned through their Identity Provider (IDP) within Kount. Kount utilizes an integration with Okta to integrate OAuth2.0/OpenID Connect by following the Okta Authorization Code flow.
Kount allows SSO integration for customers who use SAML (Security Assertion Markup Language) and other authentication standards. The just-in-time (JIT) user-provisioning allows automatic end-user creation within the Agent Web Console (AWC) when an end-user tries to log in the first time. Additionally, the Profile and Group assignments are updated each time the end-user logs in.
Production/Test Environment Checklist
Kount sets up and enables the service provider environment to receive the SAML assertion and provide the following to the IDP (the steps are the same when setting up your test and production environments):
- Assertion Consumer Service URL
- Audience URI
- Kount SSO Integration Guide
- Kount SSO Metadata File
- Kount SSO Certificate
- Your IDP
- SAML assertion, including group attributes
Once the IDP configuration is complete, send the following to Kount:
- IDP Issuer URI
- IDP Single SSO URL
- IDP Signature certificate .pem file
AWC End-User Management Changes
Once SSO is enabled, the third-party IDP becomes the authoritative source for end-user data. The following end-user management functions in AWC are disabled:
- User creation and editing is disabled
- Password reset and password change is disabled (Including password self-change)
- User account lock/unlock is disabled
- Profile self-edit is disabled (no social links)
SSO Merchant Configuration
Information checklist: before you start
|SSO/Okta Feature enabled at Kount||This is a setting at Kount that allows the Okta SSO to be enabled for a customer.||
The feature flag can be enabled at Kount by Customer Success.
Note: New users cannot be created within AWC if this flag is enabled.
This feature could incur an additional cost, check with your Kount Account Manager
|Email Domain Mapping||
This value is set by the Customer Success Manager.
Provide a list of email domains that a customer's end-users use.
This step is necessary to associate new end-users with the customer's account.
Domains must be unique across customers (deleted entries are not counted), meaning the domain cannot be a common email domains (like yahoo.com, gmail.com, etc.).
Validated against regex:
|Group Assignment||User roles are based on group assignment and some planning and configuration is required for expected behavior.||
Setting up groups in their IDP allows mapping to Kount permission roles.
Group Planning and Setup for SSO Customers
The third party IDP must identify and coordinate with Kount how they plan to configure groups for their SSO users. The SAML assertion should be configured to pass user's group assignments to Okta and then on to Kount Portal. Okta will only pass on groups that match a configured filter, and Portal will only recognize groups that match names of existing groups in Kount.
Requirements for passing group assignment to the Kount Portal
The customer's SAML IDP must pass on an attribute called groups in the SAML assertion, which specifies the groups assigned to the end-user.
See line 40 in the following SAML assertion example:
SAML Assertion Example
<?xml version="1.0" encoding="UTF-8"?>
<saml2:Conditions NotBefore="2018-10-15T20:12:32.249Z" NotOnOrAfter="
<saml2:Attribute Name="firstName" NameFormat="urn:oasis:names:tc:
<saml2:Attribute Name="lastName" NameFormat="urn:oasis:names:tc:
<saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:
<saml2:Attribute Name="groups" NameFormat="urn:oasis:names:tc:SAML:
type="xs:string">GroupName Match Starts with "Kount" (ignores case)
In SSO mode, the customer's IDP becomes authoritative for group assignment and user profile info. Therefore, group assignment should be managed in the customer's user directory and will be reflected in Kount Portal at the next login.
Group Mapping Planning
There are two options for group mappings.
Option 1: Create groups in IDP which match the Kount groups
If the merchant plans to take advantage of all 10 of the default Kount groups, they would need to set up groups in their user directory of the following names.
- Kount Manager
- Kount Employee
- Kount Account Manager
- Kount Lead Agent
- Kount Risk Editor
- Kount News Editor
- Kount Agent Manager
- Kount KSM
- Kount Agent Plus
- Kount Admin
- Kount Agent
Option 2: Create custom/composite group in Kount that match specific group names
This is appropriate if the customer only planned on using a couple types of users, but the mechanics of the mappings remains the same.
The Customer Service Manager for the customer creates new custom groups and manually assigns appropriate roles. Group names match the customer's group names without the Kount prefix.
Configuring SSO for Kount Command
You can integrate SSO into Kount Command using several different IDPs. The examples shown in this document use Okta, but the steps would be similar for other IDPs.
- Obtain the SAML metadata file from your Kount Implementation Engineer.
Note: Kount provides the SSO URL, Audience URL, and
.pemfile (generated from Okta).
- Fill out the SAML Settings General form with the values provided by Kount.
- Enter the following values:
- Name ID format: Unspecified
- Application username: Okta username
- Update application username on: Create and update
- Attribute Statement Section
firstName: Name format: URI Reference. Value: user.firstName
lastName: Name format: URI Reference. Value: user.lastName
email: Name format: URI Reference. Value: user.email
- Group Attribute Statements
Confirm there is one entry called groups. This ensures that the end-user’s groups are brought over called groups in the assertion. Refer to Group Planning and Setup for SSO Customers.
- Log in to the AWC as typical end-user, (this end-user must have been added before SSO feature was enabled within Kount).
- Provide email domains that are used within the Kount instance for each unique email domain.
Note: Only the domain part of the email is required (e.g. kount.com).
.pemcertificate generated through your IDP back to your Customer Success Manager.
- Test the login to AWC by user in IDP. Kount does not validate anything in the IDP except for whether it has been populated. If there is no IDP ID populated in the AWC, the SSO feature will fail to work.
Frequently Asked Questions
What does the end-user experience look like?
- Log into the AWC.
Note: The login page displays a message about SSO and the end-user is redirected to the Okta Login Widget.
- Enter the IDP email address, and then click Start Login. A status indicator appears as the customer information is retrieved and validated.
- Once the retrieval is completed and the end-user is logged into their IDP, the end-user is then redirected.
Note: If the end-user is not logged in to their IDP, they are prompted to log in. The end-user is then returned to the AWC SSO page and sees a message that their login is being validated.
- Once complete, the end-user is redirected to the AWC dashboard.