design/identity-provisioning.mdwn

   1 [[!meta title="Provisioning Identities"]]
   2 ##Provisioning Identities
   3
   4 One of the most significant user experience challenges for moonshot  is configuring a machine to use a particular Moonshot identity. In effect,  the machine needs to be enabled for moonshot.
   5
   6 There are three ways this can happen:
   7
   8 1. A user wants to use an identity provider website to provision their identity
   9 2. An administrator wants to provision one or more identities
  10 3. A user wants to manually add an identity.
  11
  12 The manual case is one that will likely be very uncommon and is not one to focus on.
  13
  14 In addition to provisioning identities, a system administrator may
  15 wish to provision rules for which services should be used with which
  16 types of identities.
  17
  18 So, we need to support:
  19
  20 * a identity provider website providing a encoded identity card
  21 * A system administrator providing an encoded identity card
  22 * A system administrator providing rules files system wide
  23 * A system administrator providing rules files for a user
  24
  25 ### Encoding considerations
  26
  27 The encoded identity card and encoded rules file  need to use some sort of extensible format. We're already depending on JSON using the Jannson library. XML would also be acceptable.
  28 We can protect these files in transit using TLS and at rest using file permissions. As a result providing cryptographic integrity or confidentiality in the format is not a concern for the first version
  29
  30 ### When an identity card is provisioned
  31
  32 * The identity is taken from the encoded identity card and added to the user's database of encoded identities. As a consequence identity cards can only provisioned for a specific user, not for the system.
  33 * If a password is supplied, this password is saved with the identity card. When provisioning an identity from a website it is typical that a password is provided
  34 * Rules for service selections are recorded and tied to the identity
  35 * Any attributes associated with the identity are stored.
  36
  37 No actual services are specifically associated with the identity at
  38 provisioning time; see the section on identity selection below.
  39
  40
  41 Handling updates to an identity is an open question.
  42 We want to be careful of phishing and to make sure that an updated identity comes from the same source as the existing identity.
  43
  44 ### Service selection rules
  45
  46 One of the goals of these enhancements is to minimize or avoid
  47 entirely situations where the user has to pick an identity.  We will
  48 accomplish this by having rules to describe services.  Such a rule may
  49 match for example all IMAP servers or all servers in a given service
  50 realm.
  51
  52 These rules can be used in two ways.
  53 First, they can directly be attached to a provisioned identity. If a service's name matches a rule attached to a given identity, that identity is a candidate for that service.; see the service selection rules below for what happens then.
  54
  55 Secondly, an administrator can attach a service selection rule to an identity selection rule. In this case, the service selection rule may be attached to any identity that matches the identity selection rule.
  56
  57 Service selection rules contain:
  58
  59 * A glob pattern matching a set of services
  60 * The always_confirm flag; if this flag is set then the user is always prompted to confirm the match
  61
  62 ###Selecting a service
  63
  64 ####Constructing the service selection rule set
  65
  66 The system maintains a dynamic set of service selection rules that are attached to identities in the system. Given one of these rules the system needs to be able to find the identity to which it is attached. Also, the system needs to be able to find the service selection rules associated with a given identity. Note none of these are comments about what the UI needs to display; simply requirements of the abstract representation.
  67
  68 In particular:
  69
  70 Some service selection rules are stored along side identities. In
  71 particular, when a service selection rule is part of an encoded
  72 identity card, it is stored along side that identity. Unless the
  73 identity is deleted, this rule remains attached to the identity.
  74
  75 However, the user interface also needs to manage the binding between
  76 service selection rules attached to identity selection rules and
  77 actual identity cards.  To do this, at UI start-up and whenever an
  78 identity is added, the system enumerates all identity selection
  79 rules. If an identity selection rule triggers, then the service selection rules associated with the identity selection rule are attached to the identity card that triggered this rule. These rules are only associated in the running instance of the UI; they are not stored with the identity card. If the identity selection rule is removed by an administrator, then any service selection rules from the removed identity selection rule will no longer be present after the next time the UI is reloaded.
  80
  81 ####Services associated with identity cards
  82
  83 As in the existing system, an identity card may have an associated set of services. These are not rules: these are single services that the user or system has associated with the identity.
  84 No automated provisioning will ever populate this list.
  85
  86
  87 #### None
  88
  89 The UI needs to maintain a none identity card indicating that Moonshot
  90 should not be used for a particular service.  This card cannot be
  91 deleted, but it can have services associated with it; these associations may be deleted. No service selection rules can be attached to the none identity.
  92
  93
  94 ####Algorithm for handling service selection
  95
  96 This algorithm maintains the following state:
  97
  98 * a will_confirm flag initially set to false
  99 * A set of identity cards called the candidate set, initially empty
 100 * An identity constraint.
 101
 102 The service selection algorithm is triggered when an application requests a service. The application passes in a NAI, service and password, any of which may be empty.
 103
 104 1. If the NAI is non-empty and an identity card with this NAI exists, then the identity constraint is set to the NAI. The identity card corresponding to this NAI is added to the candidate set.
 105
 106 2. If the system is in a global confirm everything mode per discussions after Prague, set will_confirm to true.
 107
 108 3. For every identity card that has this service associated directly with the identity card (not a triggering rule--the actual service),  add the identity card to the candidate set.
 109
 110 4. If the candidate set contains more than one identity card, disassociate this service from all identity cards.
 111
 112 5. If the candidate set is non-empty go to the step labeled "INTERACT".
 113
 114 6. For each service selection rule that triggers on this service, add the identity cards associated with that service selection rule to the candidate set. If any of these rules has the will_confirm flag set to true  then set the will_confirm flag in the algorithm state to true.
 115
 116
 117 7. INTERACT: If there is more than one identity in the candidate set then set the will_confirm flag to true. If there is an identity constraint, then remove any candidate identity that does not match the identity constraint.
 118
 119 8. If the will_confirm flag is true, then ask the user to select the identity to use. If the candidate set is non-empty then indicate these candidates. They may be indicated by only displaying the candidates with a button to display more options, or by highlighting the candidate set members, or some other appropriate mechanism. The user should also be given the none option.
 120
 121 9. If the service is non-empty then associate the service with the selected identity card.
 122
 123 10. Return the information for the selected identity card to the application.
 124
 125
 126 ###Attributes of an identity card
 127
 128 * NAI
 129 * password
 130 * trust anchor
 131 * a friendly name like "work account"
 132 * Service selection rules provisioned with the identity
 133 * Website for password changing and the like
 134
 135
 136 ### Attributes of an identity selection rule
 137
 138 * Identity glob pattern
 139 * set of service selection rules
 140
 141 ### Web provisioning of identity
 142
 143 When a website attempts to provision an identity, user interaction is required. The user needs to be given an opportunity to:
 144
 145 * Change or supply the friendly name for the identity
 146 * Indicate that the UI should always ask before using services with this identity; if so, the will_confirm flag on all service rules for this identity is forced to true
 147 * Reject the identity as one that should not be provisioned
 148
 149 This work flow is probably not desired when an administrator provisions an identity.