Progettazione del database: gestisci le autorizzazioni su più risorse applicative

Question

Progettazione del database: gestisci le autorizzazioni su più risorse applicative

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Panoramica

Un'applicazione Web centrale per supportare altre applicazioni Web (A) per l'utente e il relativo ruolo / gestione dei permessi. Le applicazioni (A) chiamano l'applicazione centrale tramite API per ottenere i ruoli / permessi dell'utente.

1) L'applicazione (A) può avere risorse.

2) Le risorse possono avere permessi.

3) L'utente può avere accesso a risorse / permessi.

L'amministratore dovrebbe poter creare risorse per un'applicazione, autorizzazioni per quella risorsa, assegnare l'accesso di una risorsa / autorizzazione a un utente e la risposta dovrebbe essere qualcosa di simile.

User
 - Resource
    - Permissions
 - Resource
    - Permissions

Scenario

L'amministrazione per un'applicazione (A) vuole creare risorse dire R1, R2 ma non necessariamente qualsiasi autorizzazione sotto di loro perché è sufficiente per lui se ottiene la risposta in questo modo.

 User
     - R1
     - R2

Approccio 1

Crea queste tabelle 1) Applicazione

2) Risorsa (FK come appID)

3) Permessi (FK come ID risorsa)

4) User_Permissions (FK come permissionID)

In questo caso poiché non ci sono permessi per una risorsa così la tabella User_Permission sarà vuota. Ma poi l'amministratore vuole dare accesso alle risorse, in modo che il sistema possa creare un'autorizzazione predefinita O l'amministratore deve creare un'autorizzazione predefinita ogni volta che crea una risorsa. Quindi inseriamo le autorizzazioni predefinite nella tabella User_Permissions e possiamo finalmente trovare le risorse corrispondenti e restituire la risposta seguente.

Utente - R1 - Permesso predefinito - R2 - Autorizzazione predefinita

Approccio 2

Crea queste tabelle 1) Applicazione

2) Risorsa (FK come appID)

3) Permessi (FK come ID risorsa)

4) User_Resources (FK come resourceID)

5) User_Permissions (FK come userResourceID)

In questo caso abbiamo la tabella aggiuntiva User_Resources che specifica le risorse a cui l'utente ha accesso e quindi le autorizzazioni su quella risorsa.

Hai bisogno di suggerire quale approccio preferire.

database database-design normalization

posta Pratik Garg 31.07.2015 - 16:22

fonte

3 risposte

Leggi altre domande sui tag database database-design normalization

Perché SortedDictionary non implementa IReadOnlyDictionary? perché l'aggiunta di un vertice in un grafico rappresentato utilizzando una matrice di adiacenza richiede O (| v | ^ 2) complessità temporale?

score 2 · Answer 1

Penso che il requisito n. 3: "Gli utenti possono avere accesso a risorse / permessi" è un po 'vago. Fino a quando non sarai più specifico nei tuoi requisiti, non sarà possibile rispondere. Ecco come puoi guardare i tuoi due scenari e prendere una decisione. Nello scenario n. 1 un utente può avere accesso a una risorsa solo disponendo di un'autorizzazione collegata a una risorsa specifica. Non è come avere un accesso indipendente.

Se c'è qualche motivo per le prestazioni, vuoi monitorare separatamente le risorse e gli ampli utente; le autorizzazioni, è possibile che l'accesso a una tabella funzioni meglio di dover costantemente aggiungere le autorizzazioni alla tabella delle risorse.

Inoltre, penso che sia necessaria una chiave esterna aggiuntiva nelle tabelle User_ per UserID. Sono le tipiche tabelle di link Molti-a-molti.

score 1 · Answer 2

Certamente non l'approccio 2, poiché richiederà un overhead aggiuntivo di mantenere User_Resources e User_Permissions in sincronizzazione. per es. una voce in User_Resources annullerebbe tutto in User_Permissions per una particolare risorsa.

Penso che la soluzione risieda nel definire i termini in modo più elaborato. Se penso in termini di OOP, non vedo come le autorizzazioni possano essere definite / possedute dal creatore di risorse. Invece ciò che può essere / deve essere definito dal creatore della risorsa sono le "Operazioni" che possono essere eseguite sulla risorsa, Se una risorsa non può essere gestita sulla sua non è affatto una risorsa, quindi sarà un buon progetto per renderla obbligatorio che ogni risorsa abbia alcune operazioni definite.

Quindi è possibile definire un'entità / tabella denominata Autorizzazioni (ID_utente, ID_operazione, Tipo) che definirà il tipo di accesso che un utente ha sulla risorsa.

Per es. Come Definitore risorse potrei definire Fan (risorsa) - > (Operazioni) TurnOn, TurnOff, setSpeed Quindi posso definire permessi come

userA turnOn READ userA turnOff WRITE userA setSpeed UPDATE

significa che userA può solo girare Off o cambiare la velocità della ventola, o controllare se la ventola è accesa ma quell'utente non può accendere la ventola.

Puoi avere anche i resourceId nella tabella per motivi di prestazioni, i miei suggerimenti erano più vicini al design.

score 0 · Answer 3

L'approccio n. 2 è decisamente sbagliato perché consente di inserire anomalie nell'inserimento.
Vorrei andare con l'approccio 1 ma con un miglioramento: se non hai ruoli, l'amministrazione sarà un incubo su cui hai bisogno di ruoli.
Con i ruoli non è necessario assegnare lo stesso insieme di autorizzazioni più e più volte a utenti diversi.
Il problema di assegnare a un utente permessi assoluti su una determinata risorsa non è più un problema anche perché avresti già creato un RUOLO "super utente" con tutte le autorizzazioni su quell'oggetto. Assegni semplicemente quel ruolo all'utente.

Unmodellopiùcompletodovrebbeconsentiredidefinireleseparazioniseparatellyeassociateallerisorseinmododanondovercrearelestesseautorizzazionipiùepiùvolteperlediverseapplicazioni/risorseconilrischiodiripetereleautorizzazionicondifferentiortografie(unlanormalizzazionedelleanomaliecercadievitare).QuindihaiunatabelladelleautorizzazionigeneralienellatabellaRESOURCE_PERMISSIONdefinisciqualipermessisonoadattiperqualirisorse.ROLElifarebbeloro.