In questo momento stiamo implementando un sistema di autorizzazioni basato sui ruoli (onestamente eccessivamente complesso) in cui gli utenti verranno assegnati ai ruoli e a quei ruoli verranno concesse le autorizzazioni su alcune combinazioni di risorse. Abbastanza tradizionale, e penso che sia abbastanza semplice implementare il database collegando una tabella di users con una tabella di roles collegata a una tabella di permissions , che hanno un riferimento al tipo di risorsa che sono un'autorizzazione per e una semplice maschera di bit che identifica le autorizzazioni CRUD che sono state concesse.
Detto questo, abbiamo coinvolto due casi limite:
- Innanzitutto, ci sono utenti amministratori che dispongono di autorizzazioni univoche che non possono essere concesse agli utenti. Alcune di queste sono caratteristiche specifiche che non si adattano perfettamente alle tabelle e alle risorse del database e sono specificamente disponibili solo per gli utenti amministratori
- In secondo luogo, poiché siamo un sistema multi-tenant, abbiamo un gruppo di utenti interni che possono accedere a qualsiasi database. Mentre gli utenti del locatario siedono tutti nello stesso database dei dati del titolare, questi supportano tutti gli utenti in un database separato; altrimenti agiscono come utenti amministratori, occasionalmente con autorizzazioni aggiuntive specificamente disponibili solo a loro (di nuovo)
Normalmente il livello di specificità richiesto per questi utenti mi fa desiderare di spostare i ruoli nel codice dell'applicazione, ma non posso farlo perché gli inquilini devono essere in grado di gestire e assegnare i propri ruoli, fino al creazione di nuovi amministratori. Ciò che si riduce a questo è che gli utenti probabilmente finiranno per avere una combinazione di ruoli e controllo degli accessi basato sugli attributi in atto: ruoli per la maggior parte degli utenti, ricerca di attributi per casi speciali. Quindi fondamentalmente ibridazione di ARO e controllo degli accessi basato sugli attributi.
La mia soluzione alternativa qui è quella di creare ruoli hardcoded nel database, potenzialmente riservando i primi ~ 10 o più ID nella mia tabella roles per ruoli "speciali" con comportamento hardcoded. Che si sente anche cattivo.
Quale approccio dovrei adottare? O meglio ancora, esiste un approccio alternativo a cui non avevo ancora pensato?