Lo sviluppo delle tecnologie cloud, mobile e IOT impongono un cambio di passo rispetto alla sicurezza finora utilizzata nel “recinto” aziendale. La nuova linea di difesa è basata sull’identità digitale ed ecco che ci viene in soccorso l’Identity and Access Management (IAM). Il ruolo dell’IAM è quello di gestire gli utenti, la loro profilazione all’interno dell’azienda e le relative autorizzazioni per l’accesso alle sezioni.
In questo articolo vi parlerò delle caratteristiche, pro e contro di WSO2 Identity Server [1], un prodotto open source della piattaforma WSO2 altamente customizzabile e con un ottimo supporto da parte della community di sviluppo.
Buona lettura.
WSO2: Interfaccia e dashboard di controllo
A prima occhiata l’interfaccia grafica di WSO2 risulta piuttosto datata, nonostante ciò presenta tantissime funzionalità.
La dashboard di WSO2 è il cuore e permette di gestire agevolmente tutte le caratteristiche come ad esempio creare ruoli, aggiungere utenti e collegare applicazioni.
Per utenti più esperti, è possibile settare le configurazioni attraverso i file di configurazione.
Una volta lanciata l’installazione la struttura decisa sarà già pronta, sgravando il cliente o voi stessi da parecchio lavoro.
Elenco qui alcune delle funzionalità che abbiamo provato ad utilizzare:
- Reset della password attraverso “One Time Password”.
- Reset della password attraverso la mail.
- Scadenza della password.
- Utilizzo di Claim per inviare informazioni all’applicativo.
Il responso è piuttosto positivo: la documentazione è abbastanza dettagliata anche se a volte richiede l’aiuto della community, la possibilità di customizzare la maggior parte del lavoro permette una relativa libertà di movimento.
Service provider
Un Service Provider (SP) è un’entità che fornisce servizi Web la quale si basa su un provider di identità (IdP) attendibile per l’autenticazione e l’autorizzazione. In questo caso WSO2 Identity Server funge da IdP e svolge il compito di autenticare e autorizzare l’utente del fornitore di servizi.
I service provider hanno delle chiavi che vengono utilizzate dalla vostra applicazione per collegarsi a WSO2 e scambiarsi tutte le informazioni necessarie.
In WSO2 l’aggiunta di un service provider è relativamente semplice e altamente personalizzabile con numerose funzionalità tra cui la scelta del tipo di token, come ad esempio il JSON Web Token (JWT) che abbiamo provato.
All’interno del SP vengono anche definite le informazioni dell’utente loggato che si vogliono inviare all’applicativo esterno: le Claim.
Il settaggio di una Claim si effettua attraverso la dashboard e nonostante un inizio un po’ ostico in seguito la procedura diventa chiara e semplice. Anche in questo è possibile customizzare qualsiasi tipo di Claim o addirittura crearne delle proprie aggiungendo dei jar specifici prendendo come base il loro progetto Open.
Tenant
Un tenant è un’istanza che rappresenta un dominio specifico con i propri dati, utenti, ruoli e autorizzazioni.
Gli utenti all’interno di questo dominio possono gestire i propri dati ed eseguire le proprie transazioni senza essere influenzati dalle azioni svolte in altri domini.
Concretamente un tenant può essere considerato un cliente che utilizza dei Service Provider (Applicazioni) comuni ad altri domini senza poter accedere ai dati di questi altri.
Alla creazione di un tenant, wso2 setta automaticamente un utente ‘admin’ del dominio che ha potere assoluto nel suo solo tenant senza poter accedere ad altri ‘clienti’.
Utilizzo di WSO2 con un’amministrazione propria
Noi attualmente utilizziamo il servizio come Identity Provider, specularmente abbiamo un’amministrazione di produzione propria che interroga WSO2 per tantissime questioni.
L’utilizzo del Token con l’applicazione interessata è abbastanza semplice anche grazie alla presenza di numerosissime Claim di default che facilitano il lavoro. Come citato sopra qualora si vogliano aggiungere delle Claim non previste ciò è possibile attraverso una procedura più dettagliata [2].
Alcuni problemi riscontrati
Forse il punto più dolente ad oggi si riscontra quando, utilizzando un’applicazione di amministrazione di produzione propria, si vuole interrogare WSO2 per fare le procedure che altrimenti verrebbero fatte dalla loro dashboard nativa.
Riporto due problemi dalla mia esperienza:
- Il più ostico è la poca documentazione relativa a queste chiamate che a volte ti porta a dover analizzare il codice [3], open per fortuna, di WSO2 o fare numerosi test per venirne a capo.
- La presenza di numerosissime chiamate SOAP [4]. Questo credo derivi dal fatto che WSO2 sia una piattaforma piuttosto vecchia. All’interno del team abbiamo però notato che ad ogni versione vengono aggiunte chiamate SCIM/REST [5] in parallelo con le chiamate già esistenti in SOAP. Ciò non toglie che numerose chiamate siano ancora gestite con la vecchia modalità.
Considerazioni finali
Dopo mesi di lavoro con questa piattaforma credo di poter segnalare dei pro e contro per utilizzare questo servizio:
| PRO | CONTRO |
| Altamente customizzabile | Presenza di chiamate SOAP |
| Piattaforma viva in continuo aggiornamento | Grafica piuttosto datata |
| Supporto da parte della community di sviluppo | Ogni versione nuova non è per forza ‘100% compatibile’ con quella precedente |
| Progetto Open source | |
| Servizi esistenti divisi in micro progetti open modificabili |