Manage Robot Connection: 802.1x Authentication

[umbhau]

As a robot user, I would like to be able to connect to wireless networks with enterprise (802.1x) security.

Acceptance Criteria

• [ ] If user selects a network with 802.1x authentication:
  • [ ] They see a dialogue box with the following:
  • [ ] Copy explaining that their selected network requires 802.1x (enterprise) authentication, and to please select the authentication method.
  • [ ] Dropdown to select from supported 802.1x authentication methods (returned from api)
  • Note this list currently includes: EAP-TLS, PEAP/EAP-MSCHAPv2 (eduroam), TTLS/EAP-MSCHAPv2, TTLS/EAP-TLS, TTLS/MD5
• [ ] After user selects authentication type, display required fields for authentication. Note fields and labels returned by /eap-options, and can be of three types:
  • Text (will include a field label string, e.g. 'username')
  • Password (label also provided by API)
  • [ ] Add a 'show password' box for every password field
  • Certificate (allow user to upload a certificate file; may include multiple certificate fields)
  • [ ] Display progress icon next to certificate field during upload
  • Fields can be required or optional (also provided by API; indicate required fields with asterisk)
  • Question: How many fields do we have to support?
  • Note we may have to display up to six fields
  • Note design should support fields labels as long as 30 char (e.g. 'Inner Client Certificate File')
• [ ] Allow user to 'Join' to attempt network auth, or 'Cancel' and close modal.
• [ ] Join button is disabled until required fields complete
• [ ] If user blurs a required field while empty, display 'required field' in red below the field

Break out into stories Story 1: Allow user to select from 802.1 x auth types modal (med) Story 2: 802.1x auth modal (md) Story 3: Certificates (large)

• Check robot for certificates
• Allow user to select from existing certificates upload certificates from local
• Allow user to auth with certificates Story 4: Field validations (tbd pending designs)

Implementation Notes

• Note we already know which networks require some form of 802.1x authentication
• Note GET /wifi/eap-options will return both currently supported auth types as well as fields required per auth type
• Note this only includes basic certificate management (user can submit, but we will not check for existing certificates during future auth attempts)

Design

Open questions

• What happens if a required field is not entered
• https://zpl.io/Vkn9mG5
• https://zpl.io/VDnQOWr
• https://zpl.io/blPom60
• https://zpl.io/2pBNdPQ
• https://zpl.io/VDnQOoq
• authentication failed https://zpl.io/bAEwEAO

[mcous]

Ping @umbhau and @pantslakz - following up on questions from above:

Does the robot know what type of authentication protocol it is dealing with?

The robot knows the difference between "no security", "standard username/password", and enterprise. Once we're in the "enterprise" bucket, there are several (5 at the time or writing) we can support, but the robot has no way of telling us which of those 5 a network uses.

What auth protocols should we allow the user to select?

We have enough information to drop the user to:

• No password box (or disabled box) for networks with no security
• Password box for WPA2 networks
  • After talking to @sfoster1, for now we can safely ignore WEP (deprecated 2004), WPA1 (deprecated 2006), and anything else
• API-driven enterprise selection box

  • 2283 adds an endpoint that returns enterprise security types and a list of required and optional fields for each type

  • A field has a name, a displayName, a required flag, and a type
  • There are three types of field
    • Normal text (e.g. "Username")
    • Password (e.g. "Password")
    • Certificate file ID (e.g. "Private Key File") see below

Certificate files

Some enterprise authentication mechanisms require one or more certificate files. Selecting a certificate file for a given input is a multi-step process:

1. Get list of certificates already on the robot
   • If certificate is already loaded, populate field with the ID and you're done
2. If not already on robot, upload the file to the server
3. Server will return an ID, populate certificate field with the ID

If we wanted to, we could get away with not building a certificate management flow and just upload the files every single time. This would probably be subpar from a UX standpoint but is technically feasible.

[umbhau]

Closing in favor of: Manage Robot Connection: Select Type of 802.1x Authentication #2412 Manage Robot Connection: Enter Authentication Information #2413 Manage Robot Connection: Certificate Authentication #2415 Manage Robot Connection: Required Fields #2416