How to Integrate SSO into Kount Products

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

"^(?:[-A-Za-z0-9]+\.)+[A-Za-z]{2,10}$^"

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:

<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="
id3363847264745707556871537" IssueInstant="2018-10-15T20:17:32.175Z"
Version="2.0">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>http://www.okta.com/Issuer</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:
   unspecified">userName</saml2:NameID>
   <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:
   bearer">
   <saml2:SubjectConfirmationData NotOnOrAfter="2018-10-15T20:22:
   32.249Z" Recipient="https://kount.oktapreview.com/sso/saml2
   /0oaghflb4qxhAyvFf0h7"/>
   </saml2:SubjectConfirmation>
   </saml2:Subject>
   <saml2:Conditions NotBefore="2018-10-15T20:12:32.249Z" NotOnOrAfter="
   2018-10-15T20:22:32.249Z">
   <saml2:AudienceRestriction>
   <saml2:Audience>https://www.okta.com/saml2/service-provider
   /spoifiskuqigherjndqt</saml2:Audience>
   </saml2:AudienceRestriction>
   </saml2:Conditions>
   <saml2:AuthnStatement AuthnInstant="2018-10-15T20:17:32.175Z">
   <saml2:AuthnContext>
   <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:
   classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
   </saml2:AuthnContext>
   </saml2:AuthnStatement>
   <saml2:AttributeStatement>
   <saml2:Attribute Name="firstName" NameFormat="urn:oasis:names:tc:
   SAML:2.0:attrname-format:uri">
   <saml2:AttributeValue
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:
   type="xs:string">user.firstName
   </saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute Name="lastName" NameFormat="urn:oasis:names:tc:
   SAML:2.0:attrname-format:uri">
   <saml2:AttributeValue
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:
   type="xs:string">user.lastName
   </saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:
   2.0:attrname-format:uri">
   <saml2:AttributeValue
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:
   type="xs:string">user.email
   </saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute Name="groups" NameFormat="urn:oasis:names:tc:SAML:
   2.0:attrname-format:unspecified">
   <saml2:AttributeValue
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:
   type="xs:string">GroupName Match Starts with "Kount" (ignores case)
   </saml2:AttributeValue>
   </saml2:Attribute>
   </saml2:AttributeStatement>
   </saml2:Assertion>

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.

1. Obtain the SAML metadata file from your Kount Implementation Engineer.
   
   Note: Kount provides the SSO URL, Audience URL, and .pem file (generated from Okta).
2. Fill out the SAML Settings General form with the values provided by Kount.
   
3. 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.
     
4. Log in to the AWC as typical end-user, (this end-user must have been added before SSO feature was enabled within Kount).
5. 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).
6. Provide .pem certificate generated through your IDP back to your Customer Success Manager.
7. 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