Spring Security e ABAC (controllo dell'accesso basato sugli attributi)

Question

Abbiamo un'app business di medie dimensioni e usiamo i ruoli e le autorizzazioni Spring Security (RBAC) pesantemente con un grande kludge per attivare e disattivare i ruoli per determinati casi più le regole nascoste in SpEL all'interno dei tag @PreAuthorize.

Penso che cosa abbiamo effettivamente implementato (senza sapere che è ABAC). XACML sembra molto complicato e gonfio quindi non sono appassionato di qui la risposta:

How to change Spring Security roles by context?

Qualcuno ha fatto un'implementazione ABAC peso leggero senza XACML? Spero che questo ci consenta di separare le preoccupazioni dal momento che gli oggetti del dominio fanno semplicemente @PreAuthorize (WRITE) ecc. E la nostra politica di autorizzazione sarebbe disaccoppiata da esso.

Da quello che ho letto il principio di base di ABAC è molto semplice. Hai un'azione (molto simile a un permesso) e un meccanismo da risolvere se l'attuale Principal ha quell'autorizzazione su un determinato Soggetto.

Sono a conoscenza di AccessDecisionVoter che è approssimativamente il giusto tipo di interfaccia, ma non penso che fosse destinato al voto sulle autorizzazioni. Tuttavia, l'implementazione della nostra politica di autorizzazione con istanze di qualcosa del genere sembra molto interessante.

Ci scusiamo per la domanda sconclusionata! Fondamentalmente sono interessante in ABAC ma vorrei evitare la produzione casalinga ma preoccupato di cosa XACML sia un jumbo jet quando abbiamo bisogno di un Cessna.

Answer 1

Sembra che ci sia due cose si sono intesi per:

1. autorizzazione esteriorizzato, in cui si desidera spostare le politiche di controllo di accesso di codice (o almeno in un posto centrale nel codice e non dispersi attraverso il codice di primavera) di autorizzazione basato
2. attributo, in cui si desidera utilizzare gli attributi più ricchi di ruoli e autorizzazioni

io non sono molto sicuro di (2) da quello che dici che vuoi fare, l'azione " e un meccanismo da risolvere se il cu il principale ha il permesso ", è ancora, nei miei libri, RBAC. Avete altre condizioni sulle quali basare le decisioni di concessione di accesso? Posizione dell'utente, ora del giorno, valore di determinati dati in un database, proprietà della risorsa su cui si agisce ecc.? Se è così, andiamo nel mondo ABAC. Ad ogni modo, direi che RBAC è un sottoinsieme di ABAC poiché un ruolo è solo un attributo.

Ora, come per (1), lo schema generale dovrebbe innanzitutto centralizzare il motore di autorizzazione e utilizzare le annotazioni Spring per chiamare questo authz. motore per le decisioni di accesso. Hai due scelte:

• authz incorporato. engine: dove una libreria implementa il motore e viene chiamata dal codice proprio come una funzione Java. Potrebbe essere un motore XACML o potrebbe essere la tua implementazione RBAC/ABAC
• come servizio di rete: dove un servizio (micro) basato sulla rete risponde alle domande sulle decisioni di controllo degli accessi. Potrebbe essere un motore XACML o potrebbe essere la tua implementazione RBAC/ABAC

Al fine di ottenere il codice basato su Spring per chiamare questo authz. motore, un approccio sarebbe quello di scrivere il proprio elettore di sicurezza di primavera.Un altro modo, che ho trovato molto più semplice, sarebbe quello di scrivere le espressioni basate sul linguaggio di espressione di primavera che è possibile chiamare con l'esistente @PreAutorize, @PostAuthorize, @PreFilter e @PostFiler, sec: autorizzare i tag e anche da intercettare-url condizioni.

Questo è quello che ho usato quando ho lavorato sul nostro Spring Security XACML PEP SDK. L'approccio dovrebbe funzionare egregiamente anche se si decide di non utilizzare XACML per i criteri decisionali di accesso o la comunicazione richiesta/risposta.