design/revisedclientarchitecture.mdwn

   1 ## Revised Client Architecture
   2
   3 The architecture of the initial implementation needs to be re-factored to with give better Model, View, Controller separation, allowing for:
   4
   5 - more ways of interacting with the server than the ID Selector App and Web Provisioning;
   6 - different storage strategies;
   7 - ease of maintenance.
   8
   9 Specific requirements from the Statement of Work are
  10
  11     6.1 Abstract the interface between the Identity Selector and its backend datastore.
  12         This is required to allow different such datastores to be used at will (e.g. Gnome
  13         Keyring, Mac Keychain, etc).
  14
  15     6.2 Abstract the interface between the core logical component of the Identity Selector
  16         and the current UI elements. This is required to enable other interfaces to the Identity
  17         Selector to work, such as a platform specific UI or a Command Line Interface to enable
  18         headless operation. Any policy or invariant or constraint logic currently independent of
  19         the core logical component must be abstracted into the core so that no matter what
  20         backend datastore or UI frontend is used, all policy or invariant or constraint logic is
  21         always used and enforced.
  22
  23 ### Overview
  24
  25 This diagram shows the proposed new architecture.
  26 ![image](https://gitorious.org/petefoth-public-docs/petefoth-public-docs/blobs/raw/master/Moonshot/Proposed%20New%20Architecture.jpg)
  27
  28 The re-factored Moonshot Client software will have the following components:
  29
  30 *_identity-selector-ui_* an application allowing:
  31
  32 - the User to manage identities which are provisioned on the client machine
  33 - other applications needing access to identities to access internet services.
  34
  35 *_identity-server_*  shared library offering C and Vala APIs.
  36
  37 - provides Create / Read / Update / Delete functionality for Identities
  38 - is the only means of accessing the _identity-storage-server_
  39 - includes the server functionality initially implemented in UI
  40
  41 *_identity-storage-server_*  encapsulates the Identity Store in a shared library offering a CRUD API to access the store.
  42
  43 - protects the store from multiple concurrent write accesses
  44 - re-implemented per platform and per storage strategy so
  45
  46   * one version each for Linux, Mac OS and Windows, local storage. DBus provides an appropriate mechanism under Linux and Mac OSX for protecting the store from multiple concurrent write access. It is not supported on Windows, so the Windows implementation will use a different mechanism. This version will re-use storage-related code from src/moonshot-window.vala etc.
  47   * one version for web storage, restful API. (Not in scope for this iteration).
  48   * other versions as required for different storage solutions  (Not in scope for this iteration).
  49
  50 *_identity-provisioning_* - not implemented in the initial implementation. Provides CRUD operations via (for now) .msht and XML files, and via command line. Implemented in portable code as far as possible. Uses *_identity-server_*. Consists of
  51
  52 - *_identity-provisioning-file-handler_* - processes .msht (and, in future iterations, XML and/or json, and maybe other format) files for file-based provisioning operations. Currently implemented as *_moonshot-webp_*, allowing only install access. In future iterations it will also allow uninstall/revoke access.
  53 - *_identity-provisioning-cli-handler_* - provides a command line API to identity CRUD functions
  54
  55 All of the components will be implemented in Vala.
  56
  57 ### Detail _identity-server_ component
  58
  59 Implemented as a shared library in Vala. Built with the -H option to enable access from C code, and introspection generated to allow use from other languages.
  60
  61 Replaces the _libmoonshot_ component from the initial implementation.
  62
  63 Owns the public APIs for accessing the Identity Store (rather than, as in the initial implementation, exposing the APIs provided via DBus by _moonshot-ui_).
  64
  65 Provides the APIs  provided in the initial implementation by _lib-moonshot_ (getIdentity(), GetDefaultIdentity(), InstallId_card()) which are used:
  66
  67 - by identity-selector-ui component
  68 - by other applications to obtain the identities they need to access internet services *without interacting with the user*;
  69 - by _identity-provisioning_ components
  70
  71 Provides new APIs needed by _identity-selector-ui_ and _identity-provisioning_ components, to manage identities (e.g. CreateNewIdCard(), UpdateIdCard(), DeleteIdCard()).
  72
  73 Uses the APIs provided by the *_identity-storage-server_* component (_-dbus-local-storage-server_ on Linux and Mac, _-windows-local-storage-server_ on Windows).
  74
  75 It has no UI, so that it can be used in circumstances where interaction with a user is not possible (e.g. in headless servers). Any needed interaction with the User is done by client software.
  76
  77 ### Detail _identity-selector-ui_ component
  78
  79 This provides a UI which can be used both by the user, and by other application which need to interact with the user in selecting the identity they will use to access an internet service.
  80
  81 It no longer owns the Identity Store.
  82
  83 It no longer *provides* the APIs (using DBus) that were used in the initial implementation by other components via _libmoonshot_ to access the Identity store.
  84
  85 Instead, it *uses* APIs provided by _identity-server_ to access the Identity store.
  86
  87 Implemented in Vala using GTK widgets, reusing code from src/moonshot-window.vala and other UI related code..
  88
  89 ### Detail _identity-provisioning_ component
  90
  91 The *_identity-provisioning-file-handler_* component replaces the moonshot-webp component. It provides the same InstallIdentityCard() functionality as the moonshot-webp component in the initial implementation. In future iterations, it will provide new functions to uninstall and revoke identities.
  92
  93 The *_identity-provisioning-cli-handler_* component is not part of the current iteration. In a future iterations it is intended to provide via the command line the same functionality as *_identity-provisioning-file-handler_* but without requiring any interaction with the user.
  94
  95 ### Use Case Implementation
  96
  97 The re-factored software is designed to implement the following use cases that were part of the initial implementation:
  98
  99 1. User installs and identity by clicking on a .msht file downloaded from the Web
 100 1. User creates and installs an identity card using the UI
 101 1. User modifies an existing identity card using the UI
 102 1. User deletes an existing identity card using the UI
 103
 104 It is designed to extend the above Uses cases as follows:
 105
 106 1. User can install .msht files when attached to emails
 107 1. User can use .msht files to delete or revoke identities
 108 1. User can create, view, update and delete installed identities via the command line
 109 1. User can create, view, update and delete installed identities using a script file
 110
 111 Not all of these will be implemented in the current phase, but the software will be implemented in a way that facilitates their implementation in future phases.
 112