Autenticazione utente nell'API REST (progettazione basata sul dominio)

Question

Autenticazione utente nell'API REST (progettazione basata sul dominio)

#1 da (3 voti)

4

Utilizzo API REST come livello di presentazione di un progetto DDD. Per proteggere le chiamate API, sto utilizzando la sicurezza basata su token.

Sicurezza nelle API Web-Autenticazione di base e personalizzato basato su token Autorizzazione in API Web utilizzando i filtri azione .

Se un contesto di amministrazione degli utenti API è persistente da una API o BC diversa (a seconda della progettazione), sarebbe considerato come interrompere DDD se un BC effettivamente accede a una risorsa esterna (API di terze parti o altro BC in DDD) in ordine controllare le credenziali dell'utente?

design domain-driven-design design-patterns object-oriented-design

posta Dario Granich 29.04.2016 - 14:03

fonte

1 risposta

Leggi altre domande sui tag design domain-driven-design design-patterns object-oriented-design

Di quali argomenti di rendimento dovrei essere a conoscenza? [chiuso] Consigli per convertire un sito Web ASP.NET a più progetti su MVC (utilizzando VS2015)

score 3 · Accepted Answer

Oltre a quello che ha detto Alexander Langer, non ci sono solo buone ragioni per, ma politiche di sicurezza reali per andare ancora oltre e non possedere nemmeno alcun tipo di credenziali o token temporanei nella logica del tuo dominio.

In pratica (e mi scuso per non aver conosciuto DDD o il caso esatto):

la logica di dominio (BC, WebService, qualunque cosa) raramente deve davvero contenere le credenziali
- per la maggior parte delle attività, la logica può fare affidamento sul livello di protezione di cui sopra (ad esempio un proxy inverso bit smart che si affida reciprocamente in base alla sicurezza di trasporto client-server) per risolvere la maggior parte delle roba di sicurezza
- non esporre la parte commerciale al consumatore, mettila dietro la parte protetta
lascia che la logica si basi solo sul fatto che il livello di sicurezza gli ha fornito l'identificativo utente corretto e il set di identificatori di permesso rilevanti per il particolare dominio (BC)
- fidati del tuo livello di sicurezza (e degli esperti di sicurezza) che fanno funzionare bene la loro sicurezza
- non si fida del codice aziendale in cose di cui non è responsabile
- si aspettano i peggiori difetti di sicurezza dei tuoi programmatori, perché succede semplicemente
sarebbe "troppa informazione" perché una logica di dominio conosca le credenziali (anche in forma di token), non penso che sia necessaria la capacità del codice aziendale di impersonare l'utente "dappertutto".
- mirano a informazioni assolutamente minime, proprio ciò che è necessario per eseguire l'operazione.
- l'attività è business / domain, riguarda l'utente e il suo materiale. Non si tratta delle sue credenziali, sarebbe un dominio del livello di sicurezza.

Per immaginare le potenziali implicazioni di una decisione di sicurezza di questo tipo, considera il fatto, che una "informazione" memorizzata in un token / credenziale / id utente non è solo il contenuto binario dei dati, ma tutto raggiungibile da questo dati che utilizzano le possibilità odierne o future (cracking degli hash, scansione delle altre parti del sistema utilizzando il token da parte di un utente malintenzionato, ecc.)