2024-0156 Identity Management Solution Interoperability Tools

Deadline Date: Tuesday 27 August 2024

Requirement: Identity Management Solution - Interoperability Tools

Location: The Hague, NL

Full Time On-Site: See Section 8 PRACTICAL ARRANGEMENTS

Period of Performance: 2024 BASE: Contract period should not start later than 1 October 2024 until 31 December 2024.

Extensions possible as follows:

2025 Option: 1st January 2025 until 30th April 2025

2025 Cycle 2 (January)

2025 Cycle 3 (February)

2025 Cycle 4 (March)

2025 Cycle 5 (April)

Required Security Clearance: NATO SECRET

1. Bidding Instructions

1.1. Technical Proposal

Bidders shall submit a proposal clearly providing the following information:

a. Submission of a document containing the proposed approach to address the first cycle of work as described in Part 2, section 2 (ie: a proposed work plan for the first month).

b. An evidence of successfully delivering one to three identify provider (IDP) system (or similar) within the last five years. Each evidence should demonstrate proof of performance and be comparable in size and scope to the requirements of this role. Additionally, ensure to include a detailed case study that highlight the Purpose, Objective, Output and Outcome (PO3) mentioned in the table (Annex A). Evidence should display the ability to manage and deliver Identify Provider (IDP) systems by following customer requirements.

c. CVs of the assigned resource(s) for the project.

2. Award

Contract shall be awarded under the future AAS Framework Contract – CO- 115786 –AAS+ Market Place 1.

1 INTRODUCTION

a. The NATO Information and Communication Agency (NCI Agency) located in The Hague, The Netherlands, is the Interoperability Assurance Authority for NATO. In the light of this responsibility, the Interoperability branch of the Chief Quality Office is looking for an Identity Management Solution to support the set of tools that are part of the Interoperability (IO) Toolset.

b. More specifically, the work will be to deliver an Identity Provider (IDP) system that can integrate with the set of tools that are part of the IO Toolset and fulfil the requirements specified in the scope of work

2 SCOPE OF WORK

a. Under the direction of the NCI Agency Chief Quality Office, the Interoperability Branch requires various aspect of identity management in order to complete their work.

b. The contractor will be part of a team (technical lead, Service Delivery manager, interoperability engineers and software engineers) and will work using monthly cycles. Each cycle is planned and reviewed monthly. The content and scope of each cycle will be agreed with the Services Delivery Manager and the technical lead during the planning meetings.

c. The 1st cycle will be used for the contractor to deliver a system architecture, high-level design documentation and the evaluation results of the identity management product to be used as the core product.

2.1 Deliverable Definition To be Followed

2.1.1 Functional Requirements

a. User Management

i. The system must support user registration, login, logout, and profile management.

ii. The system must include password recovery and reset functionality.

iii. The system must support multi-factor authentication (MFA).

iv. The system must support user self-service features, such as profile updates and password changes.

b. Roles and Permissions Management

i. The system must support role-based access control (RBAC), policy-based access control (PBAC), and attribute-based access control (ABAC).

Role-Based Access Control (RBAC): Access decisions are based on the roles assigned to users within NATO. Roles are created for various functions, and permissions are assigned to these roles. Users are then assigned to roles, simplifying management and assignment of permissions.

Policy-Based Access Control (PBAC): Access decisions are governed by policies defined by NATO. These policies dictate what actions are allowed or denied based on a variety of conditions, which can include user roles, attributes, and other contextual information.

Attribute-Based Access Control (ABAC): Access decisions are based on attributes associated with users, resources, and the environment. These attributes can include user roles, user identity, resource types, and environmental conditions such as time of day or location.

ii. The system must enable administrators to define and manage roles, policies and attributes.

iii. The system must allow administrators to assign and revoke roles to/from users.

iv. The system must enable administrators to define and manage permissions.

v. The system must support granular permissions at resource and action levels.

vi. The system must support custom roles and permissions based on organizational needs.

vii. The system should support delegation of basic user administration permission to 2nd level administrators.

c. Tenancy Management

i. The system should support multi-tenancy.

ii. The system should allow for the creation, management, and deletion of tenants.

iii. The system should support isolation of data and resources between tenants.

iv. The system should allow tenant administrators to manage users, roles, and permissions within their respective tenants.

v. The system should support customizable branding for different tenants.

d. Auditing and Reporting

i. The system must log all user activities, including login, logout, and administrative actions.

ii. The system must provide audit trails and reports for user activities and security events.

e. API and Integration

i. The system must provide RESTful APIs for user, role, permission, and tenant management.

ii. The system must support integration with third-party applications and services.

iii. The system must support Single Sign-On (SSO) capabilities.

iv. The system must support integration with existing identity providers (e.g., Active Directory, LDAP).

v. The system should provide SDKs and client libraries for various programming languages.

f. OAuth2 and OpenID Connect

i. The system must support OAuth2 for authorization.

ii. The system must support OpenID Connect for authentication.

iii. The system must provide endpoints for authorization and token issuance

iv. The system must support standard OAuth2 and OpenID Connect flows, including authorization code, implicit, password, client credentials, and refresh tokens.

2.1.2 Non-Functional Requirements

a. Performance

i. The system must handle up to 1,000 concurrent users.

ii. The system must on average respond to user actions within 300 milliseconds under maximum load.

b. Security

i. The system must comply with:

1) NATO Technical and Implementation Directive on CIS Security, AC/322-D/0048-REV3

2) NATO CIS Security Technical and Implementation Directive for the Security of Web Applications, AC/322-D(2019)0038 (INV) with an Enhanced security level

ii. The system should support security features such as IP whitelisting, IP blacklisting, and rate limiting.

iii. The system should support geographical whitelisting and blacklisting of users

iv. The system should support user email domain name whitelisting and blacklisting

c. Usability

i. The system must provide a user-friendly web interface for administrators and end-users.

ii. The system must have a customizable user interface.

d. Availability and Reliability

i. The system must be able to be configured with 99% uptime.

ii. The system must support backup, restore, disaster recovery and failover mechanisms.

2.2 Design Considerations

2.2.1 Financial

a. The system should be based on an existing well maintained, security tested and proven core product with minimal licensing costs. The use of any product with licensing costs must be agreed to by NCIA prior to starting any implementation.

2.2.2 Extensibility

a. The system must be designed to allow for future enhancements and integrations with minimal changes.

2.2.3 Maintainability

a. The system should be based on an existing well maintained, security tested and proven core  product

b. Any customizations must be well-documented

c. Any customizations must not prevent upgrading of the core product

d. The system must support automated deployment and Infrastructure as Code principles

e. The system must support automated testing and continuous integration/continuous deployment (CI/CD) practices.

2.3 Security Requirements

2.3.1 Authentication

a. The system must support various authentication methods, including username/password, MFA, and OAuth.

b. The system must support adaptive authentication based on risk assessment.

2.3.2 Authorization

a. The system must enforce role-based, policy-based, and attribute-based access control for all resources.

b. The system must support fine-grained authorization policies.

2.4 Product Deliverables

2.4.1 Documentation

a. System architecture and design documentation.

b. API documentation.

c. User and administrator guides.

2.4.2 Source Code

a. Complete source code with appropriate documentation and comments for any customizations created

b. The contractor(s) will make use of the NCIA managed code repositories on Azure DevOps (i.e. NATO Software Factory)

2.4.3 Deployment

a. Automatic PowerShell based deployment scripts and configuration files.

b. Instructions for setting up development, testing, and production environments

c. Testing instance(s) for use by the Interoperability Toolset teams during their development work

2.4.5 Testing

a. Integration tests to ensure different components work together.

b. System tests to validate the end-to-end functionality of the system.

2.5 Acceptance Criteria

a. The system meets all functional and non-functional requirements.

b. The system passes all unit tests, integration tests, and system tests.

c. The system passes all security audits including a NCIA Penetration test

d. The system is successfully deployed in the production environment.

3 DELIVERABLES AND PAYMENT MILETONES

3.1 2024 deliverables from the work on this statement of work.

a. 2024 01 October 2024 to 31 December 2024:

Deliverable 01: Identity Management Solution Cycles

Quantity: 3

Payment Milestones: After each cycle completion

Estimated Start Date: October 2024

End Date: NLT 31 December 2024

Each cycle is planned for a duration of one month. At the end of each cycle, a detailed report of the activities conducted must be submitted using a Delivery Acceptance Sheet (Annex B). Upon review, if deliverables and activities follow what is included in this SoW and the monthly cycle meetings, payment will be authorized.

The NCIA team reserves the possibility to exercise a number of options, based on the same deliverable timeframe and cost, at a later time, depending on the project/ service priorities and requirements.

The payment shall be dependent upon successful acceptance of the Delivery Acceptance Sheet (DAS) – (Annex B) including the EBA Receipt number.

Invoices shall be accompanied with a Delivery Acceptance Sheet (Annex B) signed by the Contractor and the project authority.

3.2 For 2025, additional cycles may be requested under the same scope, conditions and  constraints.

a. 2025 OPTION: 01 January 2025 to 30 April 2025:

Deliverable 01: Identity Management Solution Cycles

Quantity: 4

Payment Milestones: After each cycle completion

Estimated Start Date: January 2025

End Date: NLT 30 April 2025

Each cycle is planned for a duration of one month. At the end of each cycle, a detailed report of the activities conducted must be submitted using a Delivery Acceptance Sheet (Annex B). Upon review, if deliverables and activities follow what is included in this SoW and the monthly cycle meetings, payment will be authorized.

The NCIA team reserves the possibility to exercise a number of options, based on the same deliverable timeframe and cost, at a later time, depending on the project/ service priorities and requirements.

The payment shall be dependent upon successful acceptance of the Delivery Acceptance Sheet (DAS) – (Annex B) including the EBA Receipt number.

Invoices shall be accompanied with a Delivery Acceptance Sheet (Annex B) signed by the Contractor and the project authority.

4 COORDINATION AND REPORTING

4.1 The contractor shall participate in daily and weekly status update meetings, cycle planning and other meetings, remote or in person, according to Services manager’s instructions.

4.2 For each cycle to be considered as complete and payable:

a. The contractor must report the progress of his/her work and any impediments during the cycle weekly meetings;

b. The contractor should report verbally the work completed during the cycle review;

c. The contractor should send within three (3) days after the cycle’s end date a written report. The format of this report shall be a short email to the Service manager with the cycle Delivery Acceptance Sheet (DAS) (Annex B) mentioning briefly the work held and the achievements during the cycle. The DAS need to be signed by both parties and further submitted with the invoice by the company to NCI Agency Accounts Payable.

d. If there is more than one contractor working on this project, only one report is required on behalf of the contracting company.

5 SCHEDULE

5.1. This statement of Work will be active immediately after signing of the contract by both  parties.

5.2. Period of performance:

a. The BASE period of performance is as soon as possible but not later than 1 October 2024 and will end no later than 31st December 2024.

b. If the 2025 option is exercised, the period of performance is 01 st January 2025 to 30 th April 2025.

6 SECURITY

6.1 The security classification of the work will be up to NATO Secret.

6.2 All individuals working on this arrangement must hold a valid NATO security clearance to a minimum level of NATO SECRET.

6.3 It is the responsibility of the contracting company to obtain and maintain the security accreditation of all individuals working on this arrangement

7 CONSTRAINTS

7.1 All the documentation provided under this statement of work will be based on NCI Agency templates or agreed with project point of contact.

7.2 All documentation and deliverables will be stored under the respective NCI Agency configuration management and/or in the provided NCI Agency tools and remain the property of NCI Agency.

8 PRACTICAL ARRANGEMENTS

8.1 The contractor will work under NCI Agency AAS Framework contract (CO-115786-AAS+) for the NCI Agency in The Hague, the Netherlands.

8.2 This work can be accomplished by ONE contractor or A TEAM of contractors for the duration of the agreement. Each contractor or individuals working on this agreement must hold a valid NATO security clearance at the SECRET level.

8.3 The work location can be on location or remote:

a. On location: The contractor(s) is required to work on location at NCI Agency The Hague campus, Oude Waalsdorperweg 61, 2597 AK The Hague, Netherlands. Location accessible Monday to Friday 8:30 to 17:00, close on Agency Holidays. Parking available

b. Remote: The contractor(s) must work within a NATO country and be available during Monday to Friday 8:30 to 17:00 (Central European Time) and be present for 2 days per month for coordination meetings at The Hague Campus (Oude Waalsdorperweg 61, 2597 AK The Hague, Netherlands). The cost and arrangement of travel will be the responsibility of the contractor(s).

8.4 The contracting company will be provided with one (1) NCI Agency issued laptop and user account for access to the NATO Software Factory (Azure DevOps) to be provided to the contractor(s). This equipment is the property of NCI Agency and must be return upon termination of the contract. If the equipment is required to be shipped to a location, it will be at the expense of the expeditor.

8.5 The contractor may be required to travel to other sites within NATO for completing these tasks. Travel arrangements will be the responsibility of the contractor and the expenses will be reimbursed in accordance with Article 5.5 of AAS Framework Contract and within the limits of the NCIA Travel Directive. Reimbursements for travel to the Duty location for remote working arrangement are not covered as indicated in section 8.3.2.

8.6 Short periods of absence are acceptable as long as deliverables within the established targets are completed. Planned and unplanned absences must be communicated to the service delivery manager.

9 QUALIFICATIONS for Proposed Resources

{See Requirements]

[See Workable to view Annex A and Annex B]

Requirements

6 SECURITY

• All individuals working on this arrangement must hold a valid NATO security clearance to a minimum level of NATO SECRET.

9 QUALIFICATIONS for Proposed Resources

9.1 Required Qualifications and Training/Education:

The consultancy support for this work requires a team member with the following qualifications:

• More than 3 years experience with the implementation of Identity Management solutions
• More than 3 years excellent working knowledge of :Identity and Access Management; OAuth, OpenID, MFARBAC, PBAC and ABAC
• More than 3 years strong working knowledge of: Software Development, .NET and/or Java Based
• Ability to communicate written and orally with Clarity, Coherence, Conciseness, and Engagement
• Demonstrable ability to work autonomously and proactively and to follow internal processes

9.2 Relevant soft skills / competencies:

• Very good communication skills, both spoken and written, in English.
• Ability to develop and maintain clear and concise technical documentation, including procedures
• Team player, always willing to help others and to share knowledge.
• Good collaboration skills, with the ability to work in a multinational and diverse team
• Growth mind set, always wanting to improve and to learn