Valutazione del codice dinamico in Java - Clever o Sloppy?

Sto cercando di creare un framework ACL flessibile in Java per la mia applicazione.

Molti framework ACL sono basati su una whitelist di regole, in cui una regola ha la forma di proprietario: azione: risorsa . Per esempio,

• "JOHN può VISUALIZZARE la risorsa FOOBAR-1"
• "MARY può VISUALIZZARE la risorsa FOOBAR-1"
• "MARY può MODIFICARE la risorsa FOOBAR-1"

Questo è interessante perché le regole possono essere facilmente serializzate / persistenti in un database. Ma la mia applicazione ha una logica aziendale complessa. Per esempio,

• "Tutti gli utenti del dipartimento 1 con oltre 5 anni di anzianità possono VISUALIZZARE la risorsa FOOBAR-1, altrimenti non autorizzato"
• "Tutti gli utenti del dipartimento 2, se la data è successiva al 15/03/2016, possono VISUALIZZARE la risorsa FOOBAR-2, altrimenti non autorizzata"

A prima vista, sarebbe un incubo escogitare uno schema di database in grado di gestire regole infinitamente complesse come queste. Pertanto, sembra che avrei bisogno di "inserirli" nell'applicazione compilata, valutarli per ciascun utente e quindi produrre il proprietario: azione: regole delle risorse a seguito della valutazione. Voglio evitare di inserire la logica nell'applicazione compilata.

Quindi, stavo pensando di rappresentare una regola sotto forma di predicato : azione: risorsa , dove il predicato è un'espressione booleana che determina se un utente è autorizzato. Il predicato sarebbe una stringa di un'espressione JavaScript che potrebbe essere valutata dal motore Rhino di Java. Per esempio,

• return user.getDept() == 1 && user.seniority > 5;

In tal modo, i predicati potrebbero essere facilmente mantenuti nel database.

È intelligente ? Questo è sciatto ? È ingannevole ? È troppo ingegnerizzato ? È sicuro (a quanto pare, Java può eseguire il sandbox del motore di Rhino).

Il piping di dati dinamici in un interprete del linguaggio di implementazione è di solito una cattiva idea, poiché aumenta il potenziale di corruzione dei dati in un potenziale di acquisizione di applicazioni dannose. In altre parole, stai facendo del tuo meglio per creare una vulnerabilità nell'iniezione di codice .

Il tuo problema può essere risolto meglio da un motore di regole o forse da un linguaggio specifico del dominio (DSL) . Guarda quei concetti, non è necessario reinventare la ruota.

L'ho fatto e ti consiglio di non farlo.

Quello che ho fatto è stato scrivere tutta la logica aziendale in Lua e archiviare lo script Lua in un database. All'avvio della mia applicazione si caricava ed eseguiva lo script. In questo modo ho potuto aggiornare la logica aziendale della mia applicazione senza distribuire un nuovo binario.

Ho sempre scoperto che avevo sempre bisogno di aggiornare il file binario quando apportavo modifiche. Alcune modifiche sono state apportate allo script Lua, ma invariabilmente avrei avuto un elenco di modifiche che dovevano essere apportate, e quindi ho quasi sempre dovuto apportare alcune modifiche al file binario e alcune modifiche allo script Lua. La mia immaginazione di poter evitare di distribuire i binari tutto il tempo semplicemente non ha funzionato.

Quello che ho trovato molto più utile è stato facilitare la distribuzione dei file binari. La mia applicazione verifica automaticamente la disponibilità di aggiornamenti all'avvio, i download e installa eventuali aggiornamenti. I miei utenti sono quindi sempre sugli ultimi binari che ho spinto. Non c'è quasi alcuna differenza tra una modifica nel binario e una modifica negli script. Se lo facessi di nuovo, farei ancora più sforzi per rendere l'aggiornamento senza soluzione di continuità.

Non vorrei che il database contenga codice. Ma puoi fare qualcosa di simile facendo in modo che il database contenga nomi di funzioni e quindi usi la reflection per chiamarli. Quando aggiungi una nuova condizione, devi aggiungerla al tuo codice e al tuo database, ma puoi combinare condizioni e parametri che gli vengono passati per creare valutazioni piuttosto complesse.

In altre parole, se si dispone di dipartimenti numerati, sarebbe facile disporre di un controllo UserDepartmentIs e di TodayIsAfter, quindi combinarli per avere un Department = 2 e Today> 15/03/2016. Se vuoi quindi avere un controllo TodayIsBefore in modo da poter terminare l'autorizzazione, devi scrivere la funzione TodayIsBefore.

Non l'ho fatto per le autorizzazioni utente, ma per la convalida dei dati, ma dovrebbe funzionare.

XACML è la soluzione che stai davvero cercando. È un tipo di motore delle regole focalizzato solo sul controllo degli accessi. XACML, uno standard definito da OASIS, definisce tre parti:

• un'architettura
• un linguaggio politico (che è davvero quello che vuoi)
• uno schema di richiesta / risposta (come si richiede una decisione di autorizzazione).

L'architettura è la seguente:

• il Policy Decision Point (PDP) è la parte centrale dell'architettura. È il componente che valuta le richieste di autorizzazione in entrata rispetto a una serie nota di criteri
• il Policy Enforcement Point (PEP) è il pezzo di codice che protegge la tua applicazione / API / servizio. Il PEP intercetta la richiesta commerciale, crea una richiesta di autorizzazione XACML, la invia al PDP, riceve una risposta e applica la decisione all'interno della risposta.
• il Policy Information Point (PIP) è il componente che può collegare il PDP a fonti esterne di dati, ad esempio un LDAP, un database o un servizio web. Il PIP è utile quando il PEP invia una richiesta, ad esempio "Alice può visualizzare il documento n. 12?" e il PDP ha una politica che richiede l'età dell'utente. Il PDP chiederà al PIP "dammi l'età di Alice" e sarà quindi in grado di elaborare le politiche.
• il Policy Administration Point (PAP) è il luogo in cui è possibile gestire l'intera soluzione XACML (definizione degli attributi, scrittura delle politiche e configurazione del PDP).

Ecco come appare il tuo primo caso d'uso:

/*
 * All users in department 1 with over 5 years of seniority can VIEW resource FOOBAR-1, else not authorized
 * 
 */
 policy departmentOne{
    target clause department == 1
    apply firstApplicable
    /**
     * All users in department 1 with over 5 years of seniority can VIEW resource FOOBAR-1, else not authorized
     */
    rule allowFooBar1{
        target clause resourceId=="FOOBAR-1" and seniority>=5 and actionId=="VIEW"
        permit
    }
    rule denyOtherAccess{
        deny
    }

 }

Il tuo secondo caso d'uso sarebbe:

 /*
  * "All users in department 2, if the date is after 03/15/2016, can VIEW resource FOOBAR-2, else not authorized"
  *  
  */
  policy departmentTwo{
    target clause department == 1
    apply firstApplicable
    rule allowFooBar2{
        target clause resourceId=="FOOBAR-1" and seniority>=5 and currentDate>"2016/03/15":date and actionId=="VIEW"
        permit
    }
    rule denyOtherAccess{
        deny
    }
  }

È possibile combinare entrambi i casi d'uso in un singolo criterio utilizzando i riferimenti:

  policyset global{
    apply firstApplicable
    departmentOne
    departmentTwo
  }

E hai finito!

Puoi leggere di più su XACML e ALFA da:

• il blog degli sviluppatori XACML
• il canale YouTube dello sviluppatore XACML

Quello che vuoi davvero qui è XACML . Praticamente ti dà esattamente quello che vuoi. Non devi necessariamente implementare l'intera architettura con tutti i ruoli completamente separati ... se hai solo una singola applicazione, probabilmente puoi cavartela con l'integrazione di PDP e PEP nella tua app con balana e il PIP è qualunque il tuo database utenti esistente è.

Ora, ovunque nella tua app devi autorizzare qualcosa, crei una richiesta XACML che ha l'utente, l'azione e il contesto, e il motore XACML prenderà la decisione in base ai file delle politiche XACML che hai scritto. Questi file di criteri possono essere conservati nel database o nel filesystem o ovunque si desideri mantenere la configurazione. Axiomatics ha una bella alternativa alla rappresentazione XML XACML chiamata ALFA che è un po 'più facile da leggere rispetto all'XML grezzo e un plug-in Eclipse per generare XML XACML dalle politiche ALFA.

Lo abbiamo fatto presso la mia attuale azienda e siamo molto contenti dei risultati.

Le nostre espressioni sono scritte in js e le usiamo anche per limitare i risultati che gli utenti possono ottenere interrogando ElasticSearch.

Il trucco è assicurarsi che siano disponibili informazioni sufficienti per prendere la decisione, in modo che tu possa davvero scrivere tutto ciò che vuoi senza modifiche al codice, ma allo stesso tempo mantenerlo veloce.

Non siamo veramente preoccupati per gli attacchi di iniezione di codice, poiché le autorizzazioni sono scritte da coloro che non hanno bisogno di attaccare il sistema. E lo stesso vale per gli attacchi DOS come while(true)nell'esempio. Gli amministratori del sistema non hanno bisogno di farlo, potrebbero semplicemente rimuovere le autorizzazioni di tutti ...

Aggiornare:

Qualcosa come XACML sembra essere migliore come punto centrale di gestione delle autorizzazioni per un'organizzazione. Il nostro caso d'uso è leggermente diverso in quanto i nostri clienti in genere non hanno un reparto IT per eseguire tutto ciò. Avevamo bisogno di qualcosa di autonomo, ma abbiamo cercato di preservare la massima flessibilità possibile.