| 3 | | = Account management systems = |
| 4 | | |
| 5 | | To create an account with BOINC projects, a participant must: |
| 6 | | |
| 7 | | * Locate BOINC project web sites, e.g. using Google. |
| 8 | | * Read the web sites, and decide which to join; |
| 9 | | * Download and install the BOINC client software. |
| 10 | | |
| 11 | | and then for each selected project: |
| 12 | | |
| 13 | | * Go through the Attach to Project wizard. |
| 14 | | |
| 15 | | If the participant chooses N projects, there are N web sites to visit and N Wizards to complete. |
| 16 | | This is tedious if there are lots of projects. |
| 17 | | |
| 18 | | This document describes BOINC's support for 'account management systems', |
| 19 | | which streamline the process of finding and joining BOINC projects. |
| 20 | | The account manager concept was conceived and developed jointly by [http://gridrepublic.org/ GridRepublic] and BOINC. |
| 21 | | A typical account management system is implemented as a web site. The participant experience is: |
| 22 | | |
| 23 | | * Visit the account manager site, set up a 'meta-account' (name, email, password), |
| 24 | | browse a list of projects, and click checkboxes to select projects. |
| 25 | | * Download and install the BOINC client software from the account manager. |
| 26 | | * Enter the meta-account name and password in a BOINC client dialog. |
| 27 | | |
| 28 | | This requires many fewer interactions than the manual approach. |
| 29 | | |
| 30 | | == Implementation == |
| 31 | | |
| 32 | | An account management system works as follows: |
| 33 | | |
| 34 | | [[Image(http://boinc.berkeley.edu/images/acct_mgt2.png)]] |
| 35 | | |
| 36 | | 1. The participant sets up his meta-account and selects projects. |
| 37 | | 2. The account manager issues a create account RPC to each selected project. |
| 38 | | 3. the participant downloads and installs the BOINC client software from the account manager. |
| 39 | | The install package includes a file (specific to the account manager) containing the URL of the account manager. |
| 40 | | 4. The BOINC client runs, and asks the participant to enter the name and password of his meta-account. |
| 41 | | 5. The BOINC client does an RPC to the account manager, obtaining a list of accounts. |
| 42 | | It then attaches to these accounts and proceeds. |
| 43 | | |
| 44 | | There are [WebRpc web RPCs] to create, look up, and modify accounts. |
| 45 | | |
| 46 | | == Security == |
| 47 | | |
| 48 | | If hackers break into an account manager server, |
| 49 | | they could potentially cause the account manager to instruct all its clients |
| 50 | | to attach to malicious a BOINC project that runs a malicious application. |
| 51 | | To prevent this type of attack, the URLs distributed by an account manager are digitally signed. |
| | 3 | = Account Managers = |
| | 4 | |
| | 5 | This document describes BOINC's support for |
| | 6 | [[https://boinc.berkeley.edu/wiki/Account_managers 'account managers' (AMs)]], |
| | 7 | which can streamline the process of finding and joining BOINC projects. |
| | 8 | |
| | 9 | An AM provides a 'level of indirection' between volunteers and projects. |
| | 10 | Instead of attaching the BOINC client directly to projects, |
| | 11 | the volunteer attaches it to an AM account. |
| | 12 | The client then periodically issues an RPC to the AM, |
| | 13 | obtaining a list of project accounts. |
| | 14 | It then attaches to those accounts, and fetches jobs from the projects. |
| | 15 | |
| | 16 | == Attaching to an AM == |
| | 17 | |
| | 18 | A volunteer can attach a BOINC client to an AM account |
| | 19 | using the Tools / Use Account Manager command in the BOINC Manager. |
| | 20 | This brings up a dialog where they can choose a "vetted" AM |
| | 21 | (currently BAM!, !GridRepublic, and Science United) |
| | 22 | and enter the account credentials. |
| | 23 | They can also enter the URL of a non-vetted AM. |
| | 24 | |
| | 25 | Vetted AMs can optionally support the |
| | 26 | [SimpleAttach simplified registration/download process], |
| | 27 | where new volunteers can download the BOINC installer directly from the AM, |
| | 28 | and the attachment is done automatically during the install. |
| | 29 | |
| | 30 | == Project accounts == |
| | 31 | |
| | 32 | There are two approaches to project accounts: |
| | 33 | |
| | 34 | * BAM! and !GridRepublic create separate project accounts for each volunteer. |
| | 35 | These accounts have the same email address and password as the AM account. |
| | 36 | This gives volunteers an identity on each account, |
| | 37 | at the cost of putting private data on each project. |
| | 38 | * Science United uses a single "anonymous" account on each project. |
| | 39 | |
| | 40 | == URL-signing == |
| | 41 | |
| | 42 | If hackers break into an AM server, |
| | 43 | they could potentially cause the AM to instruct all its clients |
| | 44 | to attach to a BOINC project that runs a malicious application. |
| | 45 | To prevent this type of attack, the URLs distributed by an AM are digitally signed. |
| 335 | | |
| 336 | | == Host identification == |
| 337 | | |
| 338 | | BOINC uses two ID spaces for hosts: |
| 339 | | |
| 340 | | * Cross-project ID (CPID). |
| 341 | | This is used in the statistics data exported by projects. |
| 342 | | The 'authoritative' CPID is stored on the host itself. |
| 343 | | A host's CPID changes whenever it attaches to a new project. |
| 344 | | CPID is propagated to projects in scheduler RPCs. |
| 345 | | If a host is attached to several projects, its CPID (as reported by those projects) |
| 346 | | may be inconsistent for several days. |
| 347 | | Because of these properties, CPID is not useful as a primary host identifier. |
| 348 | | * Project database ID (DBID). |
| 349 | | This is a project-specific integer identifier. |
| 350 | | On a given host, it changes only in the rare case |
| 351 | | where a user copies state files from one computer to another; |
| 352 | | in that case, one of the two computers is assigned a new ID after its next scheduler RPC. |
| 353 | | |
| 354 | | An account manager RPC request includes the host's CPID, and its DBID on all projects to which it's attached (see above). |
| 355 | | |
| 356 | | A suggested method of maintaining a user's hosts is as follows: |
| 357 | | |
| 358 | | * Maintain a host table with columns |
| 359 | | * user ID |
| 360 | | * project ID |
| 361 | | * DBID |
| 362 | | * CPID |
| 363 | | * On each account manager RPC, for each reported project, |
| 364 | | look up (user ID, project ID, DBID) in the host table (where 'DBID' is the one passed in the RPC request). |
| 365 | | If no record is found, create one. In any case, update the record with the CPID from the RPC request. |
| 366 | | * To show the user a list of their hosts, with current per-project credit: |
| 367 | | do a show_user.php RPC to each project to get a list of hosts. |
| 368 | | Update the corresponding records in the host table, based on the DBIDs returned by show_user.php. |
| 369 | | Delete any host table entries for this user/project that don't appear in the RPC reply. |
| 370 | | Ignore the CPIDs returned by the show_user RPC (they may not be consistent). |
| 371 | | Then do a query on the host table, grouping by CPID. |
| 372 | | |
| 373 | | |
| 374 | | == Client Initialization == |
| 375 | | |
| 376 | | By including [http://boinc.berkeley.edu/wiki/Initialization_files appropriate initialization files] in the client installer, |
| 377 | | you can cause the client to attach to a particular meta-account, |
| 378 | | or to prompt the user to create a meta-account. |
