Namespace: "sysadm"
Name: "settings"
Arguments structure needs the "action" variable/value for all calls:
Action: "list_ssl_certs"
- No additional input needed: will list the known/registered certificates organized by <username> : { <public_key> : <certificate as text> }
Action: "register_ssl_cert"
Example Payload: {"action" : "register_ssl_cert", "pub_key" : <public_key> }
The <public_key> string needs to match the public key of one of the certificates currently loaded into the server/client connection. This will register that certificate on the server and allow that user to authenticate without a password as long as that same certificate is loaded up in any future connections. No special outputs are send back (just overall error/ok status).
Action: "revoke_ssl_cert"
Example Payload: {"action" : "revoke_ssl_cert", "pub_key" : <public_key>, "user" : <optional-username> }
The <public_key> string needs to match one of the keys given by the list function (does not need to match any currently-loaded certs). The "user" field is optional, and allows a connection with full admin privileges to revoke certs belonging to other users.
Note about current user/connection permissions level:
If the current user has full admin access, the "list_ssl_certs" API call will return the registered certificates for all users on the system - otherwise it will only return the certificates for the current user. Similarly, the "revoke_ssl_cert" may be used to remove certs registered to other users only if the current user/connection has full admin access - otherwise it may only be used to manage the current user's certificates.
Current Settings:
1) 5 auth attempts allowed before failover
2) If no communications for 10 minutes, the failover counter gets reset
3) On failover - the IP is placed on the server blacklist for 1 hour
Note: The blacklist system is connection independant, and uses the host IP for unique tracking/blocking.
Now the user's who login are divided up into "Full Access" users or not. This allows for additional restrictions in the backend subsystems to restrict certain types of operations to only the "full access" (root-permissioned) users.
The users are divided up like this:
1) The user must be in either the "wheel" or "operator" groups to get any access whatsoever (restricting automated services from connecting).
2) If the user is in the "wheel" group, they get full access to the server's capabilities
3) If the user is in the "operator" group instead, then they only get limited access to the server's capabilities.
While here, also allow password-less logins to the server if the client is connecting to a server on the same system (local access). User restrictions still apply.
Also setup the server to make it easier to extend for API/library support in the backend. All backend functionality can now be added to the new "WebBackend.cpp" file (and WebSocket.h file for headers).
