Identity/EngPlan/VESEngPlan
Contents
- 1 Overview
- 2 Key People
- 3 Work Items
- 3.1 Verified Email Server
- 3.1.1 Port existing code to new VEP specifications
- 3.1.2 Misc. server deployment tasks and checks (LDAP connection, Mail server, etc.)
- 3.1.3 Long term data storage for VES
- 3.1.4 Complete work on server admin page (address registration)
- 3.1.5 Integrate to Clients
- 3.1.6 Performance testing for VES
- 3.1.7 Validating unit test coverage for QA
- 3.1.8 External Dependencies
- 3.1.9 Integrate to account portal for account creation.
- 3.1.10 Security Review
- 3.1.11 Package and Deploy server to Beta
- 3.1.12 Q.A. testing
- 3.1 Verified Email Server
- 4 Timeline
Overview
Identity Server Engineering plan.
This document addresses the build portions of the Identity Service Server
Key People
Technical Lead: | JR Conlin |
Additional Developers: | Rob Miller , Dave Dahl |
Project Manager: | Dan Mills |
Product Manager: | Dan Mills |
UX: | TBD |
Work Items
Verified Email Server
Top-level tracking bug: bug 663887
Port existing code to new VEP specifications
Assigned to: | jrconlin |
Bug: | 663276 |
Assumes/Depends On: | Finalization of the internal Certificate format |
Working Estimate: | *code complete as of 2011Jun13*
Best case: |
Misc. server deployment tasks and checks (LDAP connection, Mail server, etc.)
Assigned to: | jrconlin |
Bug: | N/A |
Assumes/Depends On: | Working VES |
Working Estimate: | *code complete as of 2011Jun14*
Best case: 1 day |
Long term data storage for VES
Assigned to: | jrconlin |
Bug: | N/A |
Assumes/Depends On: | finalization of the VES data requirements |
Working Estimate: | *code complete as of 2011Jun13*
Best case: |
Complete work on server admin page (address registration)
Assigned to: | jrconlin |
Bug: | N/A |
Assumes/Depends On: | Completion of UX designs, Completion of core server |
Working Estimate: | *code complete as of 2011Jun13*
Best case: 3 days |
Integrate to Clients
Assigned to: | jrconlin |
Bug: | 664575 |
Assumes/Depends On: | completion of baseline server and client |
Working Estimate: | 4 days
Best case: 2 days |
Performance testing for VES
Assigned to: | jrconlin |
Bug: | 664578 |
Assumes/Depends On: | Working VES |
Working Estimate: | 4 days
Best case: 1 day |
Validating unit test coverage for QA
Assigned to: | jrconlin |
Bug: | 664579 |
Assumes/Depends On: | Working VES |
Working Estimate: | 4 days
Best case: 1 day |
External Dependencies
Integrate to account portal for account creation.
Assigned to: | jrconlin |
Bug: | 666081 |
Assumes/Depends On: | Account portal able to create accounts and be accessed as service. |
Working Estimate: | 4 days
Best case: 2 days |
Security Review
Assigned to: | jrconlin, opsec-TBD |
Bug: | 664579 |
Assumes/Depends On: | |
Working Estimate: | 'REQUIRES SCHEDULING'
Best case: 1 day |
Security Review
= Checklist
Product Goal: Provide authenticated email addresses as signed identity certificates to client libraries.
Solutions and Approaches considered: The application uses the Verified Email Protocol. Internally, the library uses the following components:
- Services core architecture:
- nginx, python2.6, gunicorn, webob, beaker, etc.
- M2Crypto (contains centralized rsa, Crypto and wraps OpenSSL library)
- python-cjson (high speed json serializer)
Rationale for final solution: M2Crypto was chosen for two reasons: 1. It wraps OpenSLL, meaning that it's not trying to implement function independently of a proven library 2. It's fast.
cjson was chosen because it was far faster than native python JSON libraries, and this library does a LOT of JSON.
We are using redis as our back-end storage because it provides simple key::data storage. The data storage mechanism is abstracted, and can be replaced with another system if need be.
Known security threats and issues: Currently, the "admin" portions (providing the page to allow users to add and disable accounts) is meant to be called only from locally served pages, but could be spoofed. There is currently a stubbed local check function, however no method has yet been implemented.
We are working with ops to identify methods to provide adequate protection from XSS.
Summary:
Package and Deploy server to Beta
Assigned to: | jrconlin |
Bug: | 664582 |
Assumes/Depends On: | Working service, Available beta platform |
Working Estimate: | 1 day
Best case: 1 day |
Q.A. testing
Assigned to: | TBD |
Bug: | TBD |
Assumes/Depends On: | Working Service; jrconlin provides proper testing architecture |
Working Estimate: | 11 days
Best case: 5 days |
Timeline
Expected Completion
Most tasks can be parallelized with clients working off of the base server. There is some imperative in getting the base server operational on a test platform in order to provide the clients with a baseline to work from.
Working Estimate: TBD
Milestones
Milestone 1: Server Base Configuration
The server needs to work with the services base platform architecture (LDAP connectivity, data storage, and like). At this milestone, the various underlying architecture components have been resolved and preliminary connections have been made.
- Associated Bugs: 663276, (§3.1.2 & §3.1.3)
- Working Estimate: Done
- Expected completion: Done
- Requirements Resolved: R3.1, R3.7
Milestone 2: User Admin pages operational
The server will need to provide some user administration pages (e.g. login, email registration, management, etc.) At this milestone, the pages would be created and operational, but still may require UI/UX intervention.
- Associated Bugs: (§3.1.4)
- Working Estimate: Done
- Target Completion: Done
- Requirements Resolved: R3.2, R3.4, R3.5, R3.6
Milestone 3: Integrate with Client code
The server needs to be able to properly pass certification info to the client, as well as provide support for admin calls and other functions. At this milestone, the client will be able to successfully collect certificates from the server for registered emails and display various admin pages where necessary.
- Associated Bugs: 664575, 664597
- Working Estimate: 4 days
- Target Completion TBD
- Requirements Resolved: R3.3
Milestone 4: Performance and Testing analysis
In order for the code to be deployed, there must be some baseline determination of its demands on the server hardware. It must also operate correctly and with the protocol specifications. At this milestone, the server will have adequate unit tests as well as a set of load tests will have been run to determine the maximum effective traffic a server can handle with a base configuration.
- Associated Bugs: 664578, 664579
- Working Estimate: 8 days
- Target Completion: TBD
Milestone 5: Wrapup
The server needs documentation and be packaged for deployment and testing. At this milestone, the server will be in a beta consumer ready state. Documentation and packaging may not be finalized, but they should be at a point where an external developer can set up and use the system with no prior knowledge of the system and minimal assistance.
- Associated Bugs: 664579, 664582, (§3.1.11)
- Working Estimate: 13 days
- Target Completion: TBD