Progettazione del servizio di autenticazione e autorizzazione micro

2

Sfondo:

Ci sono tre diverse applicazioni A , B e C e condividono tutti gli stessi dettagli utente, ma ho dovuto implementare l'autenticazione in ciascuno di essi che era duplicazione degli sforzi.

Dopo alcune ricerche ho deciso di passare al servizio di micro-service e ho implementato un servizio di autenticazione. Il servizio memorizza il secret per ogni app e prepara un token JWT quando l'utente tenta di accedere all'app specificata. Funziona bene come previsto.

attuale:

Ora è necessario disporre di ruoli e autorizzazioni per ogni applicazione e trovo un modo per implementarlo senza creare molto accoppiamento. Ho alcune domande riguardanti le mie attuali situazioni:

Domande:

  1. Devo aggiungere login di autorizzazione nello stesso servizio o creare un altro servizio con roles e permission tabelle in esso.
  2. Il risultato finale sarà l'invio di un token JWT che conterrà payload che definisce i dettagli e l'autorizzazione dell'utente, ad esempio:

    {
      uid: 1,
      name: '...',
      email: '...'
      permissions: [{
        'edit': ['post', 'user'],
        'delete': ['post'],
        'read': ['post', 'user'],
        ...
      }]
    }
    

Sulla carta questa struttura mi sembra buona. Risparmierà le chiamate di rete aggiuntive dal lato client. Ma è abbastanza sicuro e affidabile?

PS: non ho abbastanza esperienza nella creazione di applicazioni reali, ma spero di andare nella giusta direzione.

    
posta CodeYogi 02.05.2018 - 17:03
fonte

1 risposta

1

Dovresti assolutamente esternalizzare la tua autorizzazione. In effetti esiste persino un paradigma chiamato gestione delle autorizzazioni esterne .

In Gestione delle autorizzazioni esterne, scegli di disaccoppiare la tua logica di autorizzazione dalla logica di business della tua app. Lo fai per una moltitudine di motivi:

  • Manutenzione
  • visibilità e auditabilità: è più facile capire le politiche che comprendere il codice.
  • estensibilità (a prova di futuro): con EAM, non è necessario riscrivere l'app se i requisiti di autorizzazione cambiano.
  • riutilizzo: puoi applicare la stessa logica di autorizzazione su più tecnologie e livelli (dalle API ai microservizi agli ESB ai database)
  • facilità e tempo di sviluppo: è più facile scrivere le politiche che scrivere codice per implementare requisiti di autorizzazione che a volte possono essere complessi

La gestione delle autorizzazioni esterne è disponibile in diverse forme. Alcuni framework contengono strumenti, ad es. Spring Security o autorizzazione basata su attestazioni Microsoft. Se desideri un approccio neutro rispetto alla tecnologia, consulta ABAC ( controllo dell'accesso basato sull'attributo ) e XACML , l'implementazione di ABAC.

L'architettura XACML definisce un PEP che si integrerà con / davanti al tuo microservice e un PDP che elaborerà le richieste di autorizzazione rispetto a una serie di politiche prestabilite.

Dai un'occhiata al diagramma dell'architettura per i dettagli

    
risposta data 04.05.2018 - 00:59
fonte