Dove dovrebbe essere autorizzata l'esecuzione di live in un'applicazione utilizzando gateway API / lambda e openid?

Question

Dove dovrebbe essere autorizzata l'esecuzione di live in un'applicazione utilizzando gateway API / lambda e openid?

#1 da (1 voti)
#2 da (-1 voti)

4

Per un'applicazione che:

Utilizzerà Google OpenID per la creazione di account e amp; autorizzazione
- Ho intenzione di consentire a qualsiasi utente di "creare un account", motivo per cui desidero utilizzare Google per questo
Gateway API AWS (per instradare le richieste)
Funzioni lambda di AWS (per elaborare le richieste)

dove dovrebbe autorizzazione vivere? L'autenticazione è facile, perché è gestita da OpenID stesso. Ma immagino che voglio essere in grado di avere più tipi di utenti - per questo esempio, amministratore e utente regolare. Alcune delle mie chiamate gateway API saranno protette dalla pagina "admin".

Se avessi utenti AWS, potrei utilizzare l'intero modulo IAM di AWS per associare gli utenti a gruppi / ruoli / etc e definire l'autorizzazione in questo modo.

Tuttavia, non lo faccio - ad AWS tutti i miei utenti sono gli stessi (OpenID collega gli utenti).

Potrei creare il mio servizio di autorizzazione per gestire le autorizzazioni basate su alcuni metadati di Google, ma sembra che questa sia una situazione abbastanza comune in cui dovrebbe esserci una buona soluzione, ma devo ancora trovarla.

Devo semplicemente avere un tavolo in un RDS AWS che tenga traccia di questo? Sembra un po 'goffo dover scrivere in modo efficace il mio servizio di autorizzazione se utilizzo l'OpenID di Google.

authentication authorization aws

posta enderland 26.06.2017 - 22:34

fonte

2 risposte

Leggi altre domande sui tag authentication authorization aws

Diversi tipi di eccezioni controllate - Garantire di lanciare solo X Event Event Sourcing e una piattaforma di gestione API si influenzano a vicenda?

score 1 · Answer 1

Quindi, per cominciare, capisci che in realtà non hai un meccanismo di autorizzazione in base a ciò che hai descritto. Hai un meccanismo di autenticazione (definendo chi è qualcuno) e al momento, tutte le persone sono autorizzate a fare qualsiasi cosa, perché non hai una logica che dice il contrario.

Per rispondere alla tua domanda, il gateway API di AWS include opzioni di autorizzazione e, a mio parere, è il posto giusto per impostare la tua autorizzazione. Uno (come accennato) utilizzerà le credenziali di AWAM IAM, ma consentono anche per gli autori di autorizzazioni personalizzati .

Quello che dovresti fare è costruire un Lambda che il Gateway colpisce ogni volta che qualcuno chiede percorsi protetti e convalida che la persona abbia i permessi corretti. Probabilmente si tratterà di un controllo su un record del database di qualche tipo che associa un'identità OpenID a un ruolo di amministratore (o di altro tipo).

score -1 · Answer 2

La posizione corretta all'interno di un sistema orientato agli oggetti è proteggere i metodi degli oggetti di dominio tramite un proxy di sicurezza o un meccanismo simile (AOP). Ciò garantisce che la sicurezza sia applicata all'interno di qualsiasi caso in cui gli oggetti del dominio partecipino.

Esistono molte più soluzioni pragmatiche per i progetti più piccoli. È possibile proteggere una facciata o gestire la sicurezza all'interno dei vostri casi d'uso. Ma fa attenzione. Se il tuo sistema cresce, tali soluzioni produrranno controlli di sicurezza ridondanti quando utilizzerai i tuoi oggetti di dominio in diversi casi d'uso.

Dopotutto, OpenId non è un meccanismo di autorizzazione. È un meccanismo di autenticazione. Risponde alla domanda CHI sei ma non a COSA ti è permesso fare. Accanto a questa autorizzazione dovrebbe essere specifica dell'applicazione. A causa del meccanismo di autenticazione Single Sign On sono altamente specifici per la tecnologia.

Quindi l'autorizzazione dovrebbe avvenire PRIMA o DOPO che la logica aziendale sia eseguita. PRIMA di controllare se l'uso è autorizzato a eseguire un'azione. Questo si riferisce sempre alle operazioni CUD. DOPO che puoi filtrare un Set / Elenco di oggetti di dominio che l'utente è autorizzato a vedere. Questo si riferisce a R-Operations.