BACK TO MENU

BACKGROUND 

Currently, Kenya Airways is experiencing the following main IAM challenges and control gaps:

•There is no centralized iden ty & authen ca on store. Some systems are integrated to Microso  ac ve directory while others locally manage their iden ty access management. This is compounded by the fact that Kenya Airways has a hybrid of on‐premise and cloud systems 

from different vendors running on multiple platforms and technologies.

•The main authen ca on mode into Kenya Airways applica ons is via use of passwords. There is no consistent enforcement of strong authen ca on or applica on of mul ‐factor authen ca on

•Users have mul ple passwords across different applica ons. There is no Single Sign On (SSO) solu on in place and users o en write down passwords or use the same password for different applica ons thereby increasing the risk of compromise of Kenya Airways informa on 

systems.

•System users’ on‐boarding and off‐boarding process is largely manual. Same case applies for movements within the organiza on such as transfers or promo ons. Joiners, movers and leavers processes and associated systems are disjointed

•Changes in applica on access are reviewed manually on a quarterly basis by the business applica on owners. There is no automated process to manage, monitor or review user access to KQ systems. 

SCOPE OF SERVICE
The partner will be expected to provide a solution that will;

Single Sign On 
Importance Vendor Response
(SSO)

Ability to utilize open standards for authentication (e.g. SAML v1.1 and v2.0, WS‐Fed, WS‐Trust, OpenID Connect) as well as proprietary SSO methods (e.g. for forms‐based auth or 
A.1 Critical
basic auth).

A.2 Ability to support SSO into web applications using secure credential posting, e.g. form‐posting techniques. Critical

Forms‐based authentication SSO must only require a user to enter their password for initial configuration of a target application.  A user can then log in to the identity service from 
A.3 Critical
any machine and any browser, and not have to enter in an app password again.

For forms‐based applications, user can go directly to a target application in a browser window and identity service will recognize the application is configured for SSO and offer to 
A.4 Critical
automatically authenticate the user.

A.6 Built‐in integrations to over 5000 of applications, with ongoing testing and repair of integrations as applications change authentication mechanisms. Critical

A.7 Ability to easily add any web‐based app with a login form to the IAM solution, if needed, using a simple wizard‐based approach. Secondary

A.8 Ability to add any SAML v1.1, SAML v2.0 or OpenID Connect app to the IAM solution. Critical

A.9 Ability to enable Desktop SSO with no desktop client agent software. Desktop SSO = extended SSO into web applications after successful authentication to Windows domain. Critical

A.10 Enhanced password policy with ability to configure complexity requirements, password age and lockout attempts.   Secondary

A.11 Ability for Admin to generate random one‐time‐password (OTP) and force password change on login attempt. Critical

A.12 Ability to enforce strong passwords and sessions timeouts. Secondary

A.13 Ability to apply access policy for sign‐in to the IAM system, or sign‐in to an individual application. Policy can allow or deny access, or require multifactor authentication. Secondary

A.14 Ability to apply protocol as context for policy (e.g. limit web access to Office 365 off‐network but allow ActiveSync) Secondary

A.15 Integration of any application or system via RADIUS, and ability to apply flexible access policy per RADIUS integration. Secondary

Integrations with leading network gateway products (e.g. F5 BIG‐IP, Citrix NetScaler) for reverse proxy behind the firewall and support for legacy applications (e.g. header‐based 
A.16 Secondary
authentication).

Multi Factor Authentication

B.1 Built in support for multi‐factor authentication (MFA) that includes security questions, smartphone soft tokens apps with push capability, or SMS (text message) as optional factors. Critical

B.2 MFA solution is built into the identity service, with reporting and policy all centrally configured in one place. Critical

B.3 MFA solution allows for flexible policy, such as applied per application, by Active Directory security group or by IP address. Critical

B.4 Ability to support end‐user self‐service 2nd factor configuration (i.e. self service mobile app for MFA soft token). Secondary

B.5 Administrator control over which 2nd factors users are allowed to use, and ability to assign specific factors based on group. Secondary

B.6 Integration of cloud‐based MFA to a VPN supporting RADIUS. Secondary

B.7 Support for voice as a 2nd factor Secondary

B.8 Support for Apple TouchID for additonal verification on iOS devices Secondary

B.9 Windows Hello (Win10) and Email as 2nd factors Secondary

B.10 Support for multiple tokens in smartphone soft token app. Secondary

B.11 Common Password Detection Secondary

Mobilile Capability  Requirement

C.1 Authentication support for iOS and Android mobile devices; both native mobile applications and mobile web applications. Critical

Mobile web SSO support via purpose‐built native mobile application for iOS (iPad, iPhone) and Android.  SSO native app includes a UI designed for appropriate phone or tablet form 
C.2 Critical
factor and has multi‐tab capability for multiple web apps to be open at the same time.

C.3 Mobility Management enables automated password sync of changed AD password to the email/calendar configuration a managed device. Critical

C.4 Change AD password from mobile app. Secondary

C.5 Mobile SSO from Safari for iOS to both forms‐based applications and SAML applications Secondary

C.6 Native mobile app SSO on iOS and Android (with Android for Work) Secondary

Mobility Management Requirements
Q.1 Mobility Management should automatically wipe business applications from user’s device when user is deactivated in Active Directory, and leave personal applications untouched. Critical

Q.2 Mobility Management should control sharing of data between corporate and personal apps. Critical

Q.3 Enable self‐service enrollment in EMM solution for end users Critical

Q.4 Automatically provision email, device configuration, and applications to enrolled mobile devices based on user identity Critical

Q.5 Provide end users an app store to find and download mobile applications Critical

Q.6 Support for customizable text to be displayed to end users during enrollment for custom acceptable use agreements. Critical

Q.7 Enforce PIN/passcde policies on devices, such as length, complexity, and re‐use limits Critical

Q.8 Restrict sharing of data between applications so only managed applications are allowed to share managed data Critical

Q.9 Protect and restrict enterprise data on devices without proprietray containerization Critical

Q.10 De‐provision devices both with full factory reset as well as selective wiping of only managed data Critical

Directory Integration

D.1 Supports secure integration with Active Directory with one integration that supports delegated authentication to AD and AD‐driven provisioning and deprovisioning. Critical

Active Directory integration components / agents must be able to deploy with redundancy for High Availability. Additionally, High Availability  should be achieved without 
D.2 Critical
additional configuration, i.e. the Agents should automatically recognize each other and provide redundancy.

D.3 SSO service must be able to authenticate users who are not on the corporate network to Active Directory behind the firewall. Critical

D.4 AD integration components / agents should all be configured centrally within the main admin console of the identity service.  Critical

D.5 Support for using AD group membership to configure access to all SSO enabled applications. Critical

D.6 End‐user capabilities for self‐service password change and password reset. Including changing / resetting Active Directory passwords. Critical

D.7 Ability to access the end user home page outside of the company network without making any firewall changes or putting additional applications or servers in the DMZ. Critical

Ability to integrate a single cloud‐based directory with multiple Active Directory domains/forests and multiple LDAP directories and manage access across all users to a single set of 
D.8 Critical
integrated applications.

D.9 Must require NO changes to the corporate firewall for integration to Active Directory. Critical

D.10 Must require NO changes to the corporate firewall for integration to LDAP user stores. Critical

D.11 End‐user capabilities for self‐service password change and password reset. Including changing / resetting Active Directory passwords. Critical

D.12 User should be able to change or reset his/her Active Directory password from outside the firewall via the cloud‐based portal for the identity service. Critical

D.13 Enforces password policy configured in Active Directory for AD‐mastered users. Critical

Active Directory synchronization should include not just user attributes, but also AD Security Group definitions, structure, and membership. This group information should be 
D.14 Critical
automatically imported as part of initial configuration, and automatically kept up to date if AD groups change.

D.15 AD integration supports both scheduled imports and Just‐In‐Time (JIT) provisioning of users into cloud IAM at the same time Secondary

D.16 AD integration provides flexibility in how users, groups and OUs are imported, and supports limiting some data from being imported to the cloud. Secondary

Data & Analytics

Fully searchable system log that is updated within milliseconds with events happing in the IAM system, to enable real‐time investigation and remediation of potential security 
E.1 Critical
incidents.

E.2 Ability to provide insight into cloud app usage vs. seat licenses, to enable improved seat utilization of cloud applications. Secondary

E.3 Ability to provide easily readable dashboards for management staff. Secondary

E.4 Provide security logging to validate that only authorized users are accessing the system, and accessing authorized applications. Critical

E.5 Built‐in reporting that shows who is accessing what applications, frequency, etc. Critical

E.6 Integration to 3rd party SIEM systems for comprehensive company‐wide analytics. Secondary

Provisioning

F.1 Over 120 application integrations that support provisioning Critical

F.2 User provisioning into applications must be able to transfer role/profile information in addition to username and password. Critical

F.3 Provisioning capability must have the option of being driven by an HR system, and the ability to write profile data pulled from the HR system to Active Directory. Secondary

F.4 An ability to provision users to on‐premises applications, custom applications, or other cloud applications not pre‐integrated. Secondary

F.5 Ability to utilize open standards for provisioning, such as SCIM, as well as proprietary provisioning APIs. Critical

F.6 Provisioning integrations that sync a rich profile should automatically discover the schema of the integrated application or directory to assist in attribute mapping. Critical

F.7 Support for real‐time integration and write‐back of attribute data to Workday Secondary

F.8 Provisioning to AD supports writing users with rich profiles, group memberships, and assignment of OU. Secondary

F.9 Offboarding workflow, to move data to a service account or revoke a license in a configurable way when deprovisioning a user.  Secondary

F.10 Ability to configure app‐specific features during provisioning, such as a Box personal folder. Secondary

Solution Architecture Requirements
G.1 Programmatic access to the IAM to allow the IAM solution to be used as the identity layer within a custom‐built web application or multi‐tenant cloud service. Secondary

G.2 Ability to embed application URLs in intranet sites to allow users to log in to or access applications from an intranet or portal. Critical

G.3 Programmatic interface that is exposed as REST API endpoints.   Secondary

REST API that enables custom‐built applications to create, read, update and delete (CRUD) users, groups and organizations, manage sessions, authenticate users, and provide 
G.4 Secondary
application links for any user

G.5 REST API should be accessible to any application that is behind the firewall or in the cloud without making network or firewall configuration changes. Secondary

G.6 SDKs, documentation and support for the REST API. Secondary

Login widget that supports login, password change and reset, MFA and other authentication flows, can be inserted into a custom web page with a few lines of code, and easily 
G.7 Secondary
configured.

Customization and Flexibility
‐Self Service Registration
G.8 ‐Customer email domains and URLs Secondary
‐Custom URL domains
‐Hosted and Self Hosted Sign‐in Page

G.9 Identity Proofing Secondary

Directory

I.1 Must include a directory or user store that has demonstrated scale at millions of users and millions of authentications per month. Secondary

I.2 Directory must be fully extensible, supporting an unlimited number of attributes Critical

Directory must provide for separate user profile schemas for each external directory integrated to the service and for each app integrated.  The directory must then allow 
I.3 administrators to custom‐map fields between each directory or app and the main directory of the service.  Mappings should be able to be configured differently for inbound or  Critical
outbound flows.

I.4 Directory must have capability to configure transformations of attributes between integrated directories or applications. Critical

I.5 Granular user lifecycle states, including suspend and delete states Critical

I.6 Expose the IAM users/groups as a LDAP server  Critical

General Product Requirement

J.1 Agile development process with feature releases on a weekly basis.  Service is updated without being taken offline. Secondary

J.2 Must not incur performance degradation (for the IAM service itself and for the applications it connects to) for remote or distributed workers. Critical

J.3 Must contain a unique user global ID that can be mapped to any username format across all applications and user directories. Critical

J.4 Ability to support automatic user account creation (aka JIT provisioning), into the IAM service itself. Secondary

J.5 Ability to brand the end user homepage / sign‐in page and support for a custom‐designed end‐user UI. Secondary

J.6 Provide a central location for user and application management. Critical

J.7 Certification of user access to facilitate compliance requirements. Secondary

Vendor Management Product Road‐map & Viability

Company should have Sales Engineers located in your area for dedicated pre‐sales and evaluation support, and should also have 24x7 live support options for post‐deployment 
L.1 Critical
technical questions.

L.2 Company should have a professional services team that can help with deployments, customization (if needed), and training. Critical

L.3 Company’s professional services team should provide an implementation strategy and sample plan. Critical

L.4 Company should have a support team, with expertise not only in identity management but also in enterprise software and cloud and SaaS applications and architectures. Critical

Company should be able to show reference customer case studies, but should also be able to provide customers for specific reference questions. The customers should include 
L.5 Critical
deployments of 5,000 employee end users, or over 500k customer/partner end users, and should include customers with global deployments.

L.6 Company should be able to show financial strength, through verified, credible investor backing, a strong balance sheet, or both. Critical

L.7 Provide your product road‐map and strategy for the next  3 Years?

L.8 Describe how you are managing your product strategy? Competition, Market, Positioning, Customer requirements? How is this communicated and how often?

L.9 Company should be able to show 2500+ customers who are running on the service or product during the time of evaluation. Secondary

Security and Reliability Requirments

M.1 SLA must not allow for planned downtime for maintenance windows ‐ i.e. "planned downtime" is not acceptable. Critical

M.2 All components of the service must conform to the SLA terms, including components used for integrations, e.g. Active Directory integration components. Critical

M.3 The IAM vendor must maintain application support, e.g. the IAM vendor accommodates changes to application APIs. Critical

Company should be CSA STAR Level 2 (attestation) compliant and able to provide SOC 2 (Type I and Type II) reports documenting the security practices of their product, technology, 
M.4 Critical
personnel and company.

An on‐demand IAM company should be able to show how data is encrypted, how personnel are managed and secured, and how user information is kept safe. Detailed 
M.5 Critical
documentation should be provided in this area.

Company that is offering an on‐demand or cloud‐based service should be able to provide 3+ years of uptime reporting for their service. All outages, even those for maintenance or 
M.6 Critical
upgrades, should be reported.

Company should be able to show how High Availability (HA) is achieved with their product or service. If the IAM product is deployed on‐prem, how many versions of the product 
M.7 Critical
must be deployed to achieve HA?

M.8 An on‐demand IAM company should perform white‐box and black‐box security assessments (by outside firms) at least once per year, and should be able to provide the results. Critical

M.9 An on‐demand IAM company should provide geographic redundancy in their datacenter infrastructures. Critical

M.10 The IAM company should be able to produce documented customer data segmentation architecture details. Critical

M.11 Company should be able to show a disaster recovery plan, one that has been stress tested and proven. Secondary

M.12  An on‐demand IAM company should be able to show how quickly they can add functionality or make modifications to the service, as needed, in response to customer requests. Secondary

M.13 Platform is FedRAMP Certified Critical

Adaptive Authentication

N.13 Support for geolocation as context for access policy Critical

N.14 Support for multiple location zones for access policy Secondary

N.15 Detect and use certificates for device trust. Support for 3rd party certificates distributed by an MDM, AD or SCCM. Secondary

Governance Requirements

O.1 Report that compares actual accounts in an app to system of record and determines if attributes have drifted in an application from the system of record. Secondary

O.2 Report that checks that users who should have been deprovisioned still exist in a downstream system or application. Secondary

Orchestration Requirements

P.1 App approval workflow enabling a user to request an app and a manager or app owner to approve, with an end‐user inbox to manage approval requests. Secondary

P.2 Support for attribute‐level mastering, for example, enabling user to be mastered in AD, but some user attributes mastered within cloud IAM service. Secondary

P.3 Rules for assigning users to groups and roles based on attributes or existing group memberships. Primary

API Access Management

P.1 Complete standard‐compliant support for OAuth 2.0 API Authorization Critical

P.2 Compatible with 3rd party API management solutions Critical

P.3 Supports modern application development (mobile or single page app with API backend) Critical

P.4 Supports app to app or server to server scenarios (service accounts) Critical

P.5 Flexible policies that define access based on user profile, groups, network, client, and consent Critical

P.6 Instant access revocation or updates to user permissions based on user profile and status Critical

P.7 Purpose‐built, user‐friendly console for consistent creation, maintenance, and audit of API access policies based on native identity objects without any custom code Critical

P.8 Advanced Oauth 2.0 suport with User Consent functionality Critical