ATTACHMENT I - KOG Integration.pdf

Attachment I – KOG Integration 1

ATTACHMENT I

KOG Integration

The Kentucky Online Gateway (KOG) is CHFS’ identity management and web Single Sign-On (SSO) platform. KOG must be used to manage application users and roles and to provide SSO for the application itself. KOG is built using the following technologies: Microsoft .Net 4.6.2 Framework, SQL Server 2016, and Active Directory Federation Services 2.0.

Applications must be claims-aware and integrate with KOG’s Security Token Service using the WS-Federation protocol or the SAML 2.0 protocol. A claim is a declaration made by an entity (e.g., name, identity, group, privilege, attribute, etc.). The below section discusses the fundamental architecture, technology standards, and how applications integrate with KOG.

1. SSO, Authentication, and User Provisioning

1. Access to applications will be handled through integration with KOG.

b. Web applications will interface with KOG through ADFS for SSO.

c. New applications integrating with KOG must be ADFS/WS Federation/SAML 2.0-compliant, and use vlaims for authentication and authorization.

d. KOG supports both active (WS-Trust) and passive (WS-Federation and SAML 2.0) scenarios.

e. Authorized users will have access to their applications from the KOG landing page.

2. Security Roles

a. User roles will be defined by the application. The application will determine what functions and data are available for each role and is responsible for implementing the functions and permissions of each role.

b. Users will be assigned roles in KOG using the KOG interfaces for requesting and assigning roles. A user’s role will be communicated to the application using the claims.

3. User Store

a. KOG will retain ownership of all user accounts and user profile information.

b. KOG contains user profile information as well as entitlements for registered users.

c. Applications will need to read profile information from SAML claims or integrate to

KOG APIs to retrieve profile information and entitlements.

d. Applications will make API calls directly to KOG through the secure (HTTPS) SOAP-based web services.

e. APIs will be utilized for user profile queries, retrieving application user agreements, credentialing, etc.

f. Base API will be provided for customization and implementation by onboarding application.

4. Environments

a. New applications will be responsible for all aspects of solution environment integration with KOG such as:

Attachment I – KOG Integration 2

a. Mapping and integration of application environments with KOG environments (Integrated Dev, Test, UAT, Training, Production).

b. Integration testing.

c. End-to-end testing of all API(s).

d. Performance testing.

e. Design documentation.

b. As part of the integration efforts, new applications will also be responsible for providing items such as:

f. List of application roles.

g. Workflow for each role (i.e., approvers and credentials).

h. Requirements for any claims that will be passed in the SAML token.

i. Information needed via API must be prescribed.

j. Integration documentation.

The Vendor shall not be responsible for changes in the KOG application. The Vendor shall be responsible for performing all joint application design (JAD) sessions necessary to design all security requirements, integrating the solutions into the KOG environment, and any development required by the solutions outside KOG functionality.

A. Major KOG Functionality for Internal Users

1. Application Management – Application-specific configuration in KOG.

2. Account Creation – All internal users must have an account on the existing CHFS Active

Directory and defined in KOG. If this account does not exist, KOG shall be utilized for new account creation.

3. Role Management – Each solution shall be defined as an application in KOG, and any necessary security role types shall be configured and managed in KOG. This information shall be passed to the solution.

4. Internal User Account Management – KOG will handle all user account management.

This functionality includes creating, updating, and terminating users, and user access to each application within KOG. All internal users shall be managed via KOG in order to have access to a specific role for each solution.

5. User/Usage Agreements – Enterprise and departmental user/usage agreements and user responses to such agreements shall be stored and maintained in KOG. Solutions must acquire an agreement from KOG via a web service API in order to display the agreement to the user, and must return the user response to KOG for storage.

6. Single Sign-on – All onboarding applications must participate in the KOG SSO solution, which will provide access to all solutions via the KOG landing-page without requiring the user to sign on to any of these applications and/or launching the application from each application’s web page. All application access will be initiated from the KOG landing page.

7. KOG utilizes different frameworks to implement enhanced security. For applications that require multi-factor authentication, we utilize Symantec’s services and their VIP Access clients for users.

B. Additional KOG Functionality for External Users

Attachment I – KOG Integration 3

1. User Registration – Citizen user registration shall occur via KOG. The process shall require the requesting user to provide an e-mail address, select and answer two security questions, and submit an e-mail verification response.

2. User Request for Access – Following user registration, KOG shall present the user with the ability to request access to an application.

3. Credential Management – During the request for access, the user shall be required to enter various credentialing and non-credentialing information. This information shall be made available to the user and may be updated at user request.

4. Password Management – During user registration, the user shall be required to provide a password. KOG password management includes current industry security standards as they relate to challenge questions and responses, user profile updates, and account and password resets.

C. Vendor KOG Security Responsibilities

The Vendor shall:

1. Work with the CHFS Security Team and facilitate JAD sessions necessary to identify and design all aspects of the solutions necessary to assure a seamless integration of all solutions with KOG.

2. Coordinate, communicate, and facilitate business and technical JAD sessions in order for the vendor to design and develop all security roles, credential types, and validation requirements, and any required additional components to assure robust security for all solutions.

3. Applications integrating with KOG shall be designed as ADFS/WS-Federation/SAML 2.0-compliant. The Vendor shall work with the Commonwealth Security Team to define custom claim data necessary for secure access to the solutions.

4. Design, develop, test, and implement all solution functionality required to validate credentials, pass validation and user agreement information back to KOG, assure access to information is restricted by security role and custom claim data, and any required additional security components necessary for successful implementation of the solutions.

5. Design and develop all solutions to be claims-aware and participate in SSO.

6. Design and develop all solutions to utilize role-based security.

7. Provide work necessary for the initial onboarding of users to the new solutions, which shall include, but not be limited to, working with the CHFS Security Team to compile and provide data mapping including initial User Provisioning information via KOG for all existing internal users.

8. Design, map, integrate, and test solution environments with the KOG environment including performance testing.

9. Vendor’s business applications must adhere to current functionality whenever possible.

D. Commonwealth KOG Security Responsibilities

1. The Commonwealth will assure all relevant modifications to KOG are made.

2. The Commonwealth will participate in meetings and JAD sessions as necessary.