Terms of Reference
Implementation of Identity Management and Single-Sign-On for the CTBTO
Table of Contents
1.INTRODUCTION
2.BACKGROUND
2.1User and Identity Management
2.2Single Sign On.
2.3Existing Prototype
2.4Definitions and acronyms
2.5References
3.CURRENT ENVIRONMENT
3.1PTS User Community
3.1.1.Internal Users
3.1.2.External Users
3.2Major User Repositories and Directories used by the Commission
3.2.1.UNIX/Linux LDAP Server
3.2.2.Microsoft Active Directory
3.2.3.Check Point Firewall
3.2.4.IMIS (UN ERP)
3.2.5.ECS Open LDAP Server
3.2.6.VIC Internal LDAP Server
3.3Application Portfolio
3.3.1.Internal Applications
3.3.2.Externally Accessible Applications
3.4Access Methods, SSO and Integration Approach
3.4.1.Web Access
3.4.2.VPN Access:
3.4.3.Direct SSH Access:
3.4.4.Proposed Interfaces and Interconnects
4.SCOPE
4.1Phase 1
4.2Overview of Extent of SSO Coverage in Phase 1
4.2.1.Authorization, Authentication
4.2.2.Web Single Sign-On
4.2.3.Role Management
4.2.4.Policy-based Identity Management
4.3Phase 2
5.SOFTWARE REQUIREMENT
5.1Clarifications:
5.2Oracle Identity Manager System Requirements
5.2.1.Account Profiles:
5.2.2.Passwords
5.2.3.Challenge Q&A
5.2.4.Proxy
5.2.5.Resource Assignment and Revocation with related Administration and Workflows
5.2.6.User Administration; Groups and Organizational Units and Roles
5.2.7.Access Policies
5.2.8.Import, Export Tasks and Scheduling
5.2.9.User Request and Self-Service
5.2.10.Audit and Reporting
5.2.11.User Provisioning and Reconciliation including associated Interfaces
5.2.12.System Monitoring
5.3Implementation Phases for Identity Management
5.3.1.Phase 1
5.3.2.Phase 2
5.4Oracle Access Manager System Requirements
5.4.1.Identity System and Administration
5.4.2.Initial Login and Integration with Liferay Portal
5.4.3.Authentication Services, Automatic Expiration/De-Provisioning
5.4.4.Auto Revoke after X Attempts.
5.4.5.Clear text Passwords
5.4.6.Single Revoke/Resume for All Platforms.
5.4.7.SSO Encryption
5.4.8.Password Expiration
5.4.9.Authorization Services, Policies and Policy Management
5.4.10.Ability to Enforce Global Security Rules
5.4.11.Single Point of Authorization
5.4.12.Auditing Services
5.4.13.Personalization Services
5.4.14.Single-Sign-On and Persistence of User Sessions
5.4.15.Delegated Access Administration
5.4.16.System Monitoring
5.4.17.WebGate and Reverse Proxies
5.5Implementation Phases for OAM
5.5.1.Phase 1
5.5.2.Phase 2
5.6Oracle Virtual Directory
6.IMPLEMENTATION
6.1DUTIES AND RESPONSIBILITIES OF THE CONTRACTOR
6.1.1.Preamble
6.1.2.Acquisition of Hardware
6.1.3.Acquisition of Software
6.1.4.Installation and Configuration
6.1.5.Software Maintenance
6.1.6.Support Services
6.1.7.Optional Extension
6.2DUTIES AND RESPONSIBILITIES OF THE COMMISSION
6.3REQUIRED RESOURCES
6.3.1.General Requirements for the Contractor
6.3.2.Requirements for Contractor’s Personnel
6.4DELIVERABLES
6.4.1.Phase 1
6.4.2.Phase 2
Sample Mapping for PTS Users to OID In-Built Schema
Sample Workflow:
1 | Page
1.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.
1 | Page
2.BACKGROUND
2.1User 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.
2.2Single 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 anintegrated 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.
2.3Existing 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 Directoryfor 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.
2.4Definitions and acronyms
Acronym or Abbreviation / DefinitionACS-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
2.5References
CTBTO Software Development and Documentation Guidelines
(
Oracle Identity Management Suite
(
1 | Page
3.CURRENT ENVIRONMENT
3.1PTS User Community
3.1.1.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).
3.1.2.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 havea VPN access to interactremotely with some PTS Services.
3.2Major User Repositories and Directories used by the Commission
3.2.1.UNIX/Linux LDAP Server
For UNIX and Linux users, the user data is stored in redundantly-configured LDAP servers from Sun Microsystems.
3.2.2.Microsoft Active Directory
All internal users have accounts in the Windows Active Directory, which is deployed in a Microsoft cluster environment providing high availability.
3.2.3.Check PointFirewall
Some user records are directly managed in the Commission’s Check Point Firewall software.
3.2.4.IMIS (UN ERP)
This system is the initial repository for all staff records. The application uses a Sybase Adaptive Server Database.
3.2.5.ECS OpenLDAP Server
For the Experts Communication System, user authentication relies onan OpenLDAP server instance for user records. User authorization (based on a simple role-based authorization system) is handled through data stored in an Oracle database.
3.2.6.VIC Internal LDAP Server
To facilitate the exchange of contact data within the Vienna-based organizations, aLDAP server is maintained which contains only contact information for staff members. Neither authorization nor authentication is handled by this server.
3.3Application Portfolio
3.3.1.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.
3.3.2.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.
3.4Access Methods, SSO and Integration Approach
3.4.1.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.ctbto.org.
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 solutionand 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.
3.4.2.VPN Access:
The CISCO VPN Concentrator verifies user credentials using the CISCO ACS-Server (Radius) integration point with the RSA ACEServer 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.
3.4.3.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.
3.4.4.Proposed Interfaces and Interconnects
a.)Components of the Identity Management deployment
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
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.
1 | Page
4.SCOPE
The project will be implemented in two phases:
4.1Phase 1
This phase will serve:
- Fine-tuning of the requirements for the project
- Finalization of thedeployment’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)
- Installationand 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)
4.2Overview of Extent of SSO Coverage in Phase 1
4.2.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.
4.2.2.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.
4.2.3.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.
4.2.4.Policy-based Identity Management
The system will enable the enforcement of policies on user provisioning, automatic de-activation, de-provisioning, and self-service.
4.3Phase 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
1 | Page
5.SOFTWARE REQUIREMENT
5.1Clarifications:
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.”