Access management per il gateway

Progetti IoGateway
#1

ciao a tutti/e

riflettendo sullo sviluppo del gateway ho pensato che ci sia bisogno di un meccanismo di autenticazione e autorizzazione se vogliamo che sia integrabile nelle infrastrutture degli enti PA.
In buona sostanza le funzionalità del gateway dovranno essere utilizzate da due categorie di utenti:

  1. utilizzatore
  2. amministratore
    L’utilizzatore e’ la persona che dovra’ avviare gli importer, importare i messaggi , scheduler etc.
    L’amministratore e’ colui il quale sarà’ responsabile della configurazione degli importer, del monitoring etc.

Per inserire queste funzionalità ci sono diversi modi:

  1. Inserire la gestione degli account e delle autorizzazioni all’interno del codice del gateway. Si può’ fare ma secondo me lo sforzo di codifica e’ veramente pesante
  2. Inserire nell’architettura di io-gateway un access manager con un web gate. Questo sposterebbe tutte le funzionalità di autenticazione e di autorizzazione sullo strumento di access management. OpenAm per esempio potrebbe essere un opensource che ha anche un LDAP dove possiamo gestire utenti e gruppi. Bisogna verificare come utilizzarlo con le action di open whisk soprattutto sulle autorizzazioni. Nel caso l’ente PA abbia un suo access manager ed e’ in grado di comunicare in SAML2 allora si potrebbe anche federare.
  3. Predisporre io-gateway ad essere integrato con uno strumento di access management che potrà’ essere diverso a seconda di quello utilizzato dall’ente. Noi potremmo testarlo con un OpenAM per esempio. La cosa più’ semplice e’ prevedere che user e gruppo di appartenenza vengano passati in header http su tutte le chiamate all’io-gateway.

Al momento non ho valutato tutti gli impatti che potrebbero avere soprattutto i punti 2) e 3) perché’ non mi e’ ancora chiara tutta l’architettura dell’IO-Gateway. Per quello che ho capito sarà basato sulla stessa architettura di IOSDK e al momento ho solo una conoscenza ‘vaga’ di come funzionano gli importer.

Pensate che la cosa sia fattibile ?

Ciao
Giovanni

#2

L’idea non mi dispiace, anche perchè di aggiungere una “autenticazione” ci è stato richiesto più volte e fa parte degli obiettivi del progetto Io-Gateway

A “naso” lo metterei davanti a openwhisk anche perchè openwhisk fornisce il backed ma il front-end è servito da traefik che è embeddato nella immagine di openwhisk e voglio tirar fuori e servire da una altra immagine. Ma non ho idea di quale usare.

Mi spaventa un po’ dover usare ANCHE ldap!!! Proprio non si può evitare o renderla opzionale? Non si può usare redis per le informazioni usate e ridurre il tutto a un solo front-end che “protegge le risorse”?

#3

per l’immagine che vuoi tirar fuori da open whisk basta un apache 2.4 dove poter installare il gate per OpenAM.
L’ldap non ti deve spaventare. Se non lo usi devi codificare tutte le funzionalità per gestire le password. Comunque OpenAM ha un opendj ldap embedded. Esiste un docker con tutto pronto: https://hub.docker.com/r/openidentityplatform/openam.
E, ti prego , anche basta con redis general purpose database :wink:

#4

Smetterò di proporre redis quando mi proporrai una alternatriva che funziona anche scalabile in cloud. E NO, mysql/postgresql non lo fanno, e i vari couchroachdb… prova un po’ a misurare che prestazioni hanno quando vanno distribuiti e vedrai che redis ti sembrerà il paradiso.

#5

Dai Michele, lo sai anche tu che redis puo’ essere usato solo quando i dati sono “pochi”, non strutturati e con bassa frequenza di lettura/scrittura. Oggi si preferiscono strutture miste per memorizzare i dati. Puoi avere redis per i dati di configurazione , un relazionale per lookup table molto onerose in termini di righe, timeseries database per i dati dei sensori e cosi’ via. Pensare di mettere tutto dentro redis e’ abbastanza utopico.

#6

Redis è li per essere una “cache” e l’IO-SDK v1 è stato pensato per avere dati transienti, infatti volutamente NON li salvo sul disco. Il piano di IO-SDK era “aiutare” l’import, non di automatizzarlo completamente

Sono abbastanza d’accordo che con il gateway dovremmo pensare a una persistenza “long term”, e sono ben disponibile a valutare alternative.

Non trovo però convincenti le tue affermazioni.

" lo sai anche tu che redis puo’ essere usato solo quando i dati sono “pochi”, non strutturati e con bassa frequenza di lettura/scrittura."

No non lo so, anzi so diversamente. Porta qualche dato a riprova, io ne ho altri, per esempio questo:

Users of redis:

Twitter.
GitHub.
Weibo.
Pinterest.
Snapchat.
Craigslist.
Digg.
StackOverflow.

Fonte: google.

“Oggi si preferiscono strutture miste per memorizzare i dati.”

Questo “si preferiscono” mi suona molto generico, magari per un “cliente” poco competente può funzionare, con me no. Chi li preferisce e perchè?

“Pensare di mettere tutto dentro redis e’ abbastanza utopico.”

Conclusione che non condivido. Ma ripeto non escludo il cambiamento di storage.

Ma perchè accada occorre anche rimboccarsi le maniche.

Se riesci a mandarmi una Pull Requests che sostituisce il database la accetto volentirei. Bada che è parecchio lavoro. Come minimo devi:

  • cambiare il launcher per deployare il tuo database
  • cambiare le azioni che lo usano per usare il tuo database
  • assicurarti che i test esistenti non vengano rotti ed eventulamente aggiungerne di nuovi

Per inciso @franztt ha fatto esattamente questo per la sua patch dello scheduler. Infatti la abbiamo messa nel gateway e sto cercando di integrarla con il resto.

Infine per quanto riguarda ME al momento ho come priorità multi user, importer binari e multi importer, non sono al momento interessato anche a cambiare lo storage.

#7

michele, le aziende che hai citato usano “anche” redis. Voglio vedere se Pinterest memorizza tutte le immagini dentro redis. Dai , lo sai che non e’ possibile. Git hub usa un object store, Twitter utilizza database, hadoop etc. “e” redis.
E questo come discorso generale.
Per IOSDK, e quindi per il gateway, io non ho nessuna preclusione ad usare redis per memorizzare i messaggi. Anche perche’ in effetti ogni messaggio pesa poco in termini di storage e l’associazione chiave(Codice Fiscale) - valore (json del messaggio) puo’ funzionare. Il problema sorge quando dovremo trattare migliaia se non milioni di messaggi di servizi diversi. La chiave codice fiscale non bastera’ piu’. Dobbiamo pensare ad una chiave codfis-servizio altrimenti avremmo dei duplicati. Allora il discorso si fa un po’ piu’ complicato. Anche nella gestione degli errori (messaggi non inviati, etc.). Con un db strutturato queste cose le gestisci, IMHO, con redis diventa abbastanza piu’ complicato.

#8

Il problema della chiave univoca lo ho già banalmente nel test. Devo lanciare 400 messaggi e ho un solo codfisc. La chiave non è più solo codfic, ora è codice fiscale: , che viene rimossa all’invio.

Quando dovremo gestire milioni di messaggi… giusto! Ma ci sta di peggio: DOVE TENIAMO I LOG? Si accettano proposte.

Se dovessi scegliere io metterei couchdb perchè lo conosco abbastanza bene. Se lo mettiamo, serve anche per openwhisk.

#9

Per i log potrebbe essere interessante uno stack EFK. Se dovrà girare tutto su kubernetes ci sono un sacco di tutorial per l’integrazione e sicuramente sarà comodo quando si inizierà a scalare il servizio. https://medium.com/avmconsulting-blog/how-to-deploy-an-efk-stack-to-kubernetes-ebc1b539d063

#10

ELK/EFK è molto pesante e abbastanza complesso. Potrebbe essere overkill IMHO.