SPECIAL NOTICE
D -- Enterprise Identity Management” (EIDM) system
- Notice Date
- 9/15/2015
- Notice Type
- Special Notice
- NAICS
- 541512
— Computer Systems Design Services
- Contracting Office
- Department of Health and Human Services, Centers for Medicare & Medicaid Services, Office of Acquisition and Grants Management, 7500 Security Blvd., C2-21-15, Baltimore, Maryland, 21244-1850
- ZIP Code
- 21244-1850
- Solicitation Number
- RFI-CMS-2016-00101
- Archive Date
- 11/14/2015
- Point of Contact
- David Fitton, Phone: 4107861492
- E-Mail Address
-
david.fitton@cms.hhs.gov
(david.fitton@cms.hhs.gov)
- Small Business Set-Aside
- N/A
- Description
- Solicitation Number: RFI-CMS-2016-00101 Notice Type: Special Notice Synopsis: Introduction I. Subject This is a Request for Information (RFI). This is NOT a solicitation for proposals, proposal abstracts, or quotations. The purpose of this RFI is to obtain knowledge and information for project planning purposes. This RFI is to assist the Centers for Medicare & Medicaid Services (CMS) in the identification of potential options and to obtain an Identity Management Solution or a set of solutions that are able to support Agency requirements. CMS is seeking potential solutions for creating enterprise-level common services for Identity Proofing, creation of an "assurance" level within a workflow process that can be as generic as a 2-tier approval process to a complex multi-tier process using a delegated chain of trust model, and the collection of necessary information for a replacement application (system) to assign role-based access privileges. The solution should provide services that comply with the National Institute of Standards and Technology (NIST) standards for assurance levels 1 - 4 as stated in Special Publication (SP) 800-63-3 or most current version. The solution requires knowledge-based Identity Proofing that is not dependent on the use of an individual's social security number. In addition, the solution requires functionality for multi-factor authentication using a variety of methods and techniques. CMS' Acceptable Risk Safeguards (ARS) and other security requirements can be found at the following link: https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library.html II. Background CMS is a Department of Health and Human Services (DHHS) Operating Division and is the Federal agency that administers the Medicare program and partners with the States to administer the Medicaid programs throughout the U.S. and Territories. CMS' mission is to ensure effective, up-to-date health care coverage and to promote quality healthcare for the covered people under its programs. Our nation's healthcare system is facing a major reform due to the enactment of the American Recovery and Reinvestment Act (ARRA), Health Information Technology for Economic and Clinical Health (HITECH), Medicare Access and CHIP Reauthorization Act of 2015 (MACRA), the Patient Protection and Affordable Care Act - also known as Affordable Care Act (ACA), and by the growing population of beneficiaries and insurance exchange applicants. The Centers for Medicare & Medicaid Services (CMS) has a mandate to assume a central role in ensuring the success of these healthcare reforms. The Health Insurance Marketplace, created as a result of ACA legislation, opened October 01, 2013. People without health insurance are now able to navigate to Healthcare.gov to review and compare plans and prices. The Centers for Medicare & Medicaid Services (CMS) operates a Federally-Facilitated Marketplace (FFM), which operates in states that have chosen not to build their own Marketplace. The FFM is the place where people without health care insurance can find information about health insurance options and also purchase health care insurance. Information can also be found regarding eligibility for help with paying premiums and reducing out-of-pocket costs. The Children's Health Insurance Program (CHIP) provides health coverage to eligible children, through both Medicaid and separate CHIP programs. CHIP is administered by states, according to federal requirements. The program is funded jointly by states and the federal government. CMS anticipates the Medicare, Medicaid, CHIP, and Health Insurance Exchange programs will have increasing business demands for enterprise services supporting requirements for individuals to interact with CMS via some type of online access. The approximate number of potential users of this system is 3 to 6 million individuals. There are approximately an additional 90 million Medicare and Medicaid beneficiaries; however, they are out of scope for the purposes of this RFI. Currently, CMS uses a Commercial off the Shelf (COTS) identity and access control system, which has been customized to support CMS' specialized requirements, called the "Enterprise Identity Management" (EIDM) system. CMS has identified a number of major issues with the current implementation, including limitations of the base COTS product for Identity Management (IDM) that EIDM is built upon, related to: a. Scalability - the system may not efficiently support the expected CMS user base or peak periods of new account registration or user log-in. b. Maintainability - Integration of new applications and the authorization functions can be a costly and lengthy process due to the coding efforts involved, and customized coding is too often required to ensure the system meets CMS' requirements. c. Reporting - The COTS reporting tool lacks operational reporting functionality, requires specialized skills, and does not provide sufficient reports Out Of The Box (OOTB) that are useful to CMS. d. The COTS product does not support Active - Active configuration between datacenters to allow active traffic routing and load balancing, as well as automated failover from one data center to the other if necessary. e. EIDM lacks agility, since it is difficult to introduce new functionality within the COTS product. f. The infrastructure/platform dependency of the COTS solution imposes limitations since it can only operate on specific hardware. g. The COTS product lacks the ability to operate efficiently in a virtual environment and requires physical hardware for optimal effectiveness. III. Assumptions It is recognized by CMS that a single solution or service may not meet all critical requirements and that an amalgam of integrated or connected solutions may be necessary to satisfy the requirements. COTS or Government off the Shelf (GOTS) alternatives should facilitate better Federal security compliance through controls and auditing, ease-of-use for CMS customers, simplified integration with internal systems (including CMS' Enterprise Portal) and external partners, lower maintenance and upgrade costs over the long-term, etc. CMS is supportive of well-established open source solutions that meet the criteria documented within CMS' Open Source Technical Reference Architecture (TRA). CMS is interested in a robust solution with the agility to introduce new functionality quickly. The solution should have the capability to operate and function optimally in a mixture of virtual and/or physical infrastructure environments, and to take advantage of commodity infrastructure and/or other flexible platforms. Responders should also include some industry "best practice" solution features that may not be expressly mentioned in this document. These will be considered "value added" features that are above and beyond our baseline expectations. The Solution must be fully compliant with federal regulations. All software deployed by CMS is subject to Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d) as amended by the workforce Investment Act of 1998 (P.L. 105-220). Specifically, subsection 508(a)(1) requires that when the Federal Government procures Electronic and Information Technology (EIT), the EIT must allow Federal employees and individuals of the public with disabilities comparable access to and use of information and data that is provided to Federal employees and individuals of the public without disabilities. Each Electronic and Information Technology (EIT) product or service furnished to CMS must comply with the Electronic and Information Technology Accessibility Standards (36 CFR 1194), which were developed by the Architectural and Transportation Barriers Compliance Board ("Access Board"). IV. Requirements Responders shall create a written response to this request for information that addresses each of the requirements set forth in this document. Please review the following requirements and describe how your IDM Solution will fulfill these requirements. A. User Provisioning and Authentication 1. Support for 3 to 6 million users (these numbers represent what is necessary for planning purposes to support normal operations). 2. Workflow driven user lifecycle management, including at a minimum: a. User provisioning. b. User de-provisioning. c. Provide users' with the ability to query status of the workflow process and escalate in case of delays. d. Rules based notifications for events such as user provisioning, user de-provisioning, changes in personal information or roles, etc. e. IDM system administration console/GUI to monitor workflow processes. Administrative console must provide access based on roles such as Help Desk personnel, supervisors, IDM system administrators, etc. Describe whether or not (and if so, how) the System Administration console supports user provisioning and de-provisioning. 3. Help Desk Graphical User Interface (GUI) providing specialized functions for multi-Tier Help Desk personnel (supporting both the IDM Help Desk and Application Help Desk personnel supporting applications integrated with the Identity Management System (IDMS)). Describe the functionality provided by the IDMS Help Desk GUI. 4. Support Self-service and Delegated Administration a. Provide user provisioning and de-provisioning through an IDM system administration console. b. Support Self Registration model for a user through a Web based interface. 5. Support the ability to temporarily suspend/de-activate a user's account, and re-activate an account. 6. Offer ability to perform bulk approvals, as well as provisioning and/or de-provisioning users, through IDM on-line and batch processes. 7. Perform integration and synchronization with existing external data repositories - X.500 Directory Services using Lightweight Directory Access Protocol (LDAP), Relational Database, Mainframe, and Active Directory. 8. Describe the data synchronization services provided and the mechanism by which data from external data sources/databases is accessed, processed, stored, and synchronized. 9. Describe the mechanism for provisioning across diverse environments and systems. 10. Describe the product's support for Federated Identity Management and Single Sign-on, including Single Sign-On (SSO) support for web and portal based applications, and the use of open-standards for exchanging authentication and authorization data between parties (such as SAML, OAuth, WS-Federation and others). 11. Describe support for Third-party or product-based ID Proofing: CMS is interested in capabilities in the areas of identity proofing and identity verification. 12. Describe support for product-based Multi-Factor Authentication and/or combination with Third-party multi-factor authentication services/solutions. 13. Describe support for configurations to support Spanish (or other) language/translation. 14. Describe the solution's capability to work with CMS' Personal Identify Verification (PIV) card issuance and authentication functions. 15. Describe the solution's capability to manage Federal Public Key Infrastructure (PKI), and other electronic/digital certificate management and processes, as part of user account management. 16. Provide a flow diagram that shows how the solution will meet the requirements specified in this RFI. B. Access Control 1. Provide self-service support for password management (password changes, forgotten password resets, etc.). 2. Support User profile management. 3. Ability to enforce multiple Password policies, based on the Community/line of business the user belongs to. 4. Ability for IDM Administrator and Help Desk operators to update user information. 5. Capable of issuance of two factor credentials out of the box or through integration with third party service providers. 6. Support for delegation of authority. 7. Ability to integrate with enterprise resources such as Unix/Linux servers, Windows Servers, Database Servers, Mainframe servers, and Directory Services using LDAP. 8. Flexibility to allow tokens, certificate-based authorizations, and challenge/response questions. 9. Support for Role Management and role-based access workflows. C. Auditing, Logging and Reporting 1. Support for audit trailing and logging of configurable key events. a. Ability to generate alerts and reports from configurable triggers based on configured events. b. Ability to access logs and view logged activity from a central point. 2. Provide rules based comprehensive reporting capabilities (i.e., quarterly reports for managers to review their employees' system access, reports that show who has access to what and who approved the access, reports for identifying orphaned accounts, reporting who accessed what and when, etc.). D. Miscellaneous Open-ended requirements asking for descriptions or lists are denoted by an asterisk (*). 1. The solution must be capable of managing complex registration, credentialing and authorization workflows including the collection of attributes used for approval routing, approval decisions and for retrieval by integrating applications. 2. *Describe how the solution will enforce common security policies and procedures and other federal standards, such as: a. Principles around anonymous access. b. Access rights based on least-privileged. c. Enforcement of data classification. d. Enforcement of password rules. e. Enforcement of account locking after a configurable number of invalid authentication attempts. g. Account Management: i. Enforce review of accounts for compliance with account management requirements within a configurable number of days, like 180 days. ii. Enforce annual certification of all accounts within a configurable number of days, like every 365 days.* 3. Capability to "scale up" to support surge processing related to the addition of new user types or additional application integrations, special enrollment or activity periods of applications integrated with the IDMS, etc. 4. Support flexible user certification model. CMS should be able to choose the frequency (monthly, quarterly, or annually) based upon the criticality of data. 5. Ease of configuration through well defined user interfaces. 6. *Describe the workflow that are part of the developed set of capabilities, how the workflows are developed, the level of difficulty and time involved in setting up workflows, and the level of difficulty in ongoing management and maintenance of the capability, including the necessary skill set(s) to sustain the capability*. 7. *Describe how support for CMS' Acceptable Risk Safeguards (ARS), Risk Management Handbook (including Volume III, Standard 4.3: Non-Standard Account Authenticator Management), and related standards, would be met*. 8. Describe any specialized hardware and/or software, in addition to but supporting the IDMS, recommended for optimum deployment of the IDMS to meet CMS' requirements. 9. Describe any known security weaknesses in the IDMS, the scenario(s) under which weaknesses would occur, and the short- and long-term remediation options/corrective action plan. 10. *Describe how an application would be integrated with the IDMS. Describe the integration of both a new application that is not integrated with an IDMS and an existing application already integrated with another CMS IDMS. For the existing CMS IDMS integration, include a description of how data would be migrated to the new IDMS. Describe the user base and workflows, as well as any tools or techniques that could be utilized - and whether these tools are part of the IDMS or would need to be acquired separately.* 11. Describe how the principle of Separation of Duties is enforced. For example, certain roles have different levels of trust than normal users. In particular, Administrators have a higher level of trust than normal users. Consequently, Administrators should not be users of the application. 12. Describe how the system will leverage Federation functionality and interoperate with other identity management systems/platforms/configurations in a federated fashion; include a description of if, and how, automatic "federated provisioning" is supported. 13. *Describe how the solution will work seamlessly with CMS' Enterprise Portal technology and Technical Reference Architecture, with CMS' 3-zone infrastructure, with users that utilize multiple applications integrated with the IDMS, and with applications that exist across multiple data centers.* 14. *Describe how the transition from the EIDM to the new IDMS would be achieved and managed. Include a description of how data would be migrated to the new IDMS. Describe any tools or techniques that could be utilized, and whether these tools are part of the IDMS or would need to be acquired separately. Describe the timeframe required to perform the migration; and identify the principal risks anticipated and how they would be mitigated.* 15. Service Oriented Architecture Enablement: Capability for the solution to operate within, and support, CMS' enterprise-wide Service Oriented Architecture (SOA) initiative. 16. Support for Web Services architectures, such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST) and others, to connect to a number on internal and external system resources and applications, including support for multiple markup languages such as eXtensible Markup Language (XML), JavaScript Object Notation (JSON), among others. 17. *Provide any additional information that you feel would be relevant to this RFI*. V. Disclaimer and Important Notes This notice does not obligate the Government to award a contract or otherwise pay for the information provided in response. The Government reserves the right to use information provided by respondents for any purpose deemed necessary and legally appropriate. Any organization responding to this notice should ensure that its response is complete and sufficiently detailed. Information provided will be used to assess tradeoffs and alternatives available for the potential requirement and may lead to the development of a solicitation. Respondents are advised that the Government is under no obligation to acknowledge receipt of the information received or provide feedback to respondents with respect to any information submitted. Any solicitation resulting from the analysis of information obtained will be announced to the public in Federal Business Opportunities (FedBizOps) in accordance with the FAR Part 5. However, responses to this notice will not be considered adequate responses to a solicitation. Confidentiality. No proprietary, classified, confidential, or sensitive information should be included in your response. The Government reserves the right to use any non-proprietary technical information in any resultant solicitation(s) VI. Information Requested Responders shall provide the following: 1. General Information a. Company name b. Address c. Point of contact d. Telephone number, fax number and email address e. Business size f. Corporate entity/structure (Limited Liability Company, Joint Venture, Partnership, Sole Proprietorship, etc.). Any teaming arrangements shall also include the above-cited information for each entity on the proposed team. 2. Specific Information The solution proposed shall be mature, well tested, and adopted by a wide variety of vertical markets such as government, state, healthcare, and financial. The examples provided shall be for implemented solutions that demonstrate the abilities described in this RFI. Describe how your existing solution addresses each requirement described in the sections above. Provide names, descriptions and contacts of entities, in either the Private or Public Sectors, of similar size to CMS for whom services described above were performed in the past five years. Please include the number of users supported and any/all teaming arrangements. Provide a list of data sources used, a metric indicating the percentage of the U.S. population for whom they can provide effective identity proofing/authentication services and information about existing users of their services in healthcare, government, or equivalent complex and large-scale environments. 3. CMS is also interested in receiving comments on the following points: a. Industry Best Practices. • Potential challenges of the above stated requirements. • Industry best practices or lessons learned on projects of similar complexity and magnitude. b. Risk Management. • Potential major risk factors in performing services stated above. • Effective risk mitigation techniques. c. Performance Measures. • Key performance indicators. • Appropriate performance metric and measurements. d. Describe how the system will achieve CMS' goal of 99.999% system availability measured by system uptime exclusive of planned downtime (releases, upgrades) and unplanned downtime due to external factors. VII. Submission Requirements Submissions shall be no more than 25 pages, excluding cover sheet, title page and table of contents, single spaced, 8.5 x 11 paper, 1 inch margin, and no smaller than 12 point type. Responses to this RFI are due on Friday October 30, 2015 by 3:00 PM eastern standard time. Responders must submit an electronic copy, in Microsoft Word 2010 format, which must be emailed to: David.Fitton@cms.hhs.gov with the Subject line: RFI-CMS-2016-00101 Appendix A: Acronyms Acronym Definitions: ACA - Affordable Care Act ARS - Acceptable Risk Safeguards CHIP - Children Health Insurance Program CMMI - Capability Maturity Model Integration CMS - Centers for Medicare and Medicaid Services COTS - Commercial Off the Shelf DHHS - Department of Health and Human Services FAR - Federal Acquisition Regulations FedBizOps - Federal Business Opportunities FFM - Federally Facilitated Marketplace FIPS - Federal Information Processing Standards GOTS - Government Off the Shelf GSA - General Services Administration GWACS - Government Wide Acquisition Contracts HITECH - Health Information Technology for Economic and Clinical Health IDM - Identity Management IDMS - Identity Management System ISO - International Organization for Standardization LDAP - Lightweight Directory Access Protocol MACRA - Medicare Access and CHIP Reauthorization Act NIST - National Institute of Science and Technology PKI - Public Key Infrastructure PIV - Personal Identity Verification RBAC - Role Based Access Control RFI - Request for Information SAML - Security Assertion Markup Language SOA - Service Oriented Architecture SP - Special Publication TRA - Technical Reference Architecture Primary Point of Contact Information: David Fitton, Contract Specialist David.Fitton@cms.hhs.gov Phone: 410-786-1492
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/HHS/HCFA/AGG/RFI-CMS-2016-00101/listing.html)
- Place of Performance
- Address: CMS Headquarters, 7500 Security Blvd, Baltimore, Maryland, 21244, United States
- Zip Code: 21244
- Zip Code: 21244
- Record
- SN03888017-W 20150917/150916001333-7bed88bb026828202dc6f24f38fbfc23 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |