Chubbard at 19:31, 8 February 2024

2024-02-08T19:31:56Z

← Older revision		Revision as of 12:31, 8 February 2024
Line 1:		Line 1:
	=== Notes on Authentication Design ===		=== Notes on Authentication Design ===
	So far no attempt at building an auth system has been implemented 06-06-23.		So far no attempt at building an auth system has been implemented 06-06-23. ( old info :) )

	~~Slim4 has~~ the ~~concept~~ of ~~middleware which appears to be where they want 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, do not allow overrides on the UI side~~.		* Right now we have database authentication working with JWT setting the lifetime of the login.

	Plans:		* 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.
	* Redis cache of authed users
	* guid for apis and automation		* 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..
	* guids salted for transfer
	* planned auth types: ~~local db~~, LDAP, AD?, something oddball?		* 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 TFA support
	* stub out SAML possibility		* stub out SAML possibility
	* completely unauth will only go to login no matter what is called. No bypasses for any reason.		* 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		* Think about fail2ban even for secure environments (likely possibility as a lockout on auth?)
	* redis auth expiration based on auth ~~type and admin permissions IE admin can hard set an expiration for users~~

Chubbard: Created page with "=== Notes on Authentication Design === So far no attempt at building an auth system has been implemented 06-06-23. Slim4 has the concept of middleware which appears to be where they want 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, do not allow overrides on the UI side. Plans: * Redis cache of authed users * guid for apis and automation * guids salted for transfer * planned auth typ..."

2023-06-06T14:20:04Z

Created page with "=== Notes on Authentication Design === So far no attempt at building an auth system has been implemented 06-06-23. Slim4 has the concept of middleware which appears to be where they want 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, do not allow overrides on the UI side. Plans: * Redis cache of authed users * guid for apis and automation * guids salted for transfer * planned auth typ..."

New page

=== Notes on Authentication Design ===
So far no attempt at building an auth system has been implemented 06-06-23.

Slim4 has the concept of middleware which appears to be where they want 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, do not allow overrides on the UI side.

Plans:
* Redis cache of authed users
* guid for apis and automation
* guids salted for transfer
* planned auth types: local db, 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.
* Think about fail2ban even for secure environments
* redis auth expiration based on auth type and admin permissions IE admin can hard set an expiration for users

[[Category:NMS]]

Nms-authentication - Revision history

Chubbard at 19:31, 8 February 2024