Address RBAC HLD comments (#94)

doc/aaa/SONiC RBAC.md

@@ -63,6 +63,7 @@
 | Rev |     Date    |       Author       | Change Description                |
 |:---:|:-----------:|:------------------:|-----------------------------------|
 | 0.1 | 04/07/2020  | Nirenjan Krishnan  | Initial version                   |
+| 0.2 | 06/12/2020  | Nirenjan Krishnan  | Update with review comments       |
 
 # About this Manual
 This document provides a high-level design approach for authentication and RBAC in the SONiC Management Framework.
@@ -107,15 +108,13 @@ TBD
 #### 1.1.1.1 NBI Authentication
 A variety of authentication methods must be supported:
 * **CLI** authentication is handled via user detection on the Unix Socket.
-  CLI shall also support communication to the REST server over a TCP connection,
-  but this shall use Certificate-based authentication to ensure that the CLI
-  user is an authorized user.
 * **REST** authentication
   - Password-based Authentication
   - JWT token-based authentication
   - Certificate-based Authentication
 * **gNMI** Authentication
-  - Password-based Authentication with Token-based authentication
+  - Password-based Authentication
+  - JWT token-based authentication
   - Certificate-based Authentication
 
 #### 1.1.1.2 CLI Authentication to REST server
@@ -143,12 +142,6 @@ via the following steps:
 6. When the user exits the KLISH CLI session, the HTTP persistent connection is
    closed. The REST server will clean up the corresponding authentication token
    for its corresponding KLISH CLI Client.
-7. In order to accomodate those CLI actioners that are generated by the Swagger
-   code generator, the REST server will also listen on port 8443 with
-   certificate based authentication to identify the user.
-   - This is necessary since the Swagger code generator does not support
-     connections over Unix sockets.
-
 
 #### 1.1.1.3 REST/gNMI server authentication methods CLIs
 
@@ -170,6 +163,8 @@ run `system` commands from KLISH.
 
 #### 1.1.1.5 Customizable roles
 
+**This is planned for future support.**
+
 Admin users shall be able to create customizable roles for further granularity beyond read-only and read-write. For instance, a `secadmin` role shall allow the users to configure security parameters on the switch. The custom role shall have a default deny policy. Custom roles shall map a set of features, and their access level to the feature. A feature is a set of YANG paths. The default policy is no access to a feature, if it is not specified in the role.
 
 ```
@@ -216,11 +211,9 @@ to start from a known state. Sample feature description is shown below.
 #### 1.1.1.6 Local User Management and UserDB Sync
 An interface must be developed for local user management, so that administrators can add users and assign passwords and roles to them. Administrators with the appropriate role must be able to add/delete users, modify user passwords, and modify user roles. They must be able to do so through all of the NBIs, meaning that a YANG model and CLI tree must be developed.
 
-Users must be added to the Linux database (`/etc/passwd`, `/etc/group`, and optionally `/etc/shadow`). That's where a user is mapped to a Linux [User Identifier](https://en.wikipedia.org/wiki/User_identifier) (UID) and primary [Group Identifier](https://en.wikipedia.org/wiki/Group_identifier) (GID). When users are created they also need to be assigned roles. Roles are simply defined as Linux groups (`/etc/group`) and assigned to users as [Supplementary GIDs](https://en.wikipedia.org/wiki/Group_identifier#Supplementary_groups).
-
-When a user is created it also needs to be assigned certificates that will allow them to communicate with the REST server. Finally, all users need to be added to the REDIS database where additional information about each user can be stored.
+Users must be added to the Linux database (`/etc/passwd`, `/etc/group`, and optionally `/etc/shadow`). That's where a user is mapped to a Linux [User Identifier](https://en.wikipedia.org/wiki/User_identifier) (UID) and primary [Group Identifier](https://en.wikipedia.org/wiki/Group_identifier) (GID). When users are created they also need to be assigned roles. Roles are defined in the REDIS database. Users may also be assigned to supplementary Linux groups (`/etc/group`) in order to allow functionality required for their roles (e.g. Docker group membership in order to spawn the CLI).
 
-Since these operations (i.e. creating Linux users, assigning certificates, etc.) are non-trivial, the process of creating users will be entrusted to the Host Account Management Daemon (**hamd**).
+Since these operations (i.e. creating Linux users, assigning roles, supplementary groups, etc.) are non-trivial, the process of creating users will be entrusted to the Host Account Management Daemon (**hamd**).
 
 ##### 1.1.1.6.1 Host Account Management Daemon (hamd)
 
@@ -237,7 +230,7 @@ The hamd process will provide the following APIs to create/modify/delete user an
 - **usermod**: To create or modify users. This method will accept a username,
   hashed password, and a list of strings corresponding to the roles.
 
-The hamd process will add the users to the User Table in the Config DB, however, only the username and roles will be saved in the DB. The password will not be saved due to security considerations.
+The hamd process will add the users to the User Table in the Config DB.
 
 ##### 1.1.1.6.2 Name Service Switch
 
@@ -292,7 +285,7 @@ RBAC will be enforced centrally in the management framework, so that users acces
 
 Users and their role (group) assignments may be managed via the NBIs. HAM shall
 provide tools to allow administrators to manage the users and roles from the
-shell (Click command? Shell script? TBD)
+shell using the hamctl command.
 
 # 3 Design
 ## 3.1 Overview
@@ -310,6 +303,8 @@ shell (Click command? Shell script? TBD)
 
   **Note**: The UserTable will _not_ store users' salted+hashed passwords due to security concerns surrounding access restrictions to the DB; instead, that information will be maintained in `/etc/shadow` as per Linux convention.
 
+**Future Support**
+
 * **PrivilegeTable**
 
   This table provides the information about the type of operations that a particular role is authorized to perform. The authorization can be performed at the granularity of a feature, feature group, or the entire system. The table has the following columns :