Exhibit P - HHSC Identity and Access Management (IAM) Guide.pdf

Exhibit P Page 1 of 46 RFO No. HHS0015558v2

Exhibit P - HHSC Identity and Access Management (IAM) Guide

Guide to Onboard Applications into Modern Identity Access Management and Identity Governance Solution

May 23rd, 2022 Version 1.0

Exhibit P Page 2 of 46 RFO No. HHS0015558v2

Contents 1 Introduction

2 Application Types for Modern IAM

2.1 List of pre-requisites to be performed by application team before onboarding into Modern IAM

2.2 List of pre-requisite to be performed by IAM team before onboarding application

3 Application Onboarding Process

3.1 Create Application Onboarding or Integration Factory

4 Integration requirements

4.1 IAM functional requirements

4.2 Business factors and criteria of selection

5 Project Timelines

5.1 Timelines and multi-phases of the project

5.2 Variables that affect project timing can include:

6 Process to Onboard into Modern IAM

6.1 Integration factors

6.2 Provisioning/De-provisioning

6.3 Authentication Management (Single Sign On/Strong Authentication)

6.4 Build a Single Sign-On (SSO) integration

6.5 SAML based applications onboarding steps:

6.6 OIDC based app integrations onboarding steps:

6.7 WS-Fed app integrations onboarding steps:

6.8 Salesforce app integrations onboarding steps:

6.9 Okta Access Gateway for app integrations based on Header, Basic Authentization, AuthZ URL, Thick Clients

(Desktop based) onboarding steps

6.10 Kerberos Application Integration

6.11 Secure Web Authentication (SWA)

6.12 Build a Provisioning integration

6.13 Integrating Modern IAM with Java, .NET, ASP based applications that rely on Web Services

6.14 Integrating Modern IAM (SailPoint) with Salesforce

6.15 Integrating Modern IAM (SailPoint) with Active Directory

6.16 Integrating Modern IAM (SailPoint) with Microsoft Azure Directory

6.17 Integrating Modern IAM (SailPoint) with Mainframe

6.18 Integrating Modern IAM (SailPoint) with Microsoft SQL Server

6.19 Integrating Modern IAM (SailPoint) with XML

6.20 Integrating Modern IAM (SailPoint) with JDBC

6.21 Integrating Modern IAM (SailPoint) with Peoplesoft

6.22 Integrating Modern IAM (SailPoint) with SaaS

Exhibit P Page 3 of 46 RFO No. HHS0015558v2

1 Introduction

The purpose of this document is to describe procedure or process for onboarding applications into HHSC/DSHS Modern IAM platform which uses SailPoint Identity IQ (Identity Governance and Administration) and Okta (Single Sign-On/Access Management) to meet both the integration objectives and business requirements of the application. This document is prepared to use it as a reference model to determine complexity, timelines and efforts required for integration or onboarding of various applications. Product references and product documentation from IAM vendors (SailPoint & Okta) is captured in some of the sections to provide step by step guide to onboard your applications into the new IAM platform successfully. Use hyperlinks provided throughout the documentation to refer to the sections which are only applicable to the respective apps.

Application onboarding strategy is a key step in onboarding into a modern identity and access management (IAM) platform. Having a strong onboarding check point where all applications must go through a review process before they can go live. It gives the required visibility for the application owners who need to oversee by following below list of items as part of the process.

Integration requirements (Refer section 4)

Project Timelines (Refer section 5)

Process to onboard into Modern IAM (Refer section 6)

Application onboarding is the process of registering or associating an application with Modern IAM so that it can provision or reconcile user information in or from that application. Publish modern IAM application capabilities for walkthroughs and turn application business owners into highly engaged and informed. Explain the essential features of modern IAM application and support with onboarding or integration process.

Some of the key elements related to the application onboarding are types of application, application templates, disconnected connector applications, and transformation of provisioning and reconciliation attributes, application authentication/authorization.

NOTE: This is an active document and will be updated as and when applications are onboarded into Modern IAM.

Exhibit P Page 4 of 46 RFO No. HHS0015558v2

2 Application Types for Modern IAM

Target Application: Target applications allow user requests for provisioning accounts through the access request catalog built in Modern IAM. The target application can be either connected or disconnected. Connected application uses connector framework for all identity management. Disconnected applications must be manually provisioned by admins or helpdesk users.

o Simple to configure and use: Direct connectors are simple to configure, few configuration details required to use the connector and no extra steps to deploy agents on the end managed systems.

o Less moving parts: Direct connectors do not require Connector Gateway (CG), Connector Manager (CM), Provisioning Modules (PM) to be deployed to get the setup done. Installing and (Re)configuring each component is not required.

Data caching and sequencing on transactions not required.

Authoritative Application: For an authoritative application, SailPoint IIQ manages accounts and represents them as users across different reconciliation jobs. Authoritative applications cannot be requested through the access request catalog. For example: CAPPS HR Feed, Peoplesoft etc.

Application Technology Authentication Methods

Java Header Based .NET HTTP Basic PL/SQL OpenID Connect Visual Fox pro Security Assessment Markup Language (SAML) ASP Kerberos Desktop SSO-On PeopleSoft DB AuthN Tableau OAuth 2.0 HTML Local app authentication Salesforce or SaaS

J2EE

Application Type Connector Name/Application Type

Directory Microsoft Active Directory Active Directory - Direct

OpenLDAP Directory Server OpenLDAP - Direct

LDAP LDAP

Azure Active Directory Azure Active Directory

Database

IBM DB2 IBM DB2

Exhibit P Page 5 of 46 RFO No. HHS0015558v2

Application Type Connector Name/Application Type

(Windows and Linux)

JDBC JDBC

Oracle Database Oracle Database - Direct

Microsoft SQL Server Microsoft SQL Server - Direct

Microsoft other Connectors Microsoft SharePoint Server Microsoft SharePoint Server

Microsoft SharePoint Online Microsoft SharePoint Online

CAPPS

Oracle Human Resources Management System Oracle HRMS

PeopleSoft Human Capital Management PeopleSoft HCM Database

Other End Systems

IBM RACF RACF

Salesforce Salesforce

ServiceNow ServiceNow

SQL Loader SQL Loader

System for Cross-Domain Identity Management Connector 2.0

SCIM 2.0

System for Cross-Domain Identity Management Connector SCIM

CA Top Secret TopSecret

UNIX Unix

Web Services Web Services

Delimited File DelimitedFile

Linux Linux - Direct

Mainframe Mainframe

Windows Local Windows Local - Direct

NOTE: If OOTB connectors doesn't support for HHS application integration, custom connectors need to be developed.

2.1 List of pre-requisites to be performed by application team before onboarding into Modern IAM

Provide a complete view of all user and non-user accounts associated with an application for managing lifecycle and governance for that application.

It is imperative that application owners discuss onboarding process well in advance of application onboarding into IAM platform.

Even if the applications cannot be fully integrated to provision and SSO, don’t ignore to integrate with modern IAM systems later when application teams develop custom adaptors or connectors or when the application migrates to use one of the centralized identity stores in HHS/DSHS.

Exhibit P Page 6 of 46 RFO No. HHS0015558v2

Share the timelines for availability of developers and any major upgrades of the application planned in near future which might impact the integration timelines.

Multiple integration patterns supported by application for the development teams to use during pre-development phase.

Application owner will need to create availability or project plan to work with our teams to "make it happen" and that can be from several hours to maybe several weeks of intense teamwork.

2.2 List of pre-requisite to be performed by IAM team before onboarding application

Share IAM onboarding process for applications to follow.

Conduct JAD sessions and share questionnaire template to gather requirements.

Discuss the challenges on technical integration complexity based on how well you integrate IAM platform to the respective target applications to the effective creation of change management communication plans that should ensure application owners the clarity in the added value of changing to a centralized platform to manage their user access, entitlements, and recertification processes.

Share different methodologies to onboard applications into IAM platform.

Exhibit P Page 7 of 46 RFO No. HHS0015558v2

3 Application Onboarding Process

Application onboarding request for a new application will be created by application owner.

IAM admins or integration team will review the request and verify the target application resource requirements.

Define the application administrators.

Verify the connectivity methods supported for the application into modern IAM.

Application owner will fill out the IAM application onboarding questionnaire.

IAM team will schedule the implementation.

IAM team will build and test the connections.

The application owner will work with the IAM team to develop the Request form for First- Time users to request access to the application and available roles.

IAM team will configure IAM roles to have access to the application.

IAM team will provision any initial users with their privilege levels.

If the application is disconnected from the IAM platform, the owner and IAM team will create a protocol for conducting reconciliation audit processes to account for any orphaned accounts or unauthorized access levels with the ability to quickly deprovision applications or accounts if necessary.

Owner or IAM team will complete the application onboarding.

IAM team will work with the application owner to make any additional updates or changes.

IAM team as well as the app owner will maintain the application along with any compliance requirements.

3.1 Create Application Onboarding or Integration Factory

Application Onboarding or Integration Factory process will be composed of several context scopes:

Application Onboarding schedule prioritization

Approach to different application integration complexity types

Communication process that will be tailored accordingly to the integration complexity type

Applications that will have a simple integration (Active Directory groups integration as example) should have less complexity (more automated) than a highly complex integration type (e.g., a custom connector development integration). The success in onboarding

Exhibit P Page 8 of 46 RFO No. HHS0015558v2 application is inversely proportional to the technical integration complexity, so create a plan to the application owner accordingly to that.

Simple integrations might have more automated onboarding process. Complex integrations need more communication management to the application owners and more support to their technical teams. Onboarding applications given different integration complexity types, should be acknowledged by application owner stakeholders that it also fits their expectations.

Exhibit P Page 9 of 46 RFO No. HHS0015558v2

4 Integration requirements

4.1 IAM functional requirements

Once the previous design steps have been completed for the IAM use cases, and after initial work, team will clarify requirements of what you need from the IAM system. Collect these into a list consisting of core behavior related to end-to-end flows, features & functionalities, and application guidance.

4.2 Business factors and criteria of selection

Business Factors Selection

System Criticality Critical / Non-Critical

Data classification PII, Health Information (PHI, Public Health)

Is the application accessible over the public internet? Yes / No

Volume of records managed by the application 0-1000, 1000-10K, 10K-100K, 100K- 500K

Priority to enable Multi-Factor Authentication (MFA) Low / Medium / High

Does the application have identity and access related audit findings?

Yes / No

Has your application been prioritized as "high/critical" to enable IAM by Aug 2023?

Yes / No

Exhibit P Page 10 of 46 RFO No. HHS0015558v2

5 Project Timelines

5.1 Timelines and multi-phases of the project

Applications are prioritized based on the survey answers received from the application owners on level of efforts, complexity, system criticality, user base, authentication model, user lifecycle, current enterprise portal dependencies & application technology. High and Medium critical applications onboarding are targeted between Sep 2022 – Aug 2023. Along with these, dedicated IAM operations will target to onboard non-critical applications.

Efforts needed for a complete onboarding to a modern identity access management and identity governance solution can vary widely from two weeks to 12 weeks or more, depending on several variables including the complexity of the current environment and the team resources availability, internally, and externally, to execute the onboarding. Typical application onboarding can be divided into five phases:

1. Plan

2. Design

3. Build

4. Test

5. Deploy

Keeping onboarding seamless for end users and customers require a detailed and thoughtful onboarding and deployment plan, including a thorough regimen of post-build testing.

5.2 Variables that affect project timing can include:

How many technologies make up current identity solution?

o A simple system made up of only one or few legacy technologies can be migrated more quickly than one comprised of a dozen different homegrown technologies.

Can you leverage existing technology to eliminate redundancy and simplify the onboarding task?

o Using application gateway solution like Okta Access Gateway, HHS will be able to leverage it to help eliminate one or more legacy components.

How many applications will be governed and accessed by the new system?

25%

1. Plan 2. Design 3. Build 4. Testing 5. Deploy 6. Go Live

25% 25% 20% 5%

Exhibit P Page 11 of 46 RFO No. HHS0015558v2 o If the apps make sense to migrate them directly: for a larger set from on-prem, federate Modern IAM to it, and shutter the legacy apps over time as traffic shifts to newer cloud apps.

What kind of apps are you onboarding?

o Apps that are capable of federation are usually quick to configure. Custom apps on top of libraries can be handled with proxies and SAML. And full custom legacy apps can require deeper developer knowledge and expertise.

Do you already have defined business policies in place for on/offboarding and position/role-based access?

o If provisioning is in scope for the onboarding, then business policies around access should be decided as early as possible. If the conversation around who should get what access happens later in the process, it risks delaying the deployment. If provisioning is not in scope, the access policies can potentially be addressed in a later phase.

How available is the core internal team needed to tackle the onboarding?

o Engaging internal stakeholders is critical to leverage their unique understanding of old or complex legacy systems.

Exhibit P Page 12 of 46 RFO No. HHS0015558v2

6 Process to Onboard into Modern IAM

6.1 Integration factors

IAM application integrations serve as a configured connection between Modern IAM products (SailPoint & Okta) and applications for provisioning, user lifecycle management and authentication services.

Technical integration factors

Authentication model

User Lifecyle Management

Delegated Administration

Identity Synchronization

Does the application use Enterprise Portal/ IBM identity solution

Access certification/recertification

Authentication model o Low – SAML, OAuth, OIDC, API o Medium – Active Directory, Kerberos, WS-Fed o High – Header based

User Lifecyle Management o Low – Standard out of the box configurable workflows with CSV, API or CAPPS integration o Medium – Standard out of the box configurable workflows with AD/LDAP integration o High – Custom integration workflows

Delegated Administration o Low – One level with standard out of the box configurable workflows o Medium - Two or three levels with standard out of the box configurable workflows o High - More than three levels requiring standard and/or custom workflows

Identity Synchronization o Low – Integration with supported systems with unidirectional integration and/or with attribute sync

Exhibit P Page 13 of 46 RFO No. HHS0015558v2 o Medium – Integration with supported systems with unidirectional integration and password sync o High with bi-directional sync, attribute, and password and Very High - Multiple user IDs mapped to a single user

Use of enterprise portal o Yes – Authentication only o Yes – onboarding and user management only o No – both functions

6.2 Provisioning/De-provisioning

The provisioning functionality in IAM allows to manage and automate the exchange of user identity information in cloud-based applications and on-premises applications and services.

6.3 Authentication Management (Single Sign On/Strong Authentication)

Single Sign-On (SSO) enables users to sign on to multiple cloud-based, on-premises, or mobile applications using a single set of authentication credentials. After IAM admins configure and assign SSO application integrations, end users can sign into their account and then access their applications.

Modern IAM (Okta) uses the secure connection between a user's browser and Okta-managed application integrations to authenticate the user with one of the supported SSO integration methods.

Secure Authentication Markup Language (SAML)

OpenID Connect (OIDC)

Secure Web Authentication (SWA)

Web Services Federation (WS-Fed)

Kerberos Application Integration

Okta Access Gateway based Integration (Legacy apps)

6.4 Build a Single Sign-On (SSO) integration

Choice of protocol depends mainly on your use case, but OIDC is generally recommended for new integrations. Modern IAM supports two modern protocols for handling federated SSO:

OpenID Connect (OIDC)

Security Assertion Markup Language (SAML)

OIDC features

Exhibit P Page 14 of 46 RFO No. HHS0015558v2

An identity layer on top of the OAuth 2.0 (opens new window)protocol.

Verifies end-user identity and obtains profile information.

Lightweight and REST-based.

Ideal for mobile and cloud applications.

Newer protocol with widespread usage. Some newer applications only support OIDC.

SAML features

Widely used federation protocol for SSO in Web applications.

Many SaaS providers support SAML integration to grant SSO access to end users.

Specification doesn’t have user consent, although it can be built into the flow.

Larger in size because XML messages are transmitted back and forth.

6.5 SAML based applications onboarding steps:

Security Assertion Markup Language (SAML) is an XML-based protocol used for Single Sign- On (SSO) and exchanging authentication and authorization data between applications. Within the SAML workflow, Okta can act as both the Identity Provider (IdP) or as the Service Provider (SP), depending on your application use case.

SAML is the protocol most organizations use for SSO and enterprise security. The primary appeal for SAML comes from the fact that SAML helps reduce the attack surface for organizations and improves the customer's sign-in experience. When a user signs into an application using SAML, the IdP sends a SAML assertion to their browser that is passed to the SP. IdP verifies the user (with Multifactor Authentication (MFA), for example) before issuing the SAML assertion.

Modern IAM as Identity Provider

Okta can integrate with SAML 2.0 applications as an IdP that provides SSO to applications.

Okta additionally support MFA prompts to improve application security. When users request access to application registered with Okta, they are redirected to Okta. As the IdP, Okta then delivers a SAML assertion to the browser. The browser uses the assertion to authenticate the user to the SP.

Exhibit P Page 15 of 46 RFO No. HHS0015558v2

The user attempts to access applications protected by Okta using SAML for SSO.

Client applications act as SAML Service Providers and delegate the user authentication to Okta. The client applications send a SAML assertion to Okta to establish the user session.

Okta acts as the SAML IdP and uses SSO and MFA to authenticate the user.

Okta returns an assertion to the client applications through the end user's browser.

The client applications validate the returned assertion and allow the user access to the client application.

Modern IAM as Service Provider

Okta can also serve as the SP that consumes authentication from other SSO solutions. If user tries to sign into Okta, they are redirected to an external IdP for authentication. After the user has successfully authenticated, the external IdP returns the SAML assertion, which is then passed through the user’s browser to access the Okta services.

The user opens Okta in a browser to sign into their cloud or on-premises app integrations.

Okta acts as the SP and delegates the user authentication to the external IdP.

The external IdP authenticates the user.

The IdP sends a SAML assertion back to Okta.

Okta validates the SAML assertion from the external IdP and, if necessary, enforces MFA. Users can be created in Okta using Just-In-Time provisioning if required.

SAML based applications onboarding:

1. Application (SP) should support SAML 2.0 protocol-based communication

2. For SAML integration, the SP and IdP are expected to share the metadata (XML) information. The SP should be able to provide (at a minimum):

a) ACS Endpoint URL: SP endpoint (URL) that is responsible for receiving and parsing a SAML assertion;

Exhibit P Page 16 of 46 RFO No. HHS0015558v2

b) Entity ID: Globally unique name for an IdP or SP; and

c) SP X509 Public Certificate (if the assertion needs to be encrypted).

6.6 OIDC based app integrations onboarding steps:

OpenID Connect (OIDC) is an industry-standard authentication layer built on top of the OAuth

2.0 authorization protocol. The OAuth 2.0 protocol provides security through scoped access tokens, and OIDC provides user authentication and single sign-on (SSO) functionality. Within the OIDC workflow, Okta can act as both the Identity Provider (IdP) or as the Service Provider (SP), depending on your use case.

Modern IAM as Identity Provider

Okta can integrate with OIDC applications by acting as an IdP that provides SSO to external applications. Okta additionally support MFA prompts to improve your application security.

Identity Provider (IdP) and Service Provider (SP) initiated Federated SSO

Exhibit P Page 17 of 46 RFO No. HHS0015558v2

The user requests access to a client application.

The application delegates the user authentication and redirects the user to Okta for authentication. The application requests a token from Okta to establish the user session.

Acting as the IdP, Okta uses Multifactor Authentication (MFA) and SSO credentials to authenticate the user. Okta verifies the user, and if successful, prompts the user to grant access to the application.

If the user grants access, Okta generates an ID token containing the user identity information that the application can access.

Okta returns the authenticated user to the application.

Modern IAM as Service Provider

If a user tries to sign into Okta, they are redirected to an external IdP for authentication. After the user has successfully authenticated, the external IdP returns the OIDC token which is then passed through the user’s browser to access the Okta services.

The user opens Okta in a browser to sign into their cloud or on-premises app integrations.

Okta acts as the SP and delegates the user authentication to the external IdP.

The external IdP acts as an authorization server for Okta.

The IdP authenticates the user and sends an ID token back to Okta.

Okta validates the OIDC token from the external IdP and, if necessary, enforces MFA for user authentication. Users can be created in Okta using Just-In-Time provisioning if required.

Exhibit P Page 18 of 46 RFO No. HHS0015558v2

6.7 WS-Fed app integrations onboarding steps:

Web Services Federation (WS-Fed) is an XML-based protocol used for Single Sign-On (SSO).

Typically, WS-Fed is used to sign on to legacy Windows-based web applications and Microsoft Office 365, where Okta acts as an authorization server or Identity Provider (IdP).

Modern IAM as Identity Provider

Okta supports integrating with WS-Fed applications as an IdP that provides SSO to external applications. When users request access to an external application registered with Okta, they are redirected to Okta. As the IdP, Okta then delivers a WS-Fed assertion to the browser. The browser uses that assertion to authenticate the user to the application.

Using WS-Fed, the user attempts to access client applications protected by Okta.

Client applications act as WS-Fed Service Providers (SP) and delegate the user authentication to Okta. The client applications send a SAML assertion to Okta to establish the user session.

Okta acts as the WS-Fed Identity Provider and uses SSO and Multifactor Authentication (MFA) to authenticate the user.

Okta returns a WS-Fed assertion to the client applications through the end user's browser.

The client applications validate the returned assertion and allow the user access to the client application.

Configure WS-Federation for Office 365

There are two sign-on methods for Microsoft Office 365 available in Okta: Secure Web Authentication (SWA) and WS-Federation (WS-Fed), which is the more secure and preferred method.

Exhibit P Page 19 of 46 RFO No. HHS0015558v2

SWA relies on a username and a password for security credentials that can be selected by the end user or assigned by the administrator

WS-Federation is a specification that defines mechanisms to transfer identity information using encrypted SOAP messages. It adds an additional level of security.

WS-Federation does not require a separate password for Office 365; consequently, Okta does not need to sync user passwords when WS-Federation is used.

6.8 Salesforce app integrations onboarding steps:

Security Assertion Markup Language (SAML) is a standard for logging into applications. The single sign-on (SSO) login standard is more secure and convenient than using a username and password.

In the Admin Console, go to Applications > Applications.

In the search field, enter Salesforce and click Salesforce.com.

Click the Sign On tab.

Click Edit, select SAML 2.0, click view setup Instructions, and follow the instructions for successful integrations.

6.9 Okta Access Gateway for app integrations based on Header, Basic Authentization, AuthZ URL, Thick Clients (Desktop based) onboarding steps

Access Gateway is built and deployed to sit in front of a secure web application. When Access Gateway receives a request from a user, depending on the application policy, it will let the user access the web app without requiring any authentication. Initially, it redirects the user to Okta for authentication (per tenant specific Okta Authentication Policy). After authentication, the Okta tenant sends a SAML assertion to Access Gateway. Access Gateways performs its own authorization checks on the URL before allowing the user's request to be sent to the web application.

Access Gateway supports adding various common and proprietary application types, such as applications based on header, cookie, Kerberos, Oracle, and so on.

Exhibit P Page 20 of 46 RFO No. HHS0015558v2

6.10 Kerberos Application Integration

Application considerations for Kerberos app to be integrated with Okta:

Application should support Kerberos integration

Application needs to have a DNS resolvable domain name (desktop Kerberos apps not able to integrate with OAG)

Okta Access Gateway (OAG) compatible with Microsoft IIS IWA -IIS 7 or later & Microsoft OWA IWA - IIS 7 or later apps

If multiple Kerberos apps exist on the same server, they will need to be bound to different ports using the servers FQDN as a URL

User Flow

1. User signs in.

2. Okta send user identity to Access Gateway.

3. Access Gateway accesses the predefined KDC with credentials.

4. KDC returns a Kerberos ticket.

5. Access Gateway redirects to backing application.

6. Application returns completed request.

7. Access Gateway performs rewrites and returns request

Exhibit P Page 21 of 46 RFO No. HHS0015558v2

6.11 Secure Web Authentication (SWA)

Application considerations for SWA SSO:

1. Web application has login page accessible from browser.

2. Okta’s SWA SSO can be leveraged when application doesn’t support OIDC, WS-Fed, or SAML. SWA is Okta solution to web apps that don’t support federation protocols, Okta stores encrypted username and password to pass to app.

3. End user is required to use Okta Browser plugin for SWA functionality

4. User can set username + password, or admin can: #1 set username + password. #2 admin sets username, user sets password. #3 admin sets SWA app username + password to be the same as Okta username + password. #4 all users share same username and password for app (single shared account).

5. Users will still be able to access website and login outside of Okta

6. SWA is a catch all solution for website apps where no other SSO integration pattern is supported by the application.

User Flow

1. The user logs into Okta

2. When the user successfully logs into Okta, they will click on the SWA app chiclet assigned to them

3. The App access request is sent to Okta

4. Okta passes the user's credentials for that app to the login screen and access is granted

MFA with Okta

Any app integrated with Okta can be protected with MFA

MFA can be configured for:

Authentication Account Recovery

Exhibit P Page 22 of 46 RFO No. HHS0015558v2

An Okta admin can configure MFA at the organization or application level. If both levels are enabled, end users are prompted to confirm their credentials with factors both when signing into Okta and when accessing an application.

MFA conditions can be evaluated against:

User type

Group membership

Specific users

Device state

Device platform

User's IP range

User's IP geolocation

Any user profile value with custom Okta Expression Language expression

Application type Description Configuration details

Cookie Out of the box Access Gateway application based on cookies.

This integration passes data as cookie content.

When executed, the application prints out all passed cookie data.

Header Out of the box Access Gateway header web application type with IDCS attributes.

This integration passes data as headers to an application. When executed, the application prints all passed header fields.

Policy Out of the box Access Gateway policy application type

This sample demonstrates creating a set of example policies. When executed, the application performs tests against these policies.

Proxy Out of the box Access Gateway policy application type

This sample demonstrates a basic proxy application. When executed, the application displays simulated access to the back-end proxy host.

Exhibit P Page 23 of 46 RFO No. HHS0015558v2

Application type Description Configuration details

Header Based A header web application type

This configuration is best used for applications that don't require specific settings. Access Gateway provides SSO using HTTP headers to this application.

Supported versions:

Any that use HTTP Headers.

Microsoft IIS

IWA

Microsoft OWA

IWA

Microsoft SharePoint IWA

Microsoft Kerberos based application type

The Microsoft IWA-based application types enable Access Gateway to work with Kerberos-based back-end applications.

Supported versions:

Microsoft IIS IWA -IIS 7 or later

Microsoft OWA IWA - IIS 7 or later

No-auth No authentication application

The no-auth configuration enables an application to be reverse proxied by Access Gateway without any authentication. This configuration is best used when exposing internal applications to the internet.

PeopleSoft PeopleSoft application The PeopleSoft configuration enables Access Gateway to SSO with Oracle PeopleSoft applications. By default, this application passes the PSUSER header to the PeopleSoft application. PeopleSoft must have been configured to enable SSO. Contact Oracle for assistance with PeopleSoft SSO configuration.

Supported versions:

v9.2.00 or later.

Salesforce Salesforce The Access Gateway Salesforce configuration enables SSO with Salesforce.

Exhibit P Page 24 of 46 RFO No. HHS0015558v2

What is an Okta AD agent and why do we need it?

Okta AD agents are lightweight agents that can be installed on any Windows Server and is used to connect to on-premises Active Directory for user provisioning, deprovisioning, and authentication requests.

Okta (Identity-as-a-Service platform) will communicate with the on-prem HHS Active Directory (AD) domains via its AD agent which will be installed on-prem on a domain member server.

Exhibit P Page 25 of 46 RFO No. HHS0015558v2

6.12 Build a Provisioning integration

User Provisioning or Group Provisioning process ensures user accounts are created, updated, deleted, and given proper access across applications and systems at the same time.

Application owners can define provision process and how it should work by gathering user data, identifying what business roles the user should hold, and automating which accounts and groups they should have access to.

Connectors : Provide interfaces to managed resources for reading user account data and provisioning changes from IdentityIQ down to target IT systems and applications. IdentityIQ provides one of the largest collections of connectors. SailPoint offers the following kinds of connectivity to your applications:

Application Type Connector Name/Application Type

Directory Microsoft Active Directory Active Directory - Direct

OpenLDAP Directory Server OpenLDAP - Direct

LDAP LDAP

Azure Active Directory Azure Active Directory

Database

IBM DB2

IBM DB2

(Windows and Linux)

JDBC JDBC

Oracle Database Oracle Database - Direct

Microsoft SQL Server Microsoft SQL Server - Direct

Microsoft other Connectors Microsoft SharePoint Server Microsoft SharePoint Server

Microsoft SharePoint Online Microsoft SharePoint Online

CAPPS

Oracle Human Resources Management System Oracle HRMS

PeopleSoft Human Capital Management PeopleSoft HCM Database

Other End Systems

IBM RACF RACF

Salesforce Salesforce

ServiceNow ServiceNow

SQL Loader SQL Loader

System for Cross-Domain Identity Management Connector 2.0

SCIM 2.0

System for Cross-Domain Identity Management Connector SCIM

CA Top Secret TopSecret

Exhibit P Page 26 of 46 RFO No. HHS0015558v2

Application Type Connector Name/Application Type

UNIX Unix

Web Services Web Services

Delimited File DelimitedFile

Linux Linux - Direct

Mainframe Mainframe

Windows Local Windows Local - Direct

NOTE: If OOTB connectors doesn't support for HHS application integration, custom connectors need to be developed.

LCM - User Onboarding can be implemented in 2 different ways in SailPoint

1. Self Service Registration

Commonly, Identities are created in IdentityIQ when a new account is detected on and aggregated from an authoritative system but the Self-Service Registration functionality through which a new user can request creation of an IdentityIQ account. This functionality is accessible through a link on the IdentityIQ login page. Self-Service Registration page can also be linked directly, bypassing the login page; this means that customers can provide a link on another website (such as the company’s internal website) or in an email message that takes new users directly to the self-service registration form.

2. Direct Connector Integration

The identities in SailPoint are created in IdentityIQ using direct authoritative application connectors and configured life cycle events(Joiner, Mover, Leaver etc.)the data is pulled from HR source on scheduled basis.

a. Life Cycle Events – The (Joiner, Mover, Leaver etc. ) life cycle events are configured in IdentityIQ which are triggered during identity refresh run after the aggregation from direct source connector application during this events the new identities are created/modified/change of user status etc. are achieved.

• Birth Right Provisioning (Roles/Entitlements) - Birthright Provisioning is the assignment of specific access based on the creation of a new Identity. The access might be specific to Identities in a certain department or region, it might apply to employees vs. contractors, or it might be automatically granted to all Identities with no qualifications. Additional steps could be added to workflows to manage provisioning of birthright access, though this is usually more easily handled through actions that can be set up to occur automatically on identity creation.

• The two most commonly implemented methods of accomplishing this are:

Using Joiner Lifecycle Events

Exhibit P Page 27 of 46 RFO No. HHS0015558v2

Using Roles (recommended method)

b. Access Requests - The users in IdentityIQ are allowed to raise add/remove requests to the catalog of items that contains Roles, Entitlements etc. for each specific application onboarded

6.13 Integrating Modern IAM with Java, .NET, ASP based applications that rely on Web Services

Connecting Modern IAM (SailPoint) to your Java, .NET, ASP based applications using Web Services allows you to configure any web service supported managed system which can read and write on the managed system using the respective managed system. Web Services supports JSON and XML for read and write.

The Web Services provides support for sending data for multiple users in a single API call. If the application supports sending data for multiple users in single call, the single API call can be enabled/configured by adding the evalPattern.

The Web Services Connector is developed with an idea where any web service supported target system can be configured. This connector would be able to perform read and write operation on the target system using the respective target system web services.

Note: Web Services Connector supports JSON and XML for read and write.

Attributes Description pattern Repeated pattern for set of Users in the request.

delimiter Delimiter for the repeated patterns.

count

(Optional) Specifies the number of users data to be sent with the request endpoint.

The default value is:

10 for query parameters

50 for Body parameters

Lifecycle manager requests can make requests for themselves or for other identities. In a typical configuration:

Managers can make requests for their direct reports.

Help desk users can make requests for themselves and others.

Any user can make requests for themselves.

Supported Features:

Exhibit P Page 28 of 46 RFO No. HHS0015558v2

SailPoint Web Services Connector supports the following features:

Account Management

Aggregation, Refresh Accounts

Create, Update, Delete

Enable, Disable, Change Password

Add/Remove Entitlements

Account - Group Management

Aggregation, Refresh Groups

Configuration parameters

This section provides the following type of configuration parameters of SailPoint Web Services Connector:

Basic configuration parameters

Operation specific configuration parameters

Parameters Description

Base URL* The base URL to connect to the web service target system.

Authentication Method* Authentication method that is supported by the target system

OAuth2 API Token

Basic Authentication No Authentication

Note: SOAP Web Services supports only Basic Authentication method.

Schema Attribute for Account Enable status

Attribute name and value required to be provided to check the Enable status.

For example, status=Active

Request Timeout (In Seconds) Request Timeout Value in seconds

Lifecycle Event Trigger Business Process Involved

Joiner Identity Creation Lifecycle Event – Joiner

Exhibit P Page 29 of 46 RFO No. HHS0015558v2

Leaver Attribute Change: Inactive attribute change from false to true

Lifecycle Event – Leaver

Manager Transfer / Department Change

Manager Change / Department Change and Birthright provisioning rule trigger for new department

Lifecycle Event – Manager Change / Department Change

Reinstate Attribute Change: Inactive attribute change from true to false

Lifecycle Event – Reinstate

6.14 Integrating Modern IAM (SailPoint) with Salesforce

Integration with Salesforce gives policy-based access controls so that the right users can get access. This integration enables governance which not only allows applications manage internal users but also users groups. To manage the account data, either create an identity profile based on the source or verify that the accounts you load are correlated to an existing identity. The SailPoint Salesforce Connector supports reading and provisioning of Salesforce accounts, profiles as account groups and implement the sailpoint.connector interface.

Exhibit P Page 30 of 46 RFO No. HHS0015558v2

SailPoint Salesforce Connector supports the following features:

• Account Management o Manages Salesforce users as Accounts o Aggregation, Refresh Accounts o Create, Update, Delete o Enable, Disable, Change Password o Add entitlement (Account-Groups, User Roles and Remove Role) o Add and Remove entitlements (PermissionSet, PublicGroups)

Note: Administrator Reset Password operation does not set password provided for the user account. Salesforce sends Email Notification with temporary password to the user for these operations.

• Account - Group Management o Manages Salesforce Profiles as Account-Groups o Aggregation, Refresh Groups o Aggregate PermissionSet attribute as group object

• Permission Management o Application reads permissions directly assigned to groups as direct permissions during group aggregation.

o The connector does not support automated revocation of the aggregated permissions and creates work item for such requests

6.15 Integrating Modern IAM (SailPoint) with Active Directory

Applications which rely on Active Directory for user management, group management can provision access to their respective applications via SailPoint.

The Active Directory connector provides the ability to provision users, groups, contacts, and entitlements. The connector supports the following features:

• Account Management o Active Directory Users o Active Directory Contacts o Account - Group Management

6.16 Integrating Modern IAM (SailPoint) with Microsoft Azure Directory

SailPoint Azure Active Directory connector manages the users and groups in Windows Azure Active Directory. SailPoint Azure Active Directory Connector can be used to manage Users

Exhibit P Page 31 of 46 RFO No. HHS0015558v2 and Groups as Windows Azure Active Directory is the directory for all cloud based organizational Microsoft directory services including Microsoft Office365.

SailPoint Azure Active Directory connector can also be used to provision users into a federated domain in Azure Active Directory. The SailPoint Azure Active Directory connector uses Azure AD Graph API to manage users, groups, and licenses.

The Azure Active Directory connector supports the following features:

• Account Management o Aggregation, Delta Aggregation, Get Account, Partitioning Aggregation, Pass Through Authentication o Create user in Azure Activity Directory, o Create user in a federated domain in Azure Active Directory.

o Update, Delete users in Azure Active Directory o Enable\Disable users, o Set password

• Add\Remove Entitlements:

o Add\Remove individual license plans o Add\Remove license packs o Add\Remove Roles o Add\Remove user's group membership o Account - Group Management

Aggregation, Delta Aggregation, Get operation for Security groups and Mail Enabled Security Groups

Create, Update Security Groups

Delete Security Groups, Mail Enabled Security Groups

• Configuration parameters

This section contains the information that this connector uses to connect and interact with the application. Each application type requires different information to create and maintain a connection.

The Azure Active Directory connector uses the following connection parameters:

Attributes Description

Azure AD application client ID

ID of the application created on the Azure Active Directory for using Graph REST API.

Exhibit P Page 32 of 46 RFO No. HHS0015558v2

Attributes Description

Azure AD application client secret key

Client secret of the Azure Active Directory application.

Azure AD domain name

Name of the Azure Active Directory domain to be managed.

For example, contoso.onmicrosoft.com

Page Size Number of records per page. Default: 500

IQService Host Host name of the system where IQService is installed.

IQService Port Port number used by the IQService

CreateAccount Timelag

Time in seconds to wait after create account and before calling get account. Default: 20 seconds

For example, <entry key=”createAccountTimelag” value=”20”> maxReadTimeout Time in seconds to wait for getting response from the REST call, in the read operation, before operation gets timed out.

Default: 180 seconds.

For example, <entry key=” maxReadTimeout” value=”200”> maxRetryCount Indicates the number of time read operation must be retried on retry errors for the read operations. Default: 5

For example, <entry key=” maxRetryCount” value=”6”>

RetryableErrors OnAgg

List of error which must be retried if occurred during aggregation or get operation. Type: List of strings userPartitions List of filters to be applied during account aggregation to limit set of data.

userFilters Filter that defines the scoping condition for Accounts to be applied during account aggregation to limit set of data.

Following is an example for userFilters configuration attribute:

<entrykey="userFilters"value="(startswith(displayName,'A' )andaccountEnabled eq true)"/>

Exhibit P Page 33 of 46 RFO No. HHS0015558v2 groupFilters Filter that defines the scoping condition for Groups to be applied during account-group aggregation to limit set of data. Following is an example for groupFilters configuration attribute:

<entrykey="groupFilters"value="(startswith(displayName,' A') orstartswith(displayName,'B'))"/> partitionHost (Applicable only for partitioned account delta aggregation only) The partitionHost is the host on which all delta partitions must be executed. Following is an example for partitionHost configuration attribute:

<entry key="partitionHost" value= "myhost">

6.17 Integrating Modern IAM (SailPoint) with Mainframe

SailPoint Mainframe Connector is a read only connector which uses a technique called screen scraping and each deployment must write Rules to drive the login/logout/fetch accounts. The connector parses the screens and emulates the user during the interaction. On legacy systems screen scraping is the only way to get to the data needed by IdentityIQ. Each Mainframe connector requires a lot of hands-on configuration, because the Rules that drive this connector are very specific to the application on which the connector is running.

The Mainframe connector is designed for applications and built on the IBM Host Access API libraries. You must have the IBM Host Access API libraries before working with this connector.

You can purchase these libraries from IBM.

Configuration parameters

The Mainframe connector uses the following connection attributes:

Parameters Descriptions host The host of the server to which you are connecting port The port the server is listening through user The valid username with which to connect to the server password The password associated with the connection user logonRule The rule used to log on to the application

Exhibit P Page 34 of 46 RFO No. HHS0015558v2

Parameters Descriptions logoffRule The rule called to log off of the application userIterate Regular Expression

The regular expression that should be used when fetching/iterating accounts. This expression breaks the screens into records that can be manipulated by the script.

userTransformRule The rule called for each record delineated by the regular expression. This rule takes the text from the screens and converts it to a ResourceObject.

userIterateCommand The command used to natively iterate over all users defaultTimeout The length of time scripts should wait for data to be returned during command execution.

defaultIdleTimeout The length of time the screen should be idle before timing out.

morePrompt The prompt scripts should expect to receive to indicate there is more data on the screen readyPrompt The prompt scripts should expect to receive to indicate the mainframe is ready

6.18 Integrating Modern IAM (SailPoint) with Microsoft SQL Server

Microsoft SQL Server is a relational database management system developed by Microsoft.

As a database, it is a software product whose primary function is to store and retrieve data as requested by other software applications, be it those on the same computer or those running on another computer across a network.

SailPoint Microsoft SQL Server Connector supports the following features:

Account Management o Manage Microsoft SQL Server Login Users as accounts o Manage Microsoft SQL Server Database Users connected to Login Users as attributes of Server login User account o Aggregate, Refresh Accounts

Create, Update;

Delete

Exhibit P Page 35 of 46 RFO No. HHS0015558v2 o Server Login Accounts: The deletion of any server login account would trigger the deletion of associated Database accounts provided that database is not excluded.

o Database Accounts: For deletion of the Database account, all the database roles corresponding to the database account must be removed.

Enable, Disable, Change Password Add/Remove Entitlements

Account - Group Management o Aggregate Microsoft SQL Server Database Roles and Server Roles as Account- Groups o Aggregate, Refresh Groups o Create and Delete only Database Roles

Permissions Management o Permissions directly assigned to accounts and groups as direct permissions during accounts and groups aggregations respectively.

o Revocation of the aggregated permissions for accounts and groups.

Configuration parameters

Parameters Description

URL A valid URL of Microsoft SQL Server with the following format:

jdbc:sqlserver://[serverName[\instanceName][:portNumber]] jdbc:sqlserver://: (Required) is known as the sub-protocol and is constant.

serverName: is the address of the server to connect to. This could be a DNS, IP address, localhost, or 127.0.0.1 for the local computer.

instanceName: is the instance to connect to serverName.

portNumber: is the port to connect to…