Fornire un sistema di autorizzazione agnostico

2

Sto provando a progettare una piccola piattaforma web che ospiterà diverse "applicazioni", con un pool di utenti comune. La mia riflessione è ora focalizzata sul sistema di autorizzazione.

Definisco un'applicazione come un'interfaccia che consente agli utenti di eseguire CRUD e più operazioni personalizzate su un insieme di risorse. Io tendo a preferire modellare un'applicazione come una raccolta di servizi web RESTful da consumare da vari front-end.

Mi piacerebbe davvero generalizzare il sistema di autorizzazione e renderlo agnostico alle applicazioni; Sto pensando di implementarlo come un servizio web, sfruttando database di documenti non strutturati.

Supponendo che:

  • Un servizio di gestione utenti e gruppi è disponibile per lo sviluppatore dell'applicazione;
  • L'ambito di qualsiasi applicazione sarebbe limitato per eseguire CRUD e più operazioni personalizzate sulle risorse, come indicato in precedenza;

La mia idea è di fornire agli sviluppatori l'accesso in lettura / scrittura a una struttura come questa:

[{
    "Application":"Application1",
    "Ressource":"ResourceType1",
    "id":"123",
    "read":{
        "whitelist_group_ids":[ 2 ],
        "whitelist_user_ids":[ 1 ],
        "blacklist_users_ids":[ 2 ]
    },
    "CustomOperation1":{
        "whitelist_group_ids":[ * ],
        "whitelist_user_ids":[ 1, 2 ],
        "blacklist_users_ids":[ 3 ]
    }
},{
    "Application":"Application1",
    "Ressource":"ResourceType2",
    "id":"13",
    "read":{
        "whitelist_group_ids":[ * ],
        "whitelist_user_ids":[ 1 ],
        "blacklist_users_ids":[ 2 ]
    },
    "CustomOperation2":{
        "whitelist_group_ids":[ 2 ],
        "whitelist_user_ids":[ 1, 2 ],
        "blacklist_users_ids":[ 3 ]
    }
}]

Saranno quindi in grado di archiviare, controllare e aggiornare le loro restrizioni di accesso su richiesta;

Quali sarebbero i difetti di un simile approccio? Esiste una strategia standard per raggiungere qualcosa di simile a quello che ho descritto?

    
posta zrz 20.12.2013 - 13:39
fonte

1 risposta

2

Esamina Apache Shiro . Andando con una soluzione in scatola è di solito una mossa migliore di partire da zero. Hanno una soluzione per il tuo problema che, posso attestare, è molto facile da implementare. Può collegarsi automaticamente alla sessione dell'utente e fornire autenticazione e autorizzazione a vari livelli.

La parte più potente della nostra implementazione consisteva in una gerarchia di gruppi in modo tale che ciascun gruppo ereditasse le autorizzazioni di base dai suoi genitori, quindi eseguisse l'override o aggiungesse alle autorizzazioni. Abbiamo deciso di utilizzare true / false per tutte le nostre autorizzazioni in modo che ogni autorizzazione si riducesse a una risposta sì / no. Abbiamo evitato i negativi nei nomi delle autorizzazioni in modo che il codice potesse essere letto in modo più pulito.

Per darti un'idea, ecco alcuni gruppi e le loro autorizzazioni:

WebUser
     advanced_tools: false
     admin_tools:false
     tree_navigation:true
     enhanced_panel:false
     search_limit_to_25:true
PaidUser
     advanced_tools:true
     tree_nagivation:false
     search_limit_to_25:false
TrialUser
     advanced_tools:true
AdminUser
     tree_navigation:false
     admin_tools:true

Un utente amministratore era anche un utente a pagamento (come memorizzato nel database), in modo che prima applicasse tutte le autorizzazioni degli utenti Web, quindi i valori utente a pagamento sarebbero stati sovrascritti e, infine, l'utente amministratore sarebbe stato applicato. Abbiamo anche ricevuto autorizzazioni assegnate a singoli utenti, ma è rimasto inutilizzato.

Nel codice sorgente lato server, useremmo Shiro per vedere se un utente era autorizzato a fare tree_navigation o admin_tools prima di includere il codice. Ad ogni chiamata al server per eseguire un'azione, abbiamo verificato che l'utente era autorizzato a fare ciò che stavano facendo. Il trucco era di non fidarsi di nessun dato di sessione: dovremmo ricontrollare tutte le autorizzazioni su ogni chiamata al server. Se la sessione è scaduta, o l'utente non ha effettuato l'accesso tramite Shiro, il controllo dell'autorizzazione non avrebbe avuto esito positivo e avremmo protetto i nostri dati / informazioni.

Il fatto che questo fosse tutto nel database significava che gli utenti amministratori potevano modificare o modificare le autorizzazioni al volo e quindi attivare un aggiornamento della cache per il modulo utente sul lato server.

    
risposta data 20.12.2013 - 14:10
fonte