Kony Fabric Deployment Guide · 2019. 12. 5. · KonyFabricDeploymentGuide Version1.3 RevisionHistory Date DocumentVersion DescriptionofModifications/Release 11/11/2019 1.3 DocumentPublishedfor:

Kony Fabric

Deployment Guide

Release V8 SP4 FP1Document Relevance and Accuracy

This document is considered relevant to the Release stated on this title page and the document version stated on the

Revision History page. Remember to always view and download the latest document version relevant to the software

release you are using.

© 2019 by Kony, Inc. All rights reserved 1 of 82

Kony Fabric Deployment GuideVersion1.3

Copyright © 2014 Kony, Inc.

All rights reserved.

November, 2019

This document contains information proprietary to Kony, Inc., is bound by the Kony license

agreements, andmay not be used except in the context of understanding the use andmethods of

Kony, Inc., software without prior, express, written permission. Kony, Empowering Everywhere, Kony

Fabric, KonyNitro, and Kony Visualizer are trademarks of Kony, Inc. MobileFabric is a registered

trademark of Kony, Inc. Microsoft, theMicrosoft logo, Internet Explorer, Windows, andWindowsVista

are registered trademarks of Microsoft Corporation. Apple, the Apple logo, iTunes, iPhone, iPad, OS

X, Objective-C, Safari, Apple Pay, AppleWatch, and Xcode are trademarks or registered trademarks

of Apple, Inc. Google, the Google logo, Android, and the Android logo are registered trademarks of

Google, Inc. Chrome is a trademark of Google, Inc. BlackBerry, PlayBook, Research inMotion, and

RIM are registered trademarks of BlackBerry. SAP® and SAP® Business Suite® are registered

trademarks of SAP SE in Germany and in several other countries. All other terms, trademarks, or

servicemarksmentioned in this document have been capitalized and are to be considered the

property of their respective owners.



Revision History

Date Document Version Description of Modifications/Release

11/11/2019 1.3 Document Published for:

l Case Study 2

02/28/2019 1.2 Document Published for V8 SP4 FP1. The guide

has been updated for:

l Security Hardening Features

04/19/2018 1.1 Document Published for V8 SP2

09/19/2017 1.0 Document published for V8GA



Table of Contents

1. Preface 8

1.1 Purpose 9

1.2 Intended Audience 9

1.3 Formatting Conventions Used in This Guide 9

1.4 Contact Us 11

2. Deployment Guide 12

2.1 Software Requirements 13

2.2 Deployment Topology 14

2.3 Development Topology 17

2.3.1 Moving a Kony Fabric App to a Different Environment 17

2.4 App Server Sizing 18

2.4.1 Sample Hardware Configurations 19

2.5 Database Growth Sizing 22

2.6 Session Management 25

2.6.1 Memcache Session Management 26

2.6.2 J2EE In-built Session Management 27

3. Security Hardening 30

3.1 Kony Fabric Components Covered 30

3.2 Secure Server Checklist 30

3.2.1 Enable SSL/TLS 30

3.2.2 Disable Weak Ciphers 31

3.3 Use a Hardened database for Kony Fabric 34



3.4 Users and Account roles 34

3.5 Default Services and Apps Permissions 36

3.6 Operation Security Level for Integration and Orchestration services 37

3.7 Verb Security Level for Object Services 38

3.8 Pre-requisites 38

3.8.1 Securing Data Transport between the Device and Kony Server 39

3.9 Backend Credentials and Session Security 39

3.10 User Credential Security 39

3.10.1 Example to set property ''PBKDF2_ITERATIONS" 41

3.10.2 Sample request 41

3.10.3 Steps to get Auth token and Tenant ID 42

3.11 Idle Session Timeout for Kony Fabric App 43

3.12 Password Policy for Kony Fabric users 44

3.12.1 Sample Request 44

3.12.2 Steps to get Auth token and Tenant ID 45

3.12.3 Version Management 46

3.12.4 Network security 46

3.13 Hardening Kony Fabric Integration (Middleware) 46

3.14 Hardening Kony Fabric Identity 49

3.15 Preventing Tomcat Version from Error Pages 50

3.16 Disable Concurrent Session 51

3.17 Protection against automated attacks 52

3.17.1 Configuring User Blocking Feature 53



3.17.2 Unblocking the user 54

3.18 Restrict Tomcat Manager to Localhost 55

3.19 Secure your Cookies (Secure and HttpOnly flags) 56

3.20 Redirect Traffic from Non-Secure Protocol (HTTP) to Secure Protocol(HTTPS) 57

3.21 Enabling Secure flag for CacheID Cookie 57

3.22 Configuring OWASP secure headers for SPA/Desktop apps 58

3.23 Disable Caching for Sensitive Middleware Services 60

3.24 Security Fixes for the External App Servers 65

4. Deployment Checklist and Example Case Studies 66

4.1 Checklist for Kony Fabric Deployment 66

4.1.1 Infrastructure Setup 66

4.1.2 Installing Kony Fabric 68

4.1.3 Manual Steps Post-Install 69

4.1.4 Test the Setup 69

4.1.5 Activate the License 71

4.2 Case Study 1 - Tomcat Multi-Node Cluster + HAProxy Load Balancer withMySQL Database 71


4.2.2 Installation of Kony Fabric 74






4.3 Case Study 2 - JBOSS Multi-Node Cluster + Apache/Mod_Cluster LoadBalancer with MySQL Database 75


4.3.2 Installation of Kony Fabric 78




5. FAQs and Troubleshooting 80

6. Index 81


1. Preface Kony Fabric Deployment GuideVersion1.3

1. Preface

Kony Fabric is aMobile Back-end as a Service (MBaaS) provider that helps developers build native

and web apps for mobile. Various back-end services are easily integrated with the application

irrespective of whether the application is built using JavaScript, PhoneGap, iOS, or Android

frameworks.

Kony Fabric allows you to define the back-end to build nativemobile apps for iOS, Android, and

HTML5-based apps for modern browsers. Kony Fabric ensures that developers build mobile

applications quickly by focusing on core areas and obtaining secured back-end services instantly.

Kony Fabric hasmultiple features that can be used - Identity, Integration, Orchestration, Objects,

Sync, and Engagement Services. These features can be accessed through a common, centralized

console.

For successful authentication with users, and to access the centralized features of Kony Fabric, Kony

recommends that you install the following Kony Fabric features on premises:

l Kony Fabric Identity and Console

l Kony Fabric Integration

l Kony Fabric Engagement Services

l Kony Fabric Sync Services

Kony Fabric supports the following back-end services for your applications:

l Identity: This feature allows you to define the type of authentication used for granting access to

your application. Kony Fabric supports the following authentication services: Microsoft Active

Directory, Salesforce, Security AssertionMarkup Language (SAML), Kony SAP Gateway,

Kony Facebook, and KonyUser Repository.

l Integration: This feature allows you to define various back-end services for your application.

You can define the service in XML, SOAP, JSON, Java, Salesforce, and Kony SAP Gateway.



l Orchestration: This feature allows you to create two types of orchestration services. They are:

o Composite: Allows you to run two or more services concurrently or sequentially.

o Looping: Allows you to run a single service in a loop until the loop ends or an exit criteria is

met.

l Synchronization: This feature allows you to define the synchronization services for your

application. Sync supports onlyWeb Services, except SAP Sky.

l Engagement Services: This feature allows you to define and configure pushmessaging

services for your application.

1.1 Purpose

The document helps you familiarize with the Kony Fabric and provide procedural information to

perform various tasks required to build your application.

1.2 Intended Audience

This document is intended for developers who would like to turn their applications into an enterprise-

grade applications using Kony back-end services.

1.3 Formatting Conventions Used in This Guide

The following formatting conventions are used throughout the document:



Conventions Explanation

Monospace l User input text, system prompts, and responses

l File path

l Commands

l Program code

l File names

Italic l Emphasis

l Names of books and documents

l New terminology

Bold l Windows

l Menus

l Buttons

l Icons

l Fields

l Tabs

l Folders

URL Active link to a URL.

Note:Provides helpful hints or additional information.

Important:Highlights actions or information that might cause problems to systems or

data


http://a/


1.4 Contact Us

Wewelcome your feedback on our documentation.Write to us at [email protected]. For technical

questions, suggestions, and comments, or to report problems on Kony's product line, contact

[email protected].


mailto:[email protected]?subject=Documentation Feedbackmailto:[email protected]

2. Deployment Guide Kony Fabric Deployment GuideVersion1.3

2. Deployment Guide

Guidelines for deploying Kony Fabric on-premises.

Kony Fabric is an enterprise-grademobile backend as a service (MBaaS). How you set up Kony

Fabric depends your application requirements and the number of users of your applications. You can

set up Kony Fabric on-prem inmany configurationswith component servers that are configured on

single or multiple physical and virtual hosts.

l "Software Requirements" on the next page

l "Deployment Topology" on page 14

l "Development Topology" on page 17

l "App Server Sizing" on page 18

l "DatabaseGrowth Sizing" on page 22

l "SessionManagement" on page 25

Kony Fabric Deployment Glossary

Term Definition

presentation tier The top-most level of an application, the user

interface.

application tier The business logic, or logic tier, it controls the

functionality of an application.

J2EE Java Platform, Enterprise Edition

EC2 Amazon Elastic Compute Cloud (Amazon EC2) is a

web service that provides resizable compute

capacity in the cloud.



Term Definition

RDS Amazon Relational Database Service (Amazon

RDS) is a web service that makes it possible to set

up, operate, and scale a relational database in the

cloud.

VM A virtual machine (VM) is an emulation of a particular

computer system.

UAT User acceptance testing.

high availability A system or component that is continuously

operational for a desirably long length of time.

separation of

concern

A design principle for separating a computer program

into distinct sections, such that each section

addresses a separate concern.

payload The part of the transmitted data that is the actual

intendedmessage. Payload does not include

information sent with it such as headers or metadata,

sometimes referred to as overhead data.

A-series, Dv2-

series

Sizes and options for the Azure virtual machines.

session affinity Enables the load balancer to bind a user's session to

a specific instance. This ensures that all requests

from the user during the session are sent to the same

instance.

2.1 Software Requirements

The following are the underlying software requirements for Kony Fabric on-premises.



For a complete list operating systems, app servers, databases, and Java Runtime Environment

supported by Kony Fabric , refer to Software Requirements by Kony Fabric.

Requirement Supported

Operating System Linux orWindows

Java Runtime Environment JDK 1.8

Session/cachemanagement Memcached

HTTP servers (reverse proxy) Apache or Microsoft IIS

Application servers JBoss, or Tomcat, orWebLogic orWebSphere

Database MySQL orMariaDB or Oracle or MS SQL or DB2 LUW

2.2 Deployment Topology

The following diagram depicts the topology of a typical deployment of Kony Fabric in a Production

environment. Individual components can vary based on specific requirements.


http://docs.kony.com/konylibrary/general/konyfabric_supported_devices_os_browsers/Default.htm#MobileFabricV8SP1.htm


2.3 Development Topology

A development environment can consist of any or all of the services that form part of Kony Fabric. The

following diagram depicts the topology of a typical deployment of Kony Fabric in a development

environment.

2.3.1 Moving a Kony Fabric App to a Different Environment

Tomove a Kony Fabric app from a development environment to a production environment, export the

app from the source (dev) environment, and import app in to the new environment – for example, a

UAT or Production environment. To learnmore about moving a Kony Fabric app, see Exporting and

Importing an Application.


http://docs.kony.com/konylibrary/mobilefabric/kony_mobilefabric_user_guide/Default.htm#Export-Import_Apps.htm?TocPath=Features|Exporting%2520and%2520Importing%2520an%2520Application|_____0http://docs.kony.com/konylibrary/mobilefabric/kony_mobilefabric_user_guide/Default.htm#Export-Import_Apps.htm?TocPath=Features|Exporting%2520and%2520Importing%2520an%2520Application|_____0


2.4 App Server Sizing

This section provides a guide to sizing and capacity that can help you determine the optimal

deployment configurations for your apps and user requirements.

The following table illustrates the sizing for each Kony Fabric component, for Tomcat:

Kony FabricRuntimes

Throughput/Sec Capacity CORES Memory

Integration & Identity 35 request/sec

(Every request can

have a payload of

50kb)

1-1.25million

session per

year

1 Core per JVM 3GB

per

JVM

Engagement 35 request/sec 60-70

pushes/sec

1 Core per JVM 2GB

per

JVM

Kony FabricConsole

Components

Throughput/Sec Capacity CORES Memory

Console N/A for production N/A for

production

1 Core per JVM 2GB

per

JVM



Note: 1 Core and 2GB is allocated for the operating system on each physical computer. Please

note that Metrics and integration admin consoleWeb archives (WARs) are installed as part of

integration. The integration admin console provides basic reports. If advance reporting is required,

install the reporting portal based on Jasper (Kony Fabric Reporting and Analytics - Installation

Guide).

Note: Metrics should be installed along with Integration services on the same physical computer.

2.4.1 Sample Hardware Configurations

The following scenarios illustrate a range of hardware configurations for Kony Fabric deployment.

2.4.1.1 Scenario A

A company requires Kony Fabric Integration to handle 1.25million sessions/year and Kony Fabric

Engagement for 80 pushes/sec. Tomaintain high availability, the customer adds an additional physical

computer.

Hardware Configuration Kony Fabric Java virtual machines

Physical Computer/VM – 5 core & 12GB RAM Console, Identity, Integration, Engagement

and Sync

Physical Computer/VM – 4 core & 10GB RAM Integration, Identity, Engagement and Sync

Physical Computer/VM – 2 core & 4-5 GB RAM Sync or Engagement or Integration and

Identity


http://docs.kony.com/konylibrary/mobilefabric/kony_analytics_reporting/Default.htmhttp://docs.kony.com/konylibrary/mobilefabric/kony_analytics_reporting/Default.htm


Hardware Configuration Kony Fabric Java virtual machines

Physical Computer/VM – 4 core & 16GB RAM

(applicable for Database)

Database components of the Kony Fabric:

l Console (accounts and workspace)

l Identity (authglobaldb and

authconfig)

l Integration (konyadmin, devicedb,

konyreports (Metrics))

l Engagement

l Sync

Note: The Hardware includes the RAM required for Operating System.

2.4.1.2 Scenario B

If you are required to have 250 request/sec, then you need to have 7 instances.

2.4.1.3 Scenario C

A company requires Kony Fabric Integration, Identity, Engagement and Reports Portal for handling

1.2million session/year on Azure Linux cloud with SQL Server.

As an illustration, each Standard tier: Dv2-series – Standard_D3_v2 server can handle 1.25million

sessions per year. Two Standard tier: Dv2-series – Standard_D3_v2 servers are configured for high

availability so that the environment can handle any spikes and serve up to 2million sessions per year.

For every additional 1.25million session /year, you will need an additional Standard tier: Dv2-series –

Standard_D3_v2 server.

If high availability is required for Kony Fabric Console & Reports Portal, the deployment requires 2

Standard tier: A-series – Standard_A2 servers.

The following tables also include a configuration for AWS that uses EC2 and RDS for MySQL.



For Production

Azure AWS Kony Fabric JVM’s

2 standard tier Dv2-series –

Standard_D3_v2

2M3 series – m3.xlarge Integration & Identity, &

Engagement

2 Standard tier A-series –

Standard_A2

2 T2 series – t2.medium Kony Fabric Console &

Reports Portal

Azure SQLDatabase – Standard

S1 (200 eDTU per pool) or 2

Standard tier: Dv2-series –

Standard_D3_v2 for MySQL/SQL

Server

Amazon RDS for MySQL –

db.m4.2xlarge or 2M3

series – m3.xlarge for

MySQL/SQL Server

For Development/QA

Azure AWS Kony FabricJVM’s

1 standard tier A-series – Standard_A3 1M3 series – m3.xlarge Integration &

Identity, &

Messaging

Azure SQLDatabase – Standard S1 (Basic

(200 eDTU per pool) or Standard tier: A-

series – Standard_a3 for MySQL/SQL Server

Amazon RDS for MySQL –

db.m4.2xlarge or 2M3

series – m3.xlarge

Note: If separation of concern and high availability of a particular runtime is important, you can

configure runtimes on different physical nodes.



For more information about VM sizes and other aspects of performance, see Sizes for virtual

machines in Azure and Amazon EC2 Instance Types.

2.5 Database Growth Sizing

DatabaseComponent

Data growthSize (GB)per year

Planned DataGrowth peryear (%)

EstimatedData size for 5years In GB

Datagrowthcriteria

KMS-Engagement 515 5 2846 0.1million

pushes per

day 3000 -

devices,

EMM 300 5 1658 1500 IMEI,

1500 -

users,

70000

apps, 1

crore

request per

month

Sync 7 5 38 10000

sessions

per day


https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sizes/https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sizes/https://aws.amazon.com/ec2/instance-types/


DatabaseComponent




Datagrowthcriteria

Metrics (Without

Events)

288 0 1440 1Million

Application

Sessions,

10Million

Service

Calls, 2

Million

Custom

Metrics per

month

Metrics (With

Events+geography)

1980 0 9900 1Million

Application

Sessions,

10Million

Service

Calls, 2

Million

Custom

Metrics, 50

M

Application

Events,

Geolocation

database

per month



DatabaseComponent




Datagrowthcriteria

Admin Server 1 0 1 Mostly

static data,

excluding

Logging

feature

(which is of

trouble

shooting

data)

Identity/auth 0.6 0 0.6 10000

users, 50

apps. This

data does

not grow

Waas 1 0 1 For 10 apps

or 500

services

with 10

operations

each, asset

size of 2

MB each



DatabaseComponent




Datagrowthcriteria

Accounts 0.5 0 0.5 Mostly

static data,

excluding

Logging

feature

(which is of

trouble

shooting

data)

2.6 Session Management

Kony Fabric server supportsMemcache or J2EE in-built sessionmanagement.

The following lists the session requirements for Memcache and J2EE in-built sessionmanagement.

Session Configuration Memcache J2EE In-built Session

Session affinity load balancer Not required Required

Additional configuration Yes, need to install Memcache softwareNot required. App servers

provides sessionmanagement

Data replication Not SupportedYes, session replication needs to

be configured on App Server



2.6.1 Memcache Session Management

Memcache is an in-memory key-value store for small chunks of arbitrary data—for example, strings,

and objects. Memcache is a high-performance, distributedmemory object caching system, generic in

nature. Memcache does not support data replication across nodes.

You can configure the Kony Fabric Server that is deployed on Tomcat to talk to any number of

Memcache nodes. The nodes can be located on the same or different physical machines. All the user

sessions are serialized and stored in theMemcache node. Thismakes it possible to deploy the Kony

Fabric Server in an environment where session affinity is not available.

The following describes typical scenarios that may occur when you useMemcache and how it handles

sessions:

2.6.1.1 Scenario A

Tomcat Instance is Down

In this scenario, there will be no transaction failure as the session data is available in theMemcache

node. The request is routed to the other Tomcat instances. The other Tomcat instanceswill retrieve

the session data from theMemcache.

2.6.1.2 Scenario B

Memcache Instance is Down

In this scenario, if the session data is stored in theMemcache instance that is down, there will be a

transaction failure. All the users whose session data was stored on theMemcache instance that went

down, have to reinitiate the transaction.

2.6.1.3 Scenario C

Physical Computer is Down

In this scenario, if the session data is stored on one of theMemcache instances of the physical

computer that is down, there will be a transaction failure. All the users whose session data was stored

on theMemcache instances of the failed physical computer, will have to reinitiate the transaction.



The following illustrates theMemcache-SessionManagement scenario.

2.6.2 J2EE In-built Session Management

J2EE-based Application servers provide HTTP-based session capabilities by default. The HTTP

session ismanaged via an in-memory key-value store. The HTTP sessionswill not survive application

server restarts.



The following diagram illustrates this scenario.

The following describes typical scenarios that may occur when you use J2EE in-built session

management and how it handles sessions:

2.6.2.1 Scenario A

WebLogic/Websphere Instance is Down

In this scenario, all the users of this instance will have to re-initiate the transaction.

2.6.2.2 Scenario B

Physical Computer is Down

In this scenario, all the users of this physical computer will have to re-initiate the transaction.



Note: If you configure session replication, the user will not have to re-initiate the transaction for the

app server/physical computer restart or breakdown. You can configure session replication for

small server farms—for example, 2-10 app server instances. Session replication will require

additional CPU and a very high-speed network connection between the app server nodes.


3. Security Hardening Kony Fabric Deployment GuideVersion1.3

3. Security Hardening

Security Hardening section provides prescriptive guidance to customers on how to deploy and operate

Kony Fabric in a securemanner. This document provides recommendations for improving the security

("hardening") of your Kony Fabric installation and tomake sure Kony Fabric is running securely.

3.1 Kony Fabric Components Covered

This section details hardening supported for the following Kony Fabric components.

l Installer

l Identity

l Integration

l Sync

l Console

3.2 Secure Server Checklist

3.2.1 Enable SSL/TLS

Serving web requests over HTTPS is essential to protect data between the client and the application

server.

Tomake your web application accessible through HTTPS, youmust implement SSL certificate.

While installing Kony Fabric, ensure that you select HTTPS as a communication protocol and provide

valid CA certificates.



3.2.2 Disable Weak Ciphers

To achieve greater security, you can configure the server not to use weak ciphers when they

communicate using the SSL/TLS protocol. You have to primarily take care of the following three

things:



l Disable SSL 2.0 (FUBAR) and SSL 3.01 (POODLE),

l Disable TLS 1.0 compression (CRIME),

l Disable weak ciphers (DES/3DES, RC4), prefer modern ciphers (AES), modes (GCM), and

protocols (TLS 1.2).

Make use of Qualys SSL Server Test to analyze the server SSL configurations.

3.2.2.1 How to Disable Weak Ciphers in Tomcat

To disable weak ciphers, modify the SSLConnector container attribute inside the server.xml with

the required https connector tag details. The server.xml is located in the \tomcat\conf folder.

Add the following is a sample details to SSL connector tag:

SSLEnabled="true" sslEnabledProtocols="TLSv1.2" ciphers="TLS_ECDHE_

RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_

ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_

SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_

SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,

TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"

For example, the following is a samplemodified https connector tag:


keystorePass="password" truststoreFile="mytruststore.truststore"

truststorePass="password"/>;

Note: Upgrade the SSLCipher list to the latest available versions.

3.2.2.2 How to Disable Weak Ciphers in JBoss

To disable weak ciphers, replace the https-listener under JBoss subsystem/undertow, for

example,

For example, the following is a sample for https connector tag:

For example, the following is a samplemodified https connector tag:


verify-client="REQUIRED" security-realm="ApplicationRealm" socket-

binding="connect"/>

Note: Upgrade the SSLCipher list to the latest available versions.

3.3 Use a Hardened database for Kony Fabric

Your database is the jackpot that every attacker aims to capture. As attacks get more sophisticated

and networks get more hostile, it has becomemore important than ever to take the following additional

steps to harden your database.

l Set Strong Passwords (Passwordmust contain at least 8 characters, at most 20 characters,

andmust include at least one uppercase letter, one lowercase letter, one digit, and one special

character)

l Remove Anonymous Users

l Follow the Principle of Least Privilege

l Enable TLS (The Installer does not support databases running TLS, so youmust enable it post-

installation)

3.4 Users and Account roles

Kony Fabric provides amechanism to create a store of users in Kony Fabric Console (locally) or

import fromActive Directory.

Users listed in the User Management can access Kony Fabric Console to create apps.

There are a total of four account roles in Kony Fabric:



l Owner: An owner has themost privileges and can do the following:

l Add, modify, and delete an environment.

l Add, modify, and delete other owners, admins, andmembers.

l Admin: An admin has fewer privileges than an owner and can do the following:

l Add other admins andmembers.

l Modify and delete other admins andmembers.

l Grant and deny environment access to other admins andmembers.

l Member: A member has the fewest privileges, which includes creating, editing or deleting new

Kony Fabric applications or services. A member does not have permissions to invite a new user

to the cloud or change the environment access of other members.

l Developer Portal Only: This provides access to specific Developer Portals only and does not

provide access to the Kony Fabric Console.



3.5 Default Services and Apps Permissions

You can configure access control for Kony Fabric applications and services. By default, all the users

have full access rights to create and access apps and services.

Use the Apps Console Access Control page to control access to an application. Use the Services

Console Access Control page to control access to a service.

Change the default access permissions for a new service or application according to the company’s

access policy. This setting can be found in: Settings -> Default Services & Apps Permissions.



3.6 Operation Security Level for Integration and Orchestration ser-

vices

Select one of the following security operations in the Operation Security Level field for integration and

orchestration services. By default, the field is set to Authenticated App User:

l Authenticated App User – indicates that the operation is secured. To use the operation, an app

user must be authenticated by an associated identity service.

l Anonymous App User – indicates that a user must have the app key and app secret to access

this operation.

l Public – indicates that the operation requires no special security.

For Integration Services:

For Orchestration Services:



3.7 Verb Security Level for Object Services

The Verb Security Level specifies how the client must authenticate to the verb. You can restrict access

to this verb to only authenticated app users who have successfully been authenticated using an

Identity service. An anonymous app user verb allows access from a trusted client that has the required

App Key and App Secret, but the client does not need to authenticate the user through an identity

service.

Set the security level to Public to allow any client to access this verb without any authentication

requirement. Authenticated App User – indicates that the operation is secured. To use the operation,

an app user must be authenticated by an associated identity service.

3.8 Pre-requisites

Ensure that you read the Pre-requisites which contains information onMulti-node load balancer setup

and other configurations.


http://docs.kony.com/konylibrary/konyfabric/kony_fabric_windows_install_guide/Default.htm#Prerequisites.htm?TocPath=Prerequisites|_____0


3.8.1 Securing Data Transport between the Device and Kony Server

Kony uses the traditional 128/256 bit SSL protocol between the device and the Kony Server for all the

data communication. Themobile device has the native SDKs supporting the HTTPS connection from

themobile device and no additional API or infrastructure investment is required.

3.9 Backend Credentials and Session Security

Kony Fabric uses AES-256 algorithm to encrypt backend credentials. The admin does not need to do

anything for protecting the backend credentials.

The backend cookies/tokens are stored after being encrypted using the tenant’s data encryption key

(AES encryption). Backend tokens are deleted when the session expires, or when the user logs out.

The following are the two types of sessions:

l Fixed duration sessions expire when the duration elapses after login.

l Auto-extending sessions are defined using an inactivity timeout andmax active duration. They

expire if there is no activity during an inactivity timeout duration or if themax active duration

elapses after login.

If the backend supports refresh, the backend tokens can be refreshed by calling the refresh API from

SDK.

3.10 User Credential Security

Kony Fabric currently encrypts the user credentials with PBKDF2with 1000 iterations. The password

is salted is 24 random bytes generated using java.security.SecureRandom.

As per NIST, it is recommended to use at least 10,000 iterations. If the user wants PBKDF2, iterations

to be increased, he can achieve that by setting a property called 'PBKDF2_ITERATIONS'. but this

might AFFECT THE PERFORMANCE. Below are the performance statistics for 1k iterations and 10k

iterations.



No of calculations (loops) 1K Iterations (in ms) 10K Iterations(in ms)

1000 3278 28159

2000 5780 57280

3000 8634 91604

4000 12423 122031

5000 14862 148167

6000 17967 179345

7000 20966 210320

8000 24736 242198

9000 26720 266217

10000 30150 302918



3.10.1 Example to set property ''PBKDF2_ITERATIONS"

Request:

POST authservice/api/v1/setup/tenants//properties

Headers:

Authorization:

Content-Type: application/x-www-form-urlencoded

Payload:

name = PBKDF2_ITERATIONS

value = 10000

3.10.2 Sample request

POST

/authService/100000002/api/v1/setup/tenants/100000002/properties

HTTP/1.1

Host: example.com

Authorization:



eyAidHlwIjogImp3dCIsICJhbGciOiAiUlMyNTYiIH0.eyAiX2VtYWlsIjogInNhaWtp

cmFuLmdvdWRAa29ueS5jb20iLCAiX3ZlciI6ICJ2MS4xIiwgImlzcyI6ICJodHRwOi8v

c2VjdXJpdHl0ZXN0dm0ua2l0c3BsLmNvbTo4MDgwL2F1dGhTZXJ2aWNlL2FjY291bnRz

IiwgIl9zY29wZSI6ICJnIiwgIl9pc3NtZXRhIjogIi9tZXRhZGF0YS9rNDVRdFcxa0V5

SXRsUkg5eG9renZnPT0iLCAiX3Nlc3Npb25faWQiOiAiYTBmYTE1NmQtNDFmNi00Nzkx

LTgwNmMtOTBhM2FmNmZlZGFlIiwgIl9wdWlkIjogNTA0NDIxMzMzNDk2MSwgIl9pZHAi

OiAidXNlcnN0b3JlIiwgImV4cCI6IDE1MTk4OTcwMzAsICJpYXQiOiAxNTE5ODkzNDMw

LCAiX3Nlc3Npb25fdGlkIjogImFjY291bnRzIiwgIl9wcm92X3VzZXJpZCI6ICJzYWlr

aXJhbi5nb3VkQGtvbnkuY29tIiwgImp0aSI6ICI3ODYxYjA1NS0wNmNiLTQwODItOWRk

ZC04MDFkNTJjY2ExM2QiLCAiX2FjcyI6ICJhY2NvdW50cyIgfQ.nRhGEbfTqzl5aCgEY

n85YUPxM3LOMedVFjJX4NlYhlIRzYs_5JkuCH3Yl-

p8uVGw2rNOoqzK1x2KUhe3oPRQ8ab4QTVddYnTBfsQt9lFViiGMlOKgbLDI7wn9AGfws

QRB_6fNVJ5HEt2k6kC2C8mHCYGWnXTRjLEKsK-k9Wc5Gaur49yKEjl6_tkH--

qoDsqFYuLGHzad4zQHtsRxrxgxfI_z3QuN3VF_DYKoD5Nzsi5rxGSCu-PPH9_

gQRO2ED6S-WllJdJTTIal_pa4bGG-

JhDtCdOR9GHDPcbBZ6WG1GwTJKWbqDEDzxjrxiKk5VZDOwjUuhwTJwE2cwQJIO-EQ


Cache-Control: no-cache

Postman-Token: 745a8e95-171b-204c-a934-37d434054adb

name=PBKDF2_ITERATIONS&value=1000

3.10.3 Steps to get Auth token and Tenant ID

1. Login to Kony Fabric using Owner account.

2. Goto http://securitytestvm.kitspl.com:8080/mfconsole/accountInfo

3. Note down the tenant id and auth token as shown in below image.


http://securitytestvm.kitspl.com:8080/mfconsole/accountInfo


3.11 Idle Session Timeout for Kony Fabric App

Kony Fabric supports configuring session timeout (idle timeout and fixed timeout) for an app identity

session.

You can configure either an idle timeout or fixed timeout for apps in the Applications > Identity page.

l Idle Timeout: Specifies the amount of time inminutes that a session can remain idle before

Kony Fabric automatically terminates the app.

l Identity Session Idle Timeout: When an app session on a device remains idle for a certain

amount of time, the app session expires automatically. The user will need to log in to the

app again.

l MaximumSession Duration: An apps log-in session is active until themaximum session

duration time ismet.

l Fixed Timeout: Specifies the app session’s idle timeout (HH:SS). When the timeout is reached,

the session expires automatically, and the user will need to log into the app again.

Kony Security Team recommends Identity Session Idle Timeout to be set to 00:05 hours (5Minutes).



3.12 Password Policy for Kony Fabric users

Nomatter how secure Kony Fabric is, Users will eventually choose their own password. Therefore,

you should set account policies that define a secure password for your systems.

The default password policy is passwordmust contain at least 8 characters, at most 20 characters and

must include at least one uppercase letter, one lowercase letter, one digit and one special character.

An owner of the account can change the password policy by changing “password_regex” property.

Request:

POST authservice/api/v1/setup/tenants//properties

Headers:

Authorization:


Payload:

name = password_regex

value = ^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*(_|[^\\w])).{8,20}$

3.12.1 Sample Request

POST

/authService/100000002/api/v1/setup/tenants/100000002/properties

HTTP/1.1

Host: example.com

Authorization:



eyAidHlwIjogImp3dCIsICJhbGciOiAiUlMyNTYiIH0.eyAiX2VtYWlsIjogInNhaWtp

cmFuLmdvdWRAa29ueS5jb20iLCAiX3ZlciI6ICJ2MS4xIiwgImlzcyI6ICJodHRwOi8v

c2VjdXJpdHl0ZXN0dm0ua2l0c3BsLmNvbTo4MDgwL2F1dGhTZXJ2aWNlL2FjY291bnRz

IiwgIl9zY29wZSI6ICJnIiwgIl9pc3NtZXRhIjogIi9tZXRhZGF0YS9rNDVRdFcxa0V5

SXRsUkg5eG9renZnPT0iLCAiX3Nlc3Npb25faWQiOiAiYTBmYTE1NmQtNDFmNi00Nzkx

LTgwNmMtOTBhM2FmNmZlZGFlIiwgIl9wdWlkIjogNTA0NDIxMzMzNDk2MSwgIl9pZHAi

OiAidXNlcnN0b3JlIiwgImV4cCI6IDE1MTk4OTcwMzAsICJpYXQiOiAxNTE5ODkzNDMw

LCAiX3Nlc3Npb25fdGlkIjogImFjY291bnRzIiwgIl9wcm92X3VzZXJpZCI6ICJzYWlr

aXJhbi5nb3VkQGtvbnkuY29tIiwgImp0aSI6ICI3ODYxYjA1NS0wNmNiLTQwODItOWRk

ZC04MDFkNTJjY2ExM2QiLCAiX2FjcyI6ICJhY2NvdW50cyIgfQ.nRhGEbfTqzl5aCgEY

n85YUPxM3LOMedVFjJX4NlYhlIRzYs_5JkuCH3Yl-

p8uVGw2rNOoqzK1x2KUhe3oPRQ8ab4QTVddYnTBfsQt9lFViiGMlOKgbLDI7wn9AGfws

QRB_6fNVJ5HEt2k6kC2C8mHCYGWnXTRjLEKsK-k9Wc5Gaur49yKEjl6_tkH--

qoDsqFYuLGHzad4zQHtsRxrxgxfI_z3QuN3VF_DYKoD5Nzsi5rxGSCu-PPH9_

gQRO2ED6S-WllJdJTTIal_pa4bGG-

JhDtCdOR9GHDPcbBZ6WG1GwTJKWbqDEDzxjrxiKk5VZDOwjUuhwTJwE2cwQJIO-EQ


Cache-Control: no-cache

Postman-Token: ebb17b95-9e44-6ebd-1953-3ad9f1c9019f

name=password_regex&value=^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*(_|

[^\\w])).{8,20}$

3.12.2 Steps to get Auth token and Tenant ID

1. Login to Kony Fabric using Owner account.

2. Goto http://securitytestvm.kitspl.com:8080/mfconsole/accountInfo

3. Note down the tenant id and auth token as shown in below image.


http://securitytestvm.kitspl.com:8080/mfconsole/accountInfo


3.12.3 Version Management

l A policy to periodically install security patches of all softwaremust be in place.

l Amechanism to regularly check for missing security patchesmust be in place.

l Software should be installed from a central, trusted repository when available.

l Servicesmust displayminimal information about the installed version.

3.12.4 Network security

l Only aminimal set of ICMP packetsmust be accepted

l Packet rate-limitingmust be implemented

3.13 Hardening Kony Fabric Integration (Middleware)

In addition to the security best practices followed by the customer as per their internal guidelines, Kony

makes the following recommendations to reduce the attack surface of their integration server

deployments.

1. Applying latest patches

The web server, the underlying operating system, the application server and the database



server must all have the latest patches applied. This protects the installation against exploits for

known vulnerabilities.

2. Removing unnecessary services

Every service running on the application server is an additional attack surface especially if the

service is listening on a port and is remotely accessible. All services other than the ones that are

absolutely required to run the Integration Server (formerlymiddleware) product must be turned

off.

3. Use Hardened Application and Database servers

The servers included as part of the Integration Server deployment should be hardened as per

the hardening recommendations available from the vendor or independent groups like

NSA/SANS who havemade such information available publicly.

4. Restrict Access to Non- Integration Services

Integration serviceswould typically bemade accessible from the intranet or internet. Access to

other services on the server can be restricted using IP tables or other host-level firewalls.

5. Restrict Access to Admin Console

Admin Console is the administrative interface and it is recommended to restrict access to

internal networks only if possible. This can be achieved in two ways:

l Configure Admin Console and Integration Services to use two different ports and restrict

access to the port on which Console is running to only internal users.

l At the Load Balancer, you can write a filter to block access to the Console part of the

application from external users. Restrict Access to Non- Integration Services.

6. Application Server Privileges

Integration Server can function effectively when Tomcat is run as the default Tomcat user

without any special privileges being granted. It is strongly recommended that the server should

be production grade with lesser privileges such as disabling direct access and process request

through LB and other HTTP verbs.

7. Database Server Privileges

Integration Server installation requires creating new Databases and tables, once the installation



is done, it would only insert, query and update entries in the existing tables. Hence it is

recommended that only during the installation process a database user with permission to

perform creation and deletion privileges is used. Once the installation is done this user account

can be deleted and replaced with another user who only has permissions to Read, Insert and

Update. Dangerous functions like system() (MySQL), xp_cmdshell (MS SQL)must be

disabled or permissions to use these functions should not be granted to the admin database

account.

8. Log Level Recommendation Kony recommendation on log4j Log level is ERROR in production

to avoid logging any sensitive information in log files. Make sure the below to change log level to

ERROR.

1. In middleware-log4j.properties file, All log levels should be ERROR

2. In Admin Console Configuration page, Log Level configuration should be selected as

ERROR.

9. HTTPS mode. Integration Server works both in HTTP and HTTPSmode. It is recommended to

install the server in httpsmode.

10. SSL Certificate Type

Recommended using your own existing SSL certificate rather than going with a generated self-

signed certificate.



3.14 Hardening Kony Fabric Identity

In addition to the security best practices followed by the customer as per their internal guidelines, Kony

makes the following recommendations to reduce the attack surface of their Kony Fabric Identity

Deployments.

1. Restrict Access to Non-Kony Fabric Identity Services: Kony Fabric Identity service would

typically bemade accessible from the intranet or the internet. Access to other services on the

server can be restricted using IP tables or other host-level firewalls.

2. Restrict Access to Kony Fabric Console: Kony Fabric Console is the administrative interface

and it is recommended to restrict access to internal networks only if possible. This can be

achieved in two ways:

l Configure Kony Fabric Console and Kony Fabric Identity Service to use two different

ports and restrict access to the port on which Console is running to only internal users.

l At the Load Balancer, you can write a filter to block access to the Console part of the

application from external users. Restrict Access to Non-Kony Fabric Identity Services



3. Log Level Recommendation Kony recommendation on log4j Log level is ERROR in production

to avoid logging any sensitive information in log files. It is recommended to set the LOG_LEVEL

property in authService.properties to ERROR.

4. Kony Fabric Identity tokens and sessions: When a user logs in to an identity provider in Kony

Fabric via an app, the user passes app credentials (Kony Fabric app key and secret), and user

credentials for the backend identity provider. The Identity service validates the app credentials

and sends the user credentials to the backend identity provider for authentication (in case of

SAML or OAuth, the user credentials are passed to backend identity provider via client-side

browser redirect and not via Kony Fabric Identity). The backend authenticates the user and

returns a session token (known as the backend token), which can then be used to access the

user’s data in the backend. Once the user is successfully authenticated at the backend, Kony

Fabric Identity creates a session and issues an Identity token linked to the session. The Kony

Fabric Identity token is a JWT token signed by the tenant’s signing key and contains claims

about the authenticated user, app, provider, issuer, and session. The backend tokens are also

linked to the identity session.

3.15 Preventing Tomcat Version from Error Pages

When you access Kony Fabric V8.x by using a particular URL directly from a browser, the web page

displays Tomcat Application Server's version.

For example, the Apache Tomcat server version is disclosed, as shown in the following screen shot:

For security reasons, youmust disable the server information disclosure for Tomcat application server.



To prevent disclosure of the Tomcat Application Server version, follow these steps:

1. Open the Tomcat Server > server.xml file.

2. Add the following:

3. Save the server.xml.

4. Restart the server.

3.16 Disable Concurrent Session

If your users are not going to connect to more than one session, it is recommended to disable

concurrent sessions.

To disable concurrent sessions, add the following property in the waas_property table of the console

db:

l property_name="DISABLE_CONCURRENT_SESSIONS"

l property_value="true"

l tenant_name = __global

l etag =

Alternatively, you can also use the following API to add the property in the waas table:

POST /api/v1/setup/properties

Headers:



l X-Kony-Authorization =

l Content-Type = application/x-www-form-urlencoded

Form Data parameters:

l name = DISABLE_CONCURRENT_SESSIONS

l value = true

SampleWaas_Base_URL = http://localhost:9090/workspace/100000002

Follow these steps to get the X-Kony-Authorization token:

1. Log on to Kony Fabric and go to the accountInfo section

For example, http://localhost:9090/mfconsole/accountInfo

2. Retrieve the value corresponding to the authToken key from the output folder.

3. Navigate toauthService.war/Web-INF/classes, edit the

authService.properties file, and add DISABLE_CONCURRENT_SESSIONS=true

at the end of the file.


3.17 Protection against automated attacks

Kony Fabric provides a security feature to block users onmultiple failed log-in attempts. If a user tries

to sign inmultiple times using invalid credentials, Kony Fabric blocks their account for a certain period

called the Blocking Threshold. They can log on only after the blocking threshold elapses.

Note: This feature is applicable for On-Premise installations of Kony Fabric 7.2 and above.

Kony Fabric provides an option to configure the following:



l Number of failed log in attempts before the user is blocked.

l Blocking Threshold

3.17.1 Configuring User Blocking Feature

Youmust obtain an authToken to configure the number of failed attempts to sign in and blocking

threshold time in Identity.

Follow these steps to get the authToken.

l Log on to the Kony Fabric Console from a browser and open the /mfconsole/accountInfo API in a new tab.

l The console displays the following response:

l Copy the authUrl and authToken from the response.

Invoke the following API to enable User Blocking onmultiple failed login attempts.

POST /api/v1/setup/tenants/__global/properties

Headers:

l Content-Type: application/json

l X-Kony-Authorization:

Request body:



{

"name":"MAX_LOGON_FAILED_ATTEMPTS",

"value":"3"

}

Specify the value as themaximumnumber of failed sign in attempts you want to allow. In this scenario,

Kony Fabric blocks the user after three consecutive failed sign in attempts.

If the user tries to sign in after three failed attempts, the console displays the followingmessage:

“User account locked due tomultiple failed login attempts. Please contact the system administrator.”

Use the following API to set the blocking threshold

POST /api/v1/setup/tenants/__global/properties

Headers:

Content-Type: application/json

X-Kony-Authorization:

Request body:

{

"name":"LOGON_BLOCKING_THRESHOLD_MINUTES",

"value":"15"

}

Specify the value of the blocking threshold in the value field. In this scenario, the user is blocked for 15

minutes. After 15minutes, they can log on to the Console using valid credentials.

3.17.2 Unblocking the user

The user can sign in after the blocking threshold ends.



A database admin can unblock a user before the blocking threshold ends. To unblock a user, follow

the given steps:

1. Connect to the Identity Config Database idconfigdb (the and

must be the same as configured at the time of installation)

2. Issue the following SQL command:

set sql_safe_updates = 0;

UPDATE users

SET

user_status = 'active',

login_fail_count = 0

WHERE

userid = '';

set sql_safe_updates = 1;

3.18 Restrict Tomcat Manager to Localhost

Follow these steps to secure the tomcat manager to the localhost.

1. Create an xml file called manager.xml in the/conf/catalina/localhost path.

2. write the following code inmanager.xml:


type="org.apache.catalina.UserDatabase"/>

-->

3.19 Secure your Cookies (Secure and HttpOnly flags)

Cookies let websites store data directly on the web browser of a user. Websites primarily use cookies

to identify the user session based on their browsing. Cookies contain sensitive data that must be

protected.

Tomake your cookies secure, modify the web.xml and weblogic.xml files of the webapp for the

required components.

l WebApps > mfconsole for Kony Fabric Console

l WebApps > admin for Kony Fabric Admin Console

l WebApps > kpns for Kony Fabric Engagement

l WebApps > authService for Kony Fabric AuthService

Add the following code in the web.xml file:

true

true

Add the following code in the weblogic.xml file:

true



Restart the Application Server.

You can use developer tools to verify the changes.

3.20 Redirect Traffic from Non-Secure Protocol (HTTP) to Secure Pro-

tocol (HTTPS)

Follow these steps to setup the Tomcat Server to redirect HTTP requests to the HTTPS port to access

web applications from both the ports:

1. Add the following code in the server.xml file present in theTomcatInstallation/conf

path.

securedapp

/*

CONFIDENTIAL

2. Restart the Application Server.

3.21 Enabling Secure flag for CacheID Cookie

Themiddleware sets the CacheID to refer to the cached data fromMemcached.



Enable the secure flag for the CacheID cookie using the following -D parameter:

1. Go to tomcat\bin in the Installation folder.

2. Edit Catalina.

3. At the end of the first line, add -Dis.cacheid.cookie.secure=true.

4. Save the changes


3.22 Configuring OWASP secure headers for SPA/Desktop apps

HTTP headers which should be included. There are security settingswhich should be enabled unless

there are other overriding concerns.

l X-Frame-Options: SAMEORIGIN

l X-XSS-Protection: 1; mode=block

l X-Content-Type-Options: nosniff

l Content-Type: text/html; charset=utf-8

Follow these steps to set the header for Kony Fabric versions 8.2 or lower.

l To overcome these security issues in Kony SPA and DesktopWeb applications, add custom

filter and filter mapping entry in the web.xml file.

l For example:

public void doFilter(ServletRequest request, ServletResponse

response, FilterChain filterChain)

throws IOException, ServletException {

HttpServletRequest req = (HttpServletRequest) request;

HttpServletResponse res = (HttpServletResponse) response;



res.setHeader (""""X-Content-Type-Options"""",

""""nosniff"""");.... // Similarly add your response headers.

... filterChain.doFilter(request, response);

}

l Create a jar file using the class that you created.

XXXFilter

com.xyz.web.filter.XXXFilter

XXXFilter

/

l Extract the build applicationWar file and add thementioned lib and entry in web.xml.

l Kony Visualizer provides an option to add jars and edit the web.xml under Menu > File >

Combine EAR file option.

Note: Usage of the custom filter is the responsibility of the application developer.

Follow these steps to set the header for Kony Fabric versions 8.3 or higher.

1. Log on to Kony Fabric Console.

2. Select Environments from the left navigation pane.

3. Select App Services to open the Server Admin Console.

4. Go toSettings > Runtime Configuration > Web Apps

Configuration > Custom Response Header.



5. Add the required header in the following format:

[

{'name': 'Cache-Control', 'value': 'no-cache'}

]

3.23 Disable Caching for Sensitive Middleware Services

Most modern browsers and devices store a local cache copy of content received fromweb servers,

unless restricted. Users can also accessCache content through HTTPS. Users having access to a

device can retrieve any sensitive information stored in the local cache by other users.

To avoid storage of sesitive data in cache, applicationsmust contain caching directives that instruct

browsers to not store local copies of any sensitive data. You can configure the web server to prevent

caching for relevant pathswithin the root directory of the web. Alternatively, most web development

platforms allow the user to control the server's caching directiveswith individual scripts. Ideally, the

web server must return the following HTTP headers in all responses that contain sensitive content:

l Cache-control: no-store

l Pragma: no-cache



Use custom filters to add cache-control as a response-header

l CacheHeaderResponseWrapper is a response wrapper that adds the header just before it

writes the response to the client.

l CacheHeaderFilter is the custom filter that uses the CacheHeaderResponseWrapper

response wrapper and passes it into the filter chain.

The following code is an example for a custom filter.

CacheHeaderResponseWrapper.java

package com.kony.custom.filters;

import java.io.IOException;

import java.io.PrintWriter;

import javax.servlet.ServletOutputStream;

import javax.servlet.http.HttpServletResponse;

import org.apache.logging.log4j.LogManager;

import org.apache.logging.log4j.Logger;

import com.konylabs.middleware.common.KHttpServletResponseWrapper;

public class CacheHeaderResponseWrapper extends

KHttpServletResponseWrapper {

private static final Logger LOGGER = LogManager.getLogger

(CacheHeaderResponseWrapper.class);

private ServletOutputStream originalOutputStream;

private PrintWriter originalWriter;

private ServletOutputStream customOutputStream;

private PrintWriter customWriter;



private HttpServletResponse response;

public CacheHeaderResponseWrapper(HttpServletResponse response) {

super(response);

this.response = response;

}

@Override

public PrintWriter getWriter() throws IOException {

if (originalWriter == null) {

LOGGER.debug("Creating a custom writer.");

originalWriter = super.getWriter();

customWriter = new PrintWriter(originalWriter) {

@Override

public void write(String content) {

addCacheControlHeader();

super.write(content);

}

};

}

return customWriter;

}

@Override

public ServletOutputStream getOutputStream() throws IOException {

if (originalOutputStream == null) {

LOGGER.debug("Creating a custom servlet output stream.");

originalOutputStream = super.getOutputStream();

customOutputStream = new ServletOutputStream() {



@Override

public void write(int b) throws IOException {

originalOutputStream.write(b);

}

@Override

public void flush() throws IOException {

addCacheControlHeader();

super.flush();

}

};

}

return customOutputStream;

}

private void addCacheControlHeader() {

// Add the required response headers here.

response.setHeader("Cache-control", "no-store, no-cache, must-

revalidate");

response.setHeader("Pragma", "no-cache");

}

}

CacheHeaderFilter.java

package com.kony.custom.filters;

import java.io.IOException;

import javax.servlet.Filter;



import javax.servlet.FilterChain;

import javax.servlet.FilterConfig;

import javax.servlet.ServletException;

import javax.servlet.ServletRequest;

import javax.servlet.ServletResponse;

import javax.servlet.http.HttpServletResponse;

import org.apache.logging.log4j.LogManager;

import org.apache.logging.log4j.Logger;

import com.konylabs.middleware.common.MWConstants;

import

com.konylabs.middleware.servlet.filters.IntegrationCustomFilter;

@IntegrationCustomFilter(filterOrder = 2, urlPatterns =

MWConstants.ANY)

public class CacheHeaderFilter implements Filter {

private static final Logger LOGGER = LogManager.getLogger

(CacheHeaderFilter.class);

@Override

public void init(FilterConfig filterConfig) throws

ServletException {

LOGGER.debug("Loading CacheHeaderFilter.");

}

@Override

public void doFilter(ServletRequest request, ServletResponse

response, FilterChain chain)

throws IOException, ServletException {

CacheHeaderResponseWrapper responseWrapper = new

CacheHeaderResponseWrapper(

(HttpServletResponse)response);



chain.doFilter(request, responseWrapper);

}

@Override

public void destroy() {}

}

For more information on how to implement a custom filter, refer CustomUser Filter Guide.

3.24 Security Fixes for the External App Servers

Enable the following headers along with their mentioned values in Fabric App Servers.

Header Value

X-Content-Type-Options nosniff

Strict-Transport-Security max-age=31536000; includeSubDomains; preload

Cache-Control private, no-cache, no-store, max-age=0, notransform

Pragma no-cache

Expires 0

X-XSS-Protection 1; mode= block


https://basecamp.kony.com/s/article-detail/a046A000001lauhQAA/custom-user-filter-guide

4. Deployment Checklist and Example Case Studies Kony Fabric Deployment GuideVersion1.3

4. Deployment Checklist and Example Case Studies

This section provides a checklist for a standard production grade Kony Fabric deployment. The goal is

to help you define a repeatable process to deploy, configure, upgrade, and expand your Kony Fabric

environment. The case studies that follow, describe a few Kony Fabric deployments that were done

using well-known infrastructure components and how theywere configured for a standard production

environment. This document will help you understand the challenges involved and prepare you for a

smooth deployment of Kony Fabric within your enterprise.

4.1 Checklist for Kony Fabric Deployment

l Infrastructure Setup

l Installing Kony Fabric

l Manual Steps post-install

l Test the setup

l Activate the License

4.1.1 Infrastructure Setup

Most production grade Kony Fabric installations need you to consider the following:

l Choice of App Server and Database

Choose from the supported Application Servers and Databases as outlined in the Supported

Application Servers and Databases.

l Node Sizing

l A good starting point is to select a standard node as suggested by theminimum

infrastructure requirements that are outlined in the App Server sizing.

l Determine the number of nodes by testing actual workloads. Refine the number of nodes

iteratively based on the resource usage and cost to improve themodel.


http://docs.kony.com/konylibrary/general/konyfabric_supported_devices_os_browsers/Default.htmhttp://docs.kony.com/konylibrary/general/konyfabric_supported_devices_os_browsers/Default.htm


l Host Configuration

Host configuration varies based on theOS used and the existing configuration standards. There

are some important steps that you need to follow after installing the OS.

l Clock synchronization using NTP or similar service. Clock skew can produce errors that are

hard to debug.

l Hostnames are used for node identification in the cluster. The hostname should not be

changed.

l Application Server Specific Settings

l The JVMHeapmemory should be configured.

l Anything specific to the Application Server such as Kony Fabric combinations that had not

been taken care of during the installation process should be configured. For example,

Configure LOG_ROOT environment variable inWebSphere for the location of logs.

l Database setup

Every database has its own specific way of setting up redundancy, archival, and load

distributionmechanisms. Contact your in-house DBA for further details.

l Load Balancer considerations

l A request forwarded from the load balancer to any of the backend nodesmust have the X-

Forwarded-For header stampedwith the source client IP address. The backend requires

the source client IP address because all the requests forwarded from the Load Balancer

would have the Load Balancer IP address.

l Kony Fabric Console and Admin components use cookies to direct requests to the node on

which the session is currently active. The same needs to be handled appropriately at the

load balancer end.

l Security considerations

l If you need to use the HTTPS protocol for communication, provide a certificate/key from a

certificate providing authority. For development environments, you can use self-signed



certificates. The SSL connection can either be terminated at the load balancer or passed

to the back-end nodes.

l /mfconsole and /admin contexts are administrative consoles and access to the same

should be restricted. For a secure approach you can use two firewalls to create a DMZ

(De-Militarized Zone). For more details on this, refer to Deployment Topology.

o The first firewall also called the perimeter firewall will route traffic to the DMZ only.

This is where the Integration or Identity Cluster along with the load balancer reside.

o The second or internal firewall will allow traffic from the DMZ to the internal

network which is where the Kony Fabric Console cluster can be set up.

o PUT, PATCH andDELETE HTTP operations need to be allowed for Kony Fabric

Console users. This will be decided based on whether the users are located within

the DMZ or the internal network.

l /authService, /middleware, /services are runtime contexts and need to be

made available publicly to end-users. Youmay need tomap different URLs for internal

users and those that would access identity publicly. Refer to Support to MAP Public

URLs - Reverse Proxy (on-premises) for more details on how this can be achieved.

l You need to whitelist manage.kony.com:443 and

orchestration.kony.com:443 for License activation. If you are unable to whitelist

domains, contact the Kony Fabric Cloud Support team to whitelist individual IP

addresses.

l Specific security hardening considerations for each Kony Fabric component are available

in the Security Hardening section.

4.1.2 Installing Kony Fabric

The Kony Fabric installer provides an automated way of installing the Kony Fabric components on a

node. The installer deploys the Application Server components and executes the database scripts

based on your inputs. For more information, refer to the Installation guides for your specific OS at Kony

Documentation.


http://docs.kony.com/konylibrary/konyfabric/kony_fabric_user_guide/Default.htm#Multi-Tenant_URL.htm?TocPath=Features|Identity|_____18http://docs.kony.com/konylibrary/konyfabric/kony_fabric_user_guide/Default.htm#Multi-Tenant_URL.htm?TocPath=Features|Identity|_____18http://docs.kony.com/http://docs.kony.com/


For cluster setups, youmust repeat the installation process for each node by selecting the use

existing DB option. After you configure the first node, you can update the encryption keys on all the

other nodes by selecting the Copy the encryption keys now check box and providing the Previous

Installation Directory. You can skip the creation of the Administration Account since you have

already configured it once.

4.1.3 Manual Steps Post-Install

l The steps for the cluster setup differ based on the Application Server used. Refer to the Case

studies for Application Server specific steps.

l Set up aMemcached Cluster for the Integration nodes, if needed. For more details, refer to

Memcache Configuration in the Integration Admin Console User Guide.

l Launch the Kony Fabric Console URL. This should lead to the registration page. Enter the

authService URL. Thismay either be the load balancer URL or the authService node URL.

4.1.4 Test the Setup

Use the following HealthcheckURLs post-deployment to check the status of a Kony Fabric

component on each node:

l For Kony Fabric console: http://:/mfconsole/health_check/all

l For Middleware: http://:/services/healthcheck


http://docs.kony.com/konylibrary/integration/kmf_integrationservice_admin_console_userguide/Default.htm#Runtime_Configuration.htm%23Memcache


l For Auth Service: http://:/authService/v1/manage/checkhealth

l For Sync: http://:/syncconsole/healthcheck

l For Messaging: http://::53409/kpns/service/healthcheck/json



4.1.5 Activate the License

Follow the instructions in the Kony Licensing Guide for activating the License based on your

deployment model.

4.2 Case Study 1 - Tomcat Multi-Node Cluster + HAProxy Load Bal-

ancer with MySQL Database


The Kony Fabric Installer includes a pre-configured Tomcat Application server which will be installed

followed by deployment of selected components during the install process.

Choice of Application Server and Database: Tomcat 8.5 andMySQL 5.7.

Node Sizing

l Two nodes for Kony Fabric Integration/Identity/Metrics, 16 GB RAM, Intel(R) Xeon(R) CPU

E5-2630 v2@ 2.60GHz.

l One node for Kony Fabric Console.

l One node for MySQL 5.7.

l One node for the LoadBalancer.


http://docs.kony.com/konylibrary/general/kony_licensing_guide/Default.htm


Host Configuration

l CentOS 6 is installed on all nodes.

l Clocks of all nodes are brought to syncwith ntpupdate.

l Hostnames are configured.

Application Server Configuration: Pre-configured Apache Tomcat 8.5.x is included in the Kony

Fabric Installer.

Database Setup: MySQL 5.7 is installed on a node with CentOS 6.

Security Considerations: Certificate/key fromCA is obtained and converted into the .pem format.

The load balancer terminates the SSLConnection and communicateswith the backend servers using

HTTP.

Load Balancer Considerations: Apache Tomcat does not include a load balancer out of the box.

However, there are several standard, and open source load balancers available which are compatible

with Tomcat. This case study usesHAProxywith the following configuration:

frontend proxy_front

bind *:80

bind *:443 ssl crt /root/konylabsnet.pem

# By default all requests(Integration/Identity) will be forwarded to

the nodes' backend

Certificate provided for ssl termination

redirect scheme https if !{ ssl_fc }

# Redirects to HTTPS if the user comes via HTTP

mode http

acl url_mfconsole path_beg /mfconsole

acl url_mfconsole path_beg /accounts



acl url_mfconsole path_beg /workspace

use_backend console if url_mfconsole

# Any request on any of the Kony Fabric Console Component contexts

will be redirected to the backend of the console

default_backend nodes

backend console

mode http

option forwardfor

# Insert the X-Forwarded-For header. HAProxy will stamp this header

with the IP of the source client

http-request set-header X-Forwarded-Port %[dst_port]

http-request add-header X-Forwarded-Proto https if {ssl_fc }

server console mbaastest26.konylabs.net:9090 check

backend nodes

mode http

balance roundrobin

option forwardfor

http-request set-header X-Forwarded-Port %[dst_port]

http-request add-header X-Forwarded-Proto https if {ssl_fc}

cookie JSESSIONID prefix nocache

server web1 mbaastest12.konylabs.net:8080 check cookie web1



server web2 mbaastest36.konylabs.net:8080 check cookie web2

4.2.2 Installation of Kony Fabric

Since this is a cluster setup, you will need to repeat the installation process for each node by selecting

the use existing DB option. After you configure the first node, you can update the encryption keys on

all the other nodes by selecting the Copy the encryption keys now check box and providing the

Previous Installation Directory. You can skip the creation of the Administration Account since you

have already configured it once.


Follow these steps in addition to the stepsmentioned in the checklist.

l Set up aMemcached Cluster for the Integration nodes, if needed. For more details, refer to


l Re-deploy theWebApps and restart the Application Servers, if needed.


l Use the HealthcheckURLsmentioned at Test the Setup post-deployment to check the status of

a Kony Fabric component on each node.

l Ensure that all health-checks are passed.


l Follow the instructions in the Kony Licensing Guide for activating the License based on your

deployment model.

l Ensure that the License is activated successfully.


http://docs.kony.com/konylibrary/integration/kmf_integrationservice_admin_console_userguide/Default.htm#Runtime_Configuration.htm%23Memcachehttp://docs.kony.com/konylibrary/general/kony_licensing_guide/Default.htm


4.3 Case Study 2 - JBOSS Multi-Node Cluster + Apache/Mod_Cluster

Load Balancer with MySQL Database


The Kony Fabric Installer needs to be configured on JBoss Application server in Domainmode. For

configuring JBossmultinode setup, follow the stepsmentioned at JBoss EAP 7.2 DomainMode

Setup.

l Choice of Application Server and Database: JBoss 7.2 andMySQL 5.7.

l Node Sizing

l Two nodes for Kony Fabric Integration/Identity/Metrics, 16 GB RAM, Intel(R) Xeon(R)

CPU E5-2630 v2@ 2.60GHz.

l One node for Kony Fabric Console.

l One node for MySQL 5.7.

l One node for the LoadBalancer.

l Host Configuration

l CentOS 6 is installed on all nodes.

l Hostnames are configured.

l Application Server Configuration: Configure JBoss 7.2

l Database Setup: MySQL 5.7 is installed on a node with CentOS 6.

4.3.1.1 Integration of Apache/Mod_Cluster with JBoss

A sample configuration of Apache 2.4 with mod_cluster module used with JBoss is shown below.

Changes have to bemade to the JBossmaster node to integrate themod_cluster load balancer.


https://basecamp.kony.com/s/article-detail/a042K00001EdZQoQAN/jboss-eap-72-domain-mode-setuphttps://basecamp.kony.com/s/article-detail/a042K00001EdZQoQAN/jboss-eap-72-domain-mode-setup


1. In the JBossmaster node, edit the/root/EAP-

7.2.0/domain/configuration/domain.xmlfile. In the socket binding groups you

are using, add the following node.

For example, if you use full-sockets binding group, go to and add following

node at the end.

//Add this Node at the end of the xml file.

2. In JBossmaster node, edit /root/EAP-

7.2.0/domain/configuration/domain.xml. Go to and to the proxy node, add the

proxies="proxy1" attribute to proxy node.

//Sample Code



3. Install Apache 2.4 and setup themod_cluster module. Configuremod_cluster as per your

requirement. Following is a sample snippet of amod_cluster configuration in Apache

httpd.conf file.

Example:

MemManagerFile cache/mod_cluster

CreateBalancers 1

Listen host1.kony.com:8020

ManagerBalancerName modcluster

AllowOverride none

Require all granted

ProxyPass "/" "balancer://modcluster/"

stickysession=JSESSIONID|jsessionid nofailover=On

ProxyPassReverse "/" "balancer://modcluster/"

ProxyRequests Off

ProxyTimeout 2400

ProxyBadHeader Ignore

UseCanonicalName On

ProxyPreserveHost On

AddDefaultCharset off

Require all granted



KeepAliveTimeout 600

MaxKeepAliveRequests 0

EnableMCPMReceive on

ServerAdvertise on host1.kony.com:8020

AdvertiseFrequency 5

SetHandler mod_cluster-manager

Require all granted

4. Start mod cluster by running the HTTP start service.

5. For setting Identity, Integration, and Console on separate nodes, accessmod_cluster console

and for each node, enable only the required requests.

Example:

Enable/Disable as required tomanage the load at each node.

4.3.2 Installation of Kony Fabric

Since this is a cluster setup, you will need to repeat the installation process for each node by selecting

the use existing DB option. After you configure the first node, you can update the encryption keys on

all the other nodes by selecting the Copy the encryption keys now check box and providing the

Previous Installation Directory. You can skip the creation of the Administration Account since you

have already configured it before.




Follow these steps in addition to the stepsmentioned in the checklist.

l Set up aMemcached Cluster for the Integration nodes if needed. For more details, refer to


l Launch the Kony Fabric Console URL. This should lead to the registration page. Enter the

authService URL. Thismay either be the load balancer URL or the authService node URL.


l Use the HealthcheckURLsmentioned at Test the Setup post-deployment to check the status of

a Kony Fabric component on each node.

l Ensure that all health-checks are passed.


l Follow the instructions in the Kony Licensing Guide for activating the License based on your

deployment model.

l Ensure that the License is activated successfully.


http://docs.kony.com/konylibrary/integration/kmf_integrationservice_admin_console_userguide/Default.htm#Runtime_Configuration.htm%23Memcachehttp://docs.kony.com/konylibrary/general/kony_licensing_guide/Default.htm

5. FAQs and Troubleshooting Kony Fabric Deployment GuideVersion1.3

5. FAQs and Troubleshooting

This section lists the troubleshooting tips to resolve problems that youmay encounter during

deployment of Kony Fabric on-premises and performance and capacity characteristics of typical

deployment scenarios.

l The /manager URL from a Tomcat installation should be blocked for access from outside the

local intranet.


6. Index Kony Fabric Deployment GuideVersion1.3

6. Index

C

capacity 18

configurations

Documents

Kony Fabric Deployment Guide · 2019. 12. 5. · KonyFabricDeploymentGuide Version1.3 RevisionHistory Date DocumentVersion DescriptionofModifications/Release 11/11/2019 1.3 DocumentPublishedfor: