Nms-authentication
Notes on Authentication Design
So far no attempt at building an auth system has been implemented 06-06-23. ( old info :) )
- Right now we have database authentication working with JWT setting the lifetime of the login.
- The GUI stores the token and sends it with the API calls to validate authentication, and then checks access level if that is defined on the API side.
- The API validates the token validity first, then checks if it is defined user levels. Currently this is a string, but will be replaced with integer values as default with strings as fallback. This is going to allow regular user access as well as oddball access such as kisok modes..
- Login, account creation, password reset, and admin controls all functional in UI. API's are functionally complete
Logic (planned or partly implemented)
JWT (complete)
String user level (complete) IE: if the API filter is an "admin" and the token access level has "admin" in the access list, you have admin access to pages that are looking for.
Integer access (todo) Change the concept of access levels to numbers. User will have to have a number equal or greater than the cutoff to get an API response.
Work todo
Redis auth cache. This needs to be added so when a user is deleted they immediately loose access even if the JWT is not expired. Otherwise the user will only loose access once the token has expired.
Slim4 has the concept of middleware which appears to be the best spot for auth to live. As this is on the API side, this should work pretty well. The API and redis will decide who gets to see or do stuff, NEVER allow overrides on the UI side.
Currently the UI has ZERO passwords defined for it at all. There is a STUB of code in place to support the GUI being "blessed" for even talking to the API server, but likely this is unneeded and an additional complexity that 99% of use cases would not even think of needing.
Plans:
- Redis cache of authed users (if no exist, no access even with valid tokens)
- guid for apis and automation (not written in stone if someone wants something different)
- guids salted for transfer (V2 if ever)
- planned auth types: database, LDAP, AD?, something oddball?
- stub out TFA support
- stub out SAML possibility
- completely unauth will only go to login no matter what is called. No bypasses for any reason. (complete on UI)
- Think about fail2ban even for secure environments (likely possibility as a lockout on auth?)