This page lists the workflows users will be able to complete when the release is ready.

Contents

  1. Goals
    1. As a Server
    2. As a Router
  2. Configured User Sends FBX a Service Request
  3. Configuring New Users
  4. Box-to-Box Service Location Updates
  5. Key Exchange / Introduction Process Between Users
  6. Teaching Client About Box's Services
  7. FBX-App Connecting to Box's Services
  8. User Telling FBX-App to Connect to Local Box's Services
  9. User Telling FBX-App to Connect to Remote Box's Services
  10. Enabling New Service
  11. Footnotes

Goals

The FreedomBox is both a system that provides services for others and a router that protects its user's communications.

As a Server

(By default)

  1. Users can connect to their FreedomBox's services with client certificates:

    1. On their desktop's browser.
    2. On their mobile device.
  2. Administrators can selectively authorize (local and remote) users for services hosted on the box.

As a Router

(By default)

1. Communications that don't have to leave the box, won't. 2. The box will route all external connections through privacy-enhancing and anonymizing tools.

Configured User Sends FBX a Service Request

  +-------------+      +-------------+
  | User Agent  |      | Service     |
  |             |      |             |
  |             |<-----+             |
  |             |    6 |             |
  |             |      |             |
  +----------+--+      +-------------+
           1 |                 ^
             |                 | 5
             |         +-------------+-------------+
             |         | Web Server  | LDAP        |
             +-------->|        2,3 -+>            |
                       |             |             |
                       |            <+- 4          |
                       |             |             |
                       +-------------+-------------+
  1. Browser sends request to FBX.
  2. Web server receives request, authenticates user's key id. Web server 401s user if no key.
  3. Web server requests LDAP authorizes user's key.
  4. LDAP informs web server of its decision. Web server 403s user if LDAP doesn't authorize.
  5. Having been authenticated and authorized, web server passes request on to service.
  6. Service processes request, using key id as user id and replies to user.

Configuring New Users

  +-------------+      +-------------+
  | User Agent  |      | Hello       |
  |             |      |             |
  |             |<-----+             |
  |             |    4 |             |
  |             |      |             |
  +----------+--+      +-------------+
           1 |                 ^
             |                 | 3
             |         +-------------+-------------+
             |         | Web Server  | LDAP        |
             +-------->|            -+>            |
                       |          2  |             |
                       |            <+-            |
                       |             |             |
                       +-------------+-------------+

  1. User requests Hello service.

  2. Web server checks with LDAP to see if user without key (Nobody) is authorized for Hello right now.
  3. The Hello service begins by de-authorizing Nobody*, then it creates a PGP key, signs it with the box's key, and fully trusts the key. That key is then exported as an SSL certificate.

  4. The user-agent receives the key and the SSL certificate. It installs the certificate into the local store. The user can now access the system per the Configured User Sends FBX a Service Request workflow.

Box-to-Box Service Location Updates

  +--------------+
  | Freedombuddy |
  |              |  3
  |              |<------------+
  |              |             |
  |              |             |
  +----------+---+             |
           1 |                 |
             |               2 |
             |         +-------+------+
             |         | FreedomBuddy |
             +-------->|              |
                       |              |
                       |              |
                       |              |
                       +--------------+

  1. A sends location request to B's FBuddy service.

  2. B replies with updated locations to A's FBuddy.
  3. A records updates.

Key Exchange / Introduction Process Between Users

  +-------------+         +--------------+
  | User Agent  +-------->| FreedomBuddy |
  |             | 1       | 2            |
  |             |         |              |
  |             |<--------+              |
  |             | 3       |              |
  +-------------+         +--------------+
  1. User A sends identity and service locations in a self-signed statement to User B.
  2. User B verifies signed statement. Imports identity and service locations if all is well.
  3. User B replies to destination A just defined to inform A of identity and (optionally) provide A services.

Teaching Client About Box's Services

FBX-App Connecting to Box's Services

User Telling FBX-App to Connect to Local Box's Services

User Telling FBX-App to Connect to Remote Box's Services

Enabling New Service

  1. User selects service-to-enable in Plinth.

  2. User selects authorized client-users from pool of known users.
    1. User can select or enter new key ids when authorizing users.
  3. Nobody (users without client certificate ids) denied access by default.
  4. User is presented with any absolutely necessary configuration options.
    1. If service has any required configuration options, service should be patched to function without those options and prompt the user when the user accesses the service for the first time?
  5. Service is enabled.

Footnotes

* This step generates cryptographic keys and consumes lots of entropy (effectively a non-renewable resource on a plugserver), so the Hello service should not be enabled for more users than necessary.