TOR, CTBTO SSO Implementation



Terms of Reference

Implementation of Identity Management and Single-Sign-On for the CTBTO

Table of Contents

1. INTRODUCTION 5

2. BACKGROUND 6

2.1 User and Identity Management 6

2.2 Single Sign On. 6

2.3 Existing Prototype 6

2.4 Definitions and acronyms 7

2.5 References 9

3. CURRENT ENVIRONMENT 10

3.1 PTS User Community 10

3.1.1. Internal Users 10

3.1.2. External Users 10

3.2 Major User Repositories and Directories used by the Commission 10

3.2.1. UNIX/Linux LDAP Server 10

3.2.2. Microsoft Active Directory 10

3.2.3. Check Point Firewall 10

3.2.4. IMIS (UN ERP) 10

3.2.5. ECS Open LDAP Server 10

3.2.6. VIC Internal LDAP Server 10

3.3 Application Portfolio 11

3.3.1. Internal Applications 11

3.3.2. Externally Accessible Applications 11

3.4 Access Methods, SSO and Integration Approach 11

3.4.1. Web Access 11

3.4.2. VPN Access: 11

3.4.3. Direct SSH Access: 12

3.4.4. Proposed Interfaces and Interconnects 12

4. SCOPE 14

4.1 Phase 1 14

4.2 Overview of Extent of SSO Coverage in Phase 1 14

4.2.1. Authorization, Authentication 14

4.2.2. Web Single Sign-On 14

4.2.3. Role Management 14

4.2.4. Policy-based Identity Management 15

4.3 Phase 2 15

5. SOFTWARE REQUIREMENT 16

5.1 Clarifications: 16

5.2 Oracle Identity Manager System Requirements 16

5.2.1. Account Profiles: 16

5.2.2. Passwords 17

5.2.3. Challenge Q&A 17

5.2.4. Proxy 17

5.2.5. Resource Assignment and Revocation with related Administration and Workflows 17

5.2.6. User Administration; Groups and Organizational Units and Roles 18

5.2.7. Access Policies 18

5.2.8. Import, Export Tasks and Scheduling 18

5.2.9. User Request and Self-Service 18

5.2.10. Audit and Reporting 18

5.2.11. User Provisioning and Reconciliation including associated Interfaces 18

5.2.12. System Monitoring 19

5.3 Implementation Phases for Identity Management 19

5.3.1. Phase 1 19

5.3.2. Phase 2 19

5.4 Oracle Access Manager System Requirements 20

5.4.1. Identity System and Administration 20

5.4.2. Initial Login and Integration with Liferay Portal 20

5.4.3. Authentication Services, Automatic Expiration/De-Provisioning 20

5.4.4. Auto Revoke after X Attempts. 21

5.4.5. Clear text Passwords 21

5.4.6. Single Revoke/Resume for All Platforms. 21

5.4.7. SSO Encryption 21

5.4.8. Password Expiration 21

5.4.9. Authorization Services, Policies and Policy Management 21

5.4.10. Ability to Enforce Global Security Rules 21

5.4.11. Single Point of Authorization 22

5.4.12. Auditing Services 22

5.4.13. Personalization Services 22

5.4.14. Single-Sign-On and Persistence of User Sessions 22

5.4.15. Delegated Access Administration 23

5.4.16. System Monitoring 23

5.4.17. WebGate and Reverse Proxies 23

5.5 Implementation Phases for OAM 23

5.5.1. Phase 1 23

5.5.2. Phase 2 23

5.6 Oracle Virtual Directory 23

6. IMPLEMENTATION 24

6.1 DUTIES AND RESPONSIBILITIES OF THE CONTRACTOR 24

6.1.1. Preamble 24

6.1.2. Acquisition of Hardware 24

6.1.3. Acquisition of Software 24

6.1.4. Installation and Configuration 25

6.1.5. Software Maintenance 25

6.1.6. Support Services 25

6.1.7. Optional Extension 25

6.2 DUTIES AND RESPONSIBILITIES OF THE COMMISSION 26

6.3 REQUIRED RESOURCES 26

6.3.1. General Requirements for the Contractor 26

6.3.2. Requirements for Contractor’s Personnel 27

6.4 DELIVERABLES 27

6.4.1. Phase 1 27

6.4.2. Phase 2 28

Sample Mapping for PTS Users to OID In-Built Schema 30

Sample Workflow: 34

INTRODUCTION

The Preparatory Commission for the Comprehensive Nuclear-Test-Ban Treaty Organization (hereinafter referred to as the “Commission”) is the international organization setting up the global verification system foreseen under the Comprehensive Nuclear-Test-Ban Treaty (hereinafter referred to as the “CTBT”), which is the Treaty banning any nuclear weapon test explosion or any other nuclear explosion. The Treaty provides for a global verification regime, including a network of 321 stations worldwide, a communications system, an International Data Centre and on-site inspections to monitor compliance.

The Headquarters of the Preparatory Commission is in Vienna (Vienna International Centre of United Nations) Austria.

One fundamental task of the Commission’s International Data Centre is to provide States Parties with equal, open, timely and convenient access to agreed products and services to support their national CTBT verification requirements. Member States of the Commission have a large user community which uses the services and products offered by the Commission on a daily basis.

The purpose of this document is to define the approach and requirements for implementing Identity Management and Single Sign On for the Commission’s user base and to request for proposals with respect to the:

System design and implementation of Identity Management and Single Sign On for the Commission’s user base using the Oracle Identity Management Suite of Applications.

BACKGROUND

User and Identity Management

User information is currently managed on a per “application” basis within the PTS. This approach is ineffective, error prone and unsustainable in the long term. The major problem concerns how to deal with user information in a consistent and efficient way whenever it is required by any application or by any of the services provided by PTS. The primary approach to address the problem is to aggregate the storage and management of user credentials across the organization.

A common user management system must provide at a minimum the possibility to integrate existing repositories like Windows AD, LDAP based directories and other proprietary directories.

Single Sign On.

The Commission has been mandated by its Policy Making Organs to provide a common entry point and single user credentials for external stakeholders access to the Commission’s IT Services. This requires an integrated user account allocation scheme across PTS Divisions. Most of the services in question are web applications which are traditional targets of web-based single sign on solutions. Other categories of PTS services such as VPN connections and other non web based services may not be easily incorporated into such a single sign on deployment. However the user credentials including login information stored in an Identity Management repository can be shared across all systems.

Existing Prototype

The Identity Management and Single Sign On project is a PTS-wide project involving all users and applications from all Divisions of the Commission.

After prior evaluations and pilot phases involving different tools and platforms, the Commission has selected its prototype installation of the Identity Management Suite from Oracle which consists of the following application modules:

Oracle Identity Manager (OIM)

Oracle Access Manager (OAM)

Oracle Virtual Directory[1] (OVD)

Oracle Identity Federation (OIF)

as its SSO platform.

Currently the Commission uses the Sun Directory Server in its UNIX LAN therefore this was selected as the underlying LDAP Directory for the prototype.

The current prototype implementation incorporates all internal users (about 300) and most external users (about 2000).

The Commission seeks to implement the full application suite in a robust, high-availability, production and test/development environment to cover its entire user base.

Definitions and acronyms

|Acronym or Abbreviation |Definition |

|ACS-Server |Cisco Secure Access Control Server (ACS) is an access policy control platform used for CISCO device |

| |administration, VPN, Wireless and Network Admission Control etc. |

|API |Application Programming Interface |

|CA |Certificate Authority |

|CMS |Content Management Systems |

|COMMISSION |The Preparatory Commission for the Comprehensive Nuclear-Test-Ban Treaty Organization |

|CRL |Certificate Revocation List |

|CTBT |Comprehensive Nuclear-Test-Ban Treaty |

|DMZ |De-Militarized Zone |

|DOTS |Database of the Technical Secretariat: Actually a Java EE Web Application used within the Commission to manage|

| |Station and Equipment Inventory, Configuration, Points of Contact and State Parties Information |

|DSU |Division, Section, Unit |

|ECS |Expert Communication System, a web application used for information exchange with the Commission's |

| |stakeholders from Member States |

|EJBs |Enterprise Java Beans |

|GERONIMO |Refers to the J2EE server project of the Apache Software Foundation. Geronimo 2.1.4 is deployed on the |

| |Commission's Web Infrastructure. |

|GTA |General Temporary Assistant |

|IMIS |Integrated Management Information System (UN owned system used across the PTS for Financial transactions and |

| |Human Resources Management) |

|IRS |IMS Reporting System |

|KPI |Key Performance Indicators |

|LDAP |Lightweight Directory Access Protocol |

|NDC |National Data Centre |

|OAS |Oracle Application Server |

|OAM |Oracle Access Manager |

|OC4J |Oracle Containers for J2EE (OC4J) is the J2EE runtime component of Oracle Application Server. |

|OIM |Oracle Identity Manager |

|PIM |Policy-based Identity Management |

|PKCS |Public Key Cryptography Standards |

|PKCS#12 |Personal Information Exchange Syntax Standard of the PKCS of RSA. It defines a file format commonly used to |

| |store private keys with accompanying public key certificates, protected with a password-based symmetric key. |

|PKI |Public Key Infrastructure |

|PMI |Privilege Management Infrastructure |

|PMO |Policy Making Organs |

|POC |Point of Contact |

|Procsys |Procurement System of the Commission |

|PTS |Provisional Technical Secretariat of the Commission |

|RSA |RSA is an algorithm for public-key cryptography, Also refers to the company RSA Security, makers of SecurID |

| |OTP tokens. It is now a division of EMC corporation. |

|SAML |Security Assertion Mark-up Language |

|SecurID |OTP token from RSA (now EMC) Corporation |

|SNMP |Simple Network Management Protocol |

|SSL |Secure Socket Layer |

|SSO |Single Sign-On |

|UML |Unified Modelling Language |

|VPN |Virtual Private Network |

|WBS |Work Breakdown Structure |

|WebGate |A WebGate is a component of OAM, an Access Client for HTTP-based resources. A WebGate is an NSAPI or ISAPI |

| |plug-in that intercepts HTTP requests for Web resources and forwards them to the Access Server. |

|WebPass |This component is a plug-in that is placed on the Web server to shuttle information back and forth between the|

| |Web server and the Identity Server |

|Windows AD |Windows Active Directory |

|X.509 |X.509 is an ITU-T standard for a PKI for SSO and PMI. X.509 specifies, amongst other things, standard formats |

| |for public key certificates, certificate revocation lists, attribute certificates, and a certification path |

| |validation algorithm |

References

CTBTO Software Development and Documentation Guidelines

()

Oracle Identity Management Suite

()

CURRENT ENVIRONMENT

PTS User Community

Internal Users

About 300 users are registered as internal users. They have access to the Windows network (PCs, and Windows servers) and the UNIX network (workstations and servers).

External Users

More than 1500 users are registered for various externally accessible applications. These users have access to PTS applications like the IDC Secure Web-Site, the Experts Communication System, or the External DOTS deployment.

Some of the external users also have a VPN access to interact remotely with some PTS Services.

Major User Repositories and Directories used by the Commission

UNIX/Linux LDAP Server

For UNIX and Linux users, the user data is stored in redundantly-configured LDAP servers from Sun Microsystems.

Microsoft Active Directory

All internal users have accounts in the Windows Active Directory, which is deployed in a Microsoft cluster environment providing high availability.

Check Point Firewall

Some user records are directly managed in the Commission’s Check Point Firewall software.

IMIS (UN ERP)

This system is the initial repository for all staff records. The application uses a Sybase Adaptive Server Database.

ECS Open LDAP Server

For the Experts Communication System, user authentication relies on an Open LDAP server instance for user records. User authorization (based on a simple role-based authorization system) is handled through data stored in an Oracle database.

VIC Internal LDAP Server

To facilitate the exchange of contact data within the Vienna-based organizations, a LDAP server is maintained which contains only contact information for staff members. Neither authorization nor authentication is handled by this server.

Application Portfolio

Internal Applications

Many applications are only accessible from within the PTS. These include DOTS, ATLAS, Procsys, the Intranet, IMIS, and Helpdesk Expert. Some of them are integrated with standard LDAP directories, while others provide their own user data management.

Externally Accessible Applications

The list of externally accessible applications includes the IDC Secure Web-Site, Experts Communication System (ECS), External DOTS, IRS (both Web and E-mail), and the KPI website. Some internal applications are also externally accessible through VPN connection.

Access Methods, SSO and Integration Approach

Web Access

Most of the externally accessible applications are web-based. If supported, the integration would be via a WebGate instance of the respective Web Server for these groups of application.

If the application is not “user-aware” then the OAM WebGate deployed with Apache HTTP Proxy would suffice as sentry to provide single sign-on integration. An example for this type of system is the current IDC Secure Web Site running on kuredu.idc..

If the application has a user database and the source code is available to the PTS, then the login mechanism can be modified to integrate with the single-sign-on tool. An example of this category of systems is the ECS and the DOTS External Access.

For other applications where the PTS has no access to the source, there are various scenarios:

The application supports LDAP Directory or a user database but has proprietary login mechanisms without a programmable API: In this case, the Identity Manager can provision such users’ databases and directories. The user credentials will be the same as in the SSO solution but the user may need to log in again. Examples are the current OSI and INGE web sites.

The application does not support LDAP Directory but has an import mechanism or an accessible user list and has proprietary login mechanisms with programmable API: In this case, the Identity Manager can provision such users’ databases and lists. The user credentials will be the same as in the SSO solution and a native adapter for OAM may be built or the user may need to log in again. Applications in this category include the Cisco VPN service.

VPN Access:

The CISCO VPN Concentrator verifies user credentials using the CISCO ACS-Server (Radius) integration point with the RSA ACE Server which is currently used in the PTS to provide strong authentication in the form of one-time passwords. The OAM has integration tools to work with SecurID from RSA as referenced below:

()

This integration will be implemented in Phase1 of the project.

Direct SSH Access:

Some PTS users have remote access to database resources in the DMZ through direct SSH login via IP Addresses that are known and permitted by the PTS Check Point firewall To incorporate these users in the Identity management and Single Sign On scheme, Key pairs which are associated with their Identity records in OIM will be issued. A long term goal of the Commission’s PKI project is to serve as the CA for issuing the certificates. Therefore it is anticipated that connections from remote users would be using applications that are compatible with industry-standard X509 V3 certificates.

Proposed Interfaces and Interconnects

a. Components of the Identity Management deployment

[pic]

The diagram above shows the main components of the Identity Management system, sources of user records and provisioning requirements.

Oracle Authentication Services shall be configured for the following Operating Systems:

• Windows (based on Active Directory Integration)

• RHEL (based on Sun LDAP Integration

b. Components of the Access Management deployment

[pic]

c. Other Considerations: PTS Network and need for Directory Replication Services

There is an internal network LAN, a GCI LAN and a DMZ containing the web infrastructure VLANs. SSO services will be deployed such that Authentication and Authorization services for external users, who access services located in the DMZ, will not need to go through the firewall or the internal LAN. It may be necessary to have separate Identity realms for the different groups; therefore the Contractor must propose a workable architecture whereby these needs are taken into consideration.

SCOPE

The project will be implemented in two phases:

Phase 1

This phase will serve:

• Fine-tuning of the requirements for the project

• Finalization of the deployment’s design detailing all necessary hardware and software platform

• Establishment of hardware infrastructure and installation of base operating system (Out of the scope of this proposal)

• Installation and initial configuration of OIM with user imports

• Schema definition, implementation and initial configuration of selected LDAP Directories (to be provisioned by OIM)

• Implementation and initial configuration of OAM

• Integration of selected Web applications (ECS and IDC Secure Web Site) with Access Manager

• Testing

• Roll Out of Phase1 (This is foreseen to be in place by September 2009)

Overview of Extent of SSO Coverage in Phase 1

Authorization, Authentication

The implementation will handle user Authentication as well as the Authorization to use a specific backend application. However, backend application’s specific roles and internal rights management are out of the scope in Phase1.

Web Single Sign-On

The implementation will enable single sign-on for web-based applications. In the first phase, SSO will be implemented only for a few selected web applications commonly accessed by external stakeholders. Other applications (e.g. VPN access and command-line tools) are out of the scope of Phase 1.

Role Management

The system will implement a role-based management model only to the extent necessary for identifying users and the applications to which they have been granted access.

Policy-based Identity Management

The system will enable the enforcement of policies on user provisioning, automatic de-activation, de-provisioning, and self-service.

Phase 2

This phase will serve to:

• Finalize the deployment of all necessary components such that all identified systems and network environments can be covered.

• Integrate internal users in Active Directory and implement SSO on Windows PC

• Provision internal UNIX and Windows users

• Protect additional Web Applications with OAM

SOFTWARE REQUIREMENT

Clarifications:

In the requirement statements below, references to the features and functionalities that the system must support refer only to capabilities that must exist in the application suite upon installation. It may be necessary to apply further configuration to fully implement these features but this is not necessarily within the scope of this project and current implementation.

E.g.: “The system shall/must support the ability to automatically import entire user records or parts thereof from one or more defined sources at preset intervals.”

On the other hand, references to the features and functionalities that the implementation must support refer to capabilities that must be configured and fully implemented in the scope of the present project.

E.g.: “The implementation shall/must support the creation and customization of automated workflows (Request and approval chains) for the creation of user resources and for resource assignments to users.”

Oracle Identity Manager System Requirements

Account Profiles:

The implementation must have an account profile for each user with the following attributes:

|Attribute |Constraint |

|User Name: Can be alphanumerical; must be unique for any given user. |Not Null |

|User Password | |

|IMIS Number | |

|First Name: |Not Null |

|Middle Name: | |

|Last Name (To be replaced by First name If nonexistent) |Not Null |

|Date of user record creation: |Not Null |

|Foreseen Expiration Date of user account: |Not Null |

|Organization :(Org. Unit for Internal Users and Country for External Users) |Not Null |

|Nationality | |

|Email | |

|User Type: Internal External, Consultant |Not Null |

|Source Application: (should ideally reference known resource) | |

|User Status; (Active, Inactive) |Not Null |

|Supervisor: | |

|Group Membership (details to be defined) | |

Other attributes mandated by the system may be added as required. A sample mapping scheme to implement the above for OID can be found in Annex1.

Passwords

Self Service Password Management: The implementation shall support a user-friendly self service password generation and management in the web GUI.

The implementation shall support the ability for users to reset user password.

The implementation shall support the ability to manage and enforce password expiration policies and automated warnings for expiring passwords and accounts.

Challenge Q&A

The implementation shall support customizable and user-friendly challenge question and answers scheme to help users who have lost their passwords. The implementation of this functionality must support email.

Proxy

Delegated Administration: The implementation must support a user-initiated ability to delegate roles to a proxy who can be a supervisor or any other user for a randomly-defined period of time. This feature will support the Commission’s practice of temporarily assigning a staff member’s responsibilities to another staff whenever the staff member is on a leave of absence.

Resource Assignment and Revocation with related Administration and Workflows

The implementation must support the ability to create and manage “resources” like IT systems, applications or IT infrastructure.

The implementation must provide the ability to assign and revoke the assignment of these resources to users based on defined policies or scheduled tasks. Resource assignment/revocation may be triggered based on requests or based on defined policy/rule.

The implementation must support the full management of tasks related to resource assignments referenced above.

The implementation must support the creation and customization of automated workflows (Request and approval chains) for the creation of user resources and for resource assignments to users.

User Administration; Groups and Organizational Units and Roles

The implementation shall support the creation of users and user groups, organizational units as well as user and group level roles. Users’ addition may be triggered based on requests or based on defined policy/rule.

Each user shall have access to the Identity Management system with a dedicated system area or personal Inbox to track requests and personalized tasks.

Each user shall have the possibility to modify personal fields allowed by the Administrator. This functionality may be coupled with an approval workflow.

Access Policies

The implementation must support the ability to create and maintain access policies applicable to a single user, group of users or to entire user realms.

Import, Export Tasks and Scheduling

The implementation must support the ability to create, schedule and manage jobs (tasks) related to user management (Imports, exports, reconciliations etc.) at freely-definable intervals. The system must implement a means of tracking the current status and history of attempted runs for these tasks.

User Request and Self-Service

End users must be able to initiate request for account creation and resource assignment through a web form.

Audit and Reporting

The implementation shall provide standard reports on common functionalities and user activities as well as a customizable reporting interface.

The implementation shall include the possibility to retrieve a detailed audit trail for all user activities whenever required.

User Provisioning and Reconciliation including associated Interfaces

Exports:

The system must support the ability to automatically provision and synchronise records across different repositories. As a minimum, exports and synchronization with the following repository types must be supported:

• LDAP 3 –compliant directories like: Windows Active Directory (AD); Open LDAP; Sun Directory Server;

• SQL Databases like Oracle, MySQL, Sybase Adaptive Server

• Flat files (Plain text and Comma-separated values (.csv) files)

• Generic XML formatted data stores

Imports:

The system must support the ability to automatically import entire user records or parts thereof from one or more defined sources at preset intervals. As a minimum, imports and synchronization with the following repository types must be supported:

• LDAP 3 –compliant directories like: Windows Active Directory (AD); Open LDAP; Sun Directory Server;

• SQL Databases like Oracle, MySQL, Sybase Adaptive Server

• Flat files (Plain text and Comma-separated values (csv) files)

• Generic XML formatted data stores

• HR Modules of Common ERP systems (SAP; Oracle E Business Suite, PeopleSoft)

System Monitoring

The system must support SNMP for tracking the State of Health of the services deployed

Implementation Phases for Identity Management

Phase 1

• Architecture, Design and Scope Fine-Tuning

• Infrastructure Installation

• OIM Database Installation

• Oracle Application Server Installation

• OIM Deployment

• Configurations and Provisioning Connectors Installation

• Self Service Web Forms and Approval workflow.

• Testing

• Rollout

Phase 2

• Audit Implementation

• Customized Reporting

Oracle Access Manager System Requirements

Identity System and Administration

Given that there will be an installation of OIM, the Identity administration module of the OAM application will not be used to manage users on a daily basis. The underlying user directory of the OAM application will be provisioned by OIM. The Identity Administration module will however be installed because it is required in order enable Access Manager to correctly assign users to resources using associated pre-specified authentication types. All the features of the Identity module as listed below shall be activated whereby users’ permissions to access them shall be regulated as agreed between the Contractor and the Commission after the initial design.

• Centralized user management

• Group management

• Organizational entity management

• Dynamic role-based identity administration

• Workflow for automating requests and approvals relating to identity data

• Multi-level delegation of identity administration

• Self-registration and Self-service for maintaining identity data

• Data management layer

• Password management

• User interface customization

• Extensive APIs for identity integration

• Auditing and reporting

Initial Login and Integration with Liferay Portal

At the end of the Phase 2, the initial login page presented to users by OIM shall be integrated as a portlet within the Liferay Portal currently used by the Commission. During Phase 1 the minimum implementation requirement is for a starting page with links to all the resources that are accessible only through the OIM. Details of the extent of integration with the portal will be agreed upon based on the time slot available in Phase 2.

Authentication Services, Automatic Expiration/De-Provisioning

The implementation must provide a generalized means to authenticate users and systems attempting to access resources protected by the Access Manager. This can be via HTTP header variables from a login form or through an encrypted session cookie.

The Authentication service implementation must support the “basic username and password authentication” method as well as stronger methods such as digital certificates or SecurID cards.

The implementation must support username token authentication, X.509 token authentication, and SAML token authentication.

The system must provide the possibility to write custom plug-ins and authentication interface for some of the Commission’s legacy applications and its adopted Web Application Server, Apache Geronimo.

Auto Revoke after X Attempts.

Users should be revoked from system access after a specified number of invalid attempts. This threshold should be configurable by the administrator. This ensures that invalid users are prevented from retrying sign-on indefinitely

Clear text Passwords

At no time should any password be available on the network nor in the underlying Directories and database in clear, human-readable form.

Single Revoke/Resume for All Platforms.

The implementation must support a single revoke or resume of a login id, regardless of the platform. This will help to ensure that users can be revoked or resumed with only one command from one source or platform

SSO Encryption

The system must support one-way encryption, algorithms for password protection and two-way algorithms for functions such as password access control (PAC) and script-variable protection

Password Expiration

Users whose password or account has expired shall not be able to authenticate within the system from the date of expiration onwards unless the accounts are reactivated as foreseen by the system.

Authorization Services, Policies and Policy Management

The implementation must deliver a consistent, centralized management of policies across applications, while providing users granular access to Web-based content and resources.

The system must support the definition of policy domains which are used to specify how particular an application or resource is protected.

The implementation must support a cascaded authentication scheme whereby session cookies will be valid for access only to resources with the same or lower level of authentication as the one for which the session cookie was issued. For resources requiring a higher level of authentication (e.g. Public/Private Key Pairs and OTP), users must be forced to log in again with a required level of authentication if their session cookie was obtained through login at a lower level of authentication.

Ability to Enforce Global Security Rules

The system must provide the ability to enforce security rules over the entire PTS LANs regardless of platform.

Single Point of Authorization

The system must support authorizations from a single point (i.e., from Access Server). The system should not need to connect with different versions of the product on several platforms to gain the needed access to a resource.

Auditing Services

The implementation must provide a flexible and detailed reporting, auditing, and logging of events in OAM with “out-of-the-box” reports.

The auditing and log files must be configured to enable the Commission perform threat and intrusion detection, security monitoring, and reporting that are accessible through third-party reporting products like Crystal Reports.

Personalization Services

The implementation must support user personalization for other web applications through HTTP header variables and/or redirection URLs which will be returned by the Access server upon successful Authentication.

Single-Sign-On and Persistence of User Sessions

Once a user is authenticated, the system must create and maintain an SSO session for the client that frees the user from having to sign on again to access other resources or applications.

The implementation must enable users and groups of users to access multiple applications after a single login and authentication by providing an encrypted session cookie that is valid throughout the domains protected by the Access Manager for all applications the user is allowed to access. The implementation must support full SSO for the following target technologies:

• Oracle Database (Phase2)

• Active Directory (AD) Kerberos (Phase2)

• Combined AD/Unix integration (Phase2

• RSA Tokens and One-Time Password (OTP) generators (Phase1)

• Services on Apache Web Server (Phase1)

• Services on Geronimo Application Server (Phase2)

• Services on Liferay Portal (Phase2)

• Services on Apache HTTP Servers (Phase1)

• Services on Tomcat 5.5 and above (Phase1)

• Services on Alfresco ECM (Phase2)

• Exchange/Outlook Web Access (OWA

Template plug-ins shall be developed for services without existing adapter interface to OAS.

Delegated Access Administration

The implementation must support the delegation of admin responsibilities from one user to another.

System Monitoring

The system must support SNMP for tracking the State of Health of the services deployed

WebGate and Reverse Proxies

The Commission has deployed redundantly configured Big-LP load-balancers from F5 Corporation in its Web Infrastructure as Reverse Proxies for HTTP(s) services. Therefore the implementation of OIM especially the WebGate deployments must support the use of Reverse Proxies.

Implementation Phases for OAM

Phase 1

• Architecture, Design and Scope Fine-Tuning

• Infrastructure Installation (out of the scope of this proposal)

• Directory Configuration and Schema Definition (As provisioned from OIM)

• Oracle Application Server Installation

• Installation of the Identity Server and update of loaded schema with OAM configuration data

• Web Pass Installations

• Identity System Installation

• Installation of the Policy Manager (Data and Policy Manager)

• Configurations and Provisioning (Connectors and WebGate Installation)

• Testing

• Rollout

Phase 2

• Integration with services identified in Section 5.4.14 above

• OAM Audit Database Installation

• Audit Implementation

• Customized Reporting

Oracle Virtual Directory

The Oracle Virtual Directory shall be used in order to support the possibility of having multiple directories as underlying policy repository for Access Manager.

IMPLEMENTATION

DUTIES AND RESPONSIBILITIES OF THE CONTRACTOR

Preamble

The Contractor shall provide its own infrastructure, hardware and software environment necessary for the Contractor to work off site.

When working off site, the Contractor will communicate with the Commission by telephone, facsimile or electronic mail, as appropriate.

As far as feasible, no modification or enhancement should impose dependencies on software or vendors on the Commission, such as but not limited to forced upgrade, maintenance and licenses.

The Commission reserves the right to not execute or reduce by quantity any item requested in the request for proposal.

Acquisition of Hardware

The Contractor has no obligation under the project to acquire hardware for the Commission. However, the Contractor must specify the required hardware (quantities and interconnections) during the design phase.

All hardware equipment and the base operating system shall be provided and installed by the Commission.

Acquisition of Software

The Commission will procure the following software licenses:

|Product Description |Metric |Quantity |

|Identity and Access Management Suite |Internal Users |300 |

|Identity and Access Management Suite - Non Employee Users |External Users |2000 |

|Identity Manager Connector - Microsoft Active Directory |Connector |1 |

|Identity Manager Connector - Microsoft Exchange |Connector |1 |

|Identity Manager Connector - Sun Java System Directory |Connector |1 |

|Identity Manager Connector - Database Applications Table |Connector |1 |

However, the Contractor must specify additionally required software (Licenses and Add-ons).

Amendments to the existing database schema must be synchronized with the Commission’s Oracle Designer Repository.

The Commission’s software standards (available upon request) and guidelines must be followed for all modifications or enhancements.

Modifications to documentation and new documentation must conform to the Commission’s software documentation standards and templates.

The Contractor shall clearly describe the content, terms, conditions and cost (if any) of all warranties and guaranties.

Installation and Configuration

The Contractor shall install and configure the hardware to support the architecture described in Section 3. The software setup shall implement:

Oracle Application Server, (OAS)

Oracle Identity Manager (OIM)

Oracle Access Manager (OAM)

Oracle Virtual Directory (OVD)

Software Maintenance

The Commission shall be responsible for the maintenance and updates of the installed software (as covered by Oracle Software Maintenance).

Support Services

Following the installation and acceptance of the Work, the Contractor shall provide support services for a period of 12 months. This includes but is not limited to help desk calls but also product patches, bug fixes and feature upgrades on the installed system as suggested by the Commission and in compliance with the Commission’s guidelines.

Optional Extension

The Commission will have the option to extend the support services for up to three times of 12 months each. This will be an optional work to be performed on Commission’s request at the conditions defined in the Contract.

The Contractor shall provide ongoing support within the period of 12 months.

This will include periods of work on site at the premises of the Commission in Vienna, Austria to provide:

- Software updates when available

- Product patches, bug fixes and feature upgrades suggested by the Commission and in compliance with the Commission’s guidelines

DUTIES AND RESPONSIBILITIES OF THE COMMISSION

The Commission will be responsible for overall supervision of all on site operations, including the physical database environments, and physical requirements for design, development, testing and production.

For designated Contractor Personnel, and to the extent necessary for the Contractor to fulfil the requirements of these TOR when carrying out work approved by the Commission on site, the Commission will provide:

a. Infrastructure, including office space and standard office supplies, hardware and software.

b. Access to e-mail, telephone and facsimile.

c. Physical access to selected areas of the Vienna International Centre.

The Commission will make all necessary documentation and source codes available to the Contractor.

The Commission will make qualified staff available to provide assist and cooperate in responding to information requests from the Contractor in order to allow the Contractor to carry out the Work.

For designated Contractor Personnel, and to the extent necessary for the Contractor to fulfil the requirements of these TOR when carrying out work approved by the Commission off site, the Commission will assist the Contractor, if necessary, to establish remote secure shell access to parts of the Commission’s development, test and production environments.

Strict conditions and limitations on access and use of any accessed code or documentation described above will apply as contained in the Contract. Access will be granted upon request and approval by the relevant internal bodies.

REQUIRED RESOURCES

General Requirements for the Contractor

The Contractor must be from Oracle or an authorized Oracle Partner (Proof required) with a track record of implementing user management using the OIM suite of applications.

The Contractor must demonstrate that it has a quality assurance system in place, (e.g. ISO9000).

The Contractor must possess the necessary hardware and software tools to perform the work.

The Contractor must be sufficiently large and stable in order to guarantee the level of long-term maintenance support foreseen in these TOR.

Requirements for Contractor’s Personnel

− Required Experience:

The Contractor shall provide personnel for the Work whose experience must cover the following areas:

• A record of at least two successfully completed and relevant projects utilizing the technologies required of this TOR (SSO, J2EE, Web Services), must be provided.

• Ability to work with evolving user requirements and to use initiative and experience to refine such requirements. Evidence of this ability should be provided in the form of brief descriptions of previous work undertaken.

• Ability to communicate with the Commission’s staff. The Contractor’s Personnel must include someone able to produce clear and concise reports for the users and technical staff of the Commission in English.

− Required Technical Knowledge:

The Contractor shall provide personnel for the Work whose technical knowledge must cover the following areas:

Practical knowledge of J2EE OAS and OC4J

Practical Knowledge of Oracle Database and Oracle Designer

Practical knowledge of LDAP and High Availability implementation of SSO

Practical knowledge of Portal Technology especially JSR 168 compliant portals

Practical knowledge of Web Services and Web Services for Remote Portlets

UNIX and Linux operating system knowledge (Solaris and Red Hat Enterprise Linux)

DELIVERABLES

Phase 1

• Detailed System Design listing components (hardware and software), and proposed interconnects on PTS LAN as approved by the Commission.

• Fully installed, configured and tested installation of OIM with user imports in high availability configuration.

• Fully installed, configured and tested installation of OAM with user directory provisioned from OIM in high availability configuration.

• Full SSO for selected Web applications (ECS and IDC Secure Web Site) through Access Manager.

• Initial User Login and welcome page with links to accessible resources.

Phase 2

• Fully tested installation, configuration of all components agreed in the design

• Full SSO for Windows AD and MS Exchange; User provisioning for Windows and Unix LDAP

• SSO on Windows PC for internal users

• Full SSO for other agreed Java EE Web Applications through OAM

• Full SSO for agreed non Java EE Web Applications through OAM

Contractors may bid separately for the phases.

Annex 1

Sample Workflows and Mapping

Sample Mapping for PTS Users to OID In-Built Schema

|ORACLE INTERNET DIRECTORY IN_BUILT SCHEMA |CTBTO OID Basic Setup |Comment |

|Attribute Name | Mandatory or |Description |Internal Users |External Users |  |

| |Optional | |(Staff Members etc) | | |

|OrclGUID |Optional |Specifies a Unique Global ID to identify the user. |Mandatory |Mandatory | |

|Cn |Mandatory |Specifies user's first name, common nickname, or both. |Mandatory |Mandatory | |

|Sn |Mandatory |Specifies a user's last name or surname. |Mandatory |Mandatory | |

|GivenName |Optional |Specifies a user's given name. |Optional |Optional | |

|MiddleName |Optional |Specifies a user's middle name, if any. |Optional |Optional | |

|DisplayName |Optional |Specifies the name used by GUI tools for display purposes. |Mandatory |Mandatory |Generated by = GivenName + Sn |

|OrclMaidenName |Optional |Specifies a user's maiden name, if any. |Not Used |Not Used | |

|OrclDateOfBirth |Optional |Specifies a user's birth date, includes year in yyyymmdd format. |Optional |Optional |Retrievable from Trusted Source (IMIS) |

|Street |Optional |Specifies the street and location associated with a user's office |Optional |Optional | |

| | |address. | | | |

|L |Optional |Specifies the city for a user's office address. |Optional |Optional | |

|PostalCode |Optional |Specifies the postal code associated with a user's office address.|Optional |Optional | |

|St |Optional |Specifies the state associated with a user's office address. |Optional |Optional | |

|C |Optional |Specifies the country associated with a user's office address. |Optional |Mandatory |To be taken from Source application for External Users or |

| | | | | |specified in IMIS |

|EmployeeNumber |Optional |Specifies a user's employee number, if applicable. |Mandatory |Mandatory | = IMIS Number |

|O |Optional |Specifies the organization for which a user works. |Mandatory |Optional |Defaults to "CTBTO" for Staff Members. To be taken from |

| | | | | |source application for External Users |

|Title |Optional |Specifies a user's designation. |Optional |Optional |Defaults to Post Title from IMIS for Staff Members |

|Manager |Optional |Specifies the DN of a user's manager. |Optional |Optional |For Staff Members, can be generated by using the DN of the |

| | | | | |Unit Head, Section Chief, Director or ES |

|OrclHireDate |Optional |Specifies the date on which a user was hired by the organization. |Optional |Optional | |

|Mail |Optional |Specifies a user's e-mail address. |Optional |Optional |For Staff Members; to be provided by the respective |

| | | | | |applications (UNIX/ Windows) |

|JpegPhoto |Optional |Specifies a photograph of a user. |Optional |Optional | |

|TelephoneNumber |Optional |Specifies a user's office or work telephone number. |Optional |Optional |For Staff Members; Delegated Administration by ADM/GS |

| | | | | |Section |

|Mobile |Optional |Specifies a user's mobile phone number. |Optional |Optional | |

|Pager |Optional |Specifies a user's pager number. |Optional |Optional | |

|FacsimileTelephone Number |Optional |Specifies a user fax number. |Optional |Optional | |

|HomePostalAddress |Optional |Specifies the complete residential postal address of a user. The |Optional |Optional | |

| | |value is specified as $-separated values for different address | | | |

| | |components. For example, XYZ Avenue Apt. 2 $ San Francisco CA $ | | | |

| | |92345 $ USA | | | |

|HomePhone |Optional |Specifies a user's residential phone number. | | | |

|UserPassword |Optional |Specifies a password to be used for authenticating a user. |Mandatory |Mandatory |Managed by SSO depending on Policy |

|OrclActiveStartDate |Optional |Specifies the time from which the user should be allowed to |Mandatory |Mandatory |For Staff members = EOD (Entry on Duty) Date as in IMIS |

| | |authenticate. The value is represented in Universal Coordinated | | |For External users the time specified by the backend |

| | |Time (UTC) format. If the attribute is missing, then the user is | | |application with the earliest log in date for affected user |

| | |allowed to authenticate immediately. | | | |

|OrclActiveEndDate |Optional |Specifies the date beyond which a user should not be allowed to |Mandatory |Mandatory |For Staff members = End of current contract as in IMIS |

| | |authenticate. The value is represented in UTC time format. | | |For External users the time specified by the backend |

| | | | | |application with the latest log in date for affected user |

|OrclPasswordHint |Optional |Specifies the hint to use if a user forgets their password. |Optional |Optional | |

|OrclPasswordHint Answer |Optional |Specifies the answer to the password hint question. |Optional |Optional | |

|OrclIsEnabled |Optional |Specifies if a user is currently enabled to authenticate. Valid |Mandatory |Mandatory |Field can be used temporarily to block a user. |

| | |values are ENABLED (or attribute not present in the user entry) | | | |

| | |and DISABLED. A user can successfully authenticate only if a user | | | |

| | |is enabled or the attribute is not present in the entry. | | | |

|PreferredLanguage |Optional |Specifies the preferred language for communication with a user. |Optional |Optional | |

|OrclTimeZone | Optional |Specifies the time zone applicable for a user location. |Optional |Optional | |

|OrclDefaultProfile Group |Optional |Specifies the DN of the group to use as default for a user's |Optional |Optional | |

| | |profile. | | | |

|OrclIsVisible |Optional |Specifies if a user should display in a regular user search. Valid|Optional |Optional | |

| | |values are TRUE (or not present) and FALSE. If the attribute is | | | |

| | |not present, then a user record is visible. | | | |

|OrclDisplayPersonal |Optional |Specifies if a user chooses to display personal information in a |Optional |Optional |Default is false |

|Information | |user search. Valid values are TRUE (or not present) and FALSE. | | | |

|OrclWorkflow Notification |Optional |Specifies the preferred delivery mechanism for sending workflow |Optional |Optional | |

|Preference | |notification to a user. | | | |

Sample Workflow:

a.)

[pic]

The procedure outlined in Step 1 will differ depending on the group to which the User belongs. In general there would be a web form having a set of fields containing potential user attributes. One of these attributes would be a field related to the “Reason for requesting PTS Account”. Special codes may be provided to different user groups through existing manual or electronic mechanisms to enable proper identification. For example, internal units may provide codes to requesting missions whenever a Note Verbale has been received with respect to the registration of a particular user.

b.)

[pic]

-----------------------

[1] | - 6Vg{|}”•–²³µ¶ÂÃÄÞßàáâòçÜçÑÜÑÜÑÆÑ»°Ÿ“Ÿ‹‡‹~m~h^hQ^L^ ?h|7ø[2]?j[pic]?h?nèU[pic]j?h?nèU[pic] ?h³VU!h³VU5?OJPJQJmHnHtH hçœh³VU0Jh?nèjh?nèU[pic]h½,AhžwïmH nH u jh?nèh?nèU[pic]mH nH uh½,Ahò[mH sH h½,AhžwïmH sH h½,AhõGîmH sH h½,Ah¦s®mH sH h½,Ahãn~mH sH h½,AhÚG“mH sH h½,AhÙo'5?CJ$\?aJ$ OVD was not implemented in the prototype but is foreseen to be used in the project

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download