Uno studio in JIRA – Scenario e possibili soluzioni
Uno studio in JIRA
In questo post cercheremo di descrivere un possibile scenario, dettato da una necessità reale, cui successivamente cercheremo di fornire alcune possibili soluzioni.
JIRA esposto verso i clienti
Partecipando ad un evento, mi fu indicata questa situazione: Si voleva esporre JIRA verso dei clienti. Tuttavia esisteva sempre il timore che i clienti potessero anche accedere, oltre ai progetti loro esposti, anche altri progetti, cui NON DOVEVANO ACCEDERE.
Si trattava ancora di JIRA 6 e JIRA 7 era appena stato rilasciato.
La necessità è reale. Avere a disposizione un unico JIRA è sicuramente utile. Non abbiamo la necessità di dover gestire più istanze e non ci complichiamo la vita con troppe operazioni di amministrazioni.
Quali azioni possiamo intraprendere?
Sicuramente andiamo a gestire i permessi ed i relativi permission scheme associato al progetto.
In quest modo riusciamo a stabilire chi fa cosa e perché. In aggiunta, lavorando con i Roles del progetto, stabiliamo i ruoli degli utenti.
Questo sicuramente aiuta nel separare le persone dalle informazioni che possono leggere da quelle che non devono reperire.
Utile, ma??
Questo è sicuramente utile, ma tenendo tutto in un unico JIRA esiste sempre la possibilità che:
- una configurazione possa …. scappare e di conseguenza delle informazioni possono essere lette;
- si potrebbe sfruttare dei buchi di sicurezza (ce ne sono stati e ce ne saranno sempre) ed accedere a sezioni private;
- se abbiamo un numero molto alto di utenti da gestire, l’errore aumenta.
Ok. Che cosa possiamo fare?
Possiamo sfruttare le API REST che i prodotti della Atlassian mettono a disposizione. In questo modo possiamo mettere a disposizione una applicazione, ad uso interno, per mettere a disposizione degli utenti ciò di cui hanno bisogno, e niente ALTRO.
Le API sono molto complete e permettono di poter fare… praticamente tutto. Di conseguenza abbiamo una applicazione opportunamente bloccata e configurata. Il pericolo delle falle di sicurezza è limitato…… forse :-O
Tuttavia, questo significa che occorre SVILUPPARE e MANUTENERE questa applicazione. Di conseguenza aumentano i costi e i tempi. Questo è un aspetto da non sottovalutare.
La facciamo più difficile? ovviamente si
Se oltre a JIRA volessimo esporre anche JIRA Service Desk? Questo complica la vita. La versione 6 di JIRA differisce parecchio dalla versione 7 di JIRA, come abbiamo mostrato nei precedenti post e nei post successivi.
Nella versione 6, JIRA Service Desk è un ADDON di JIRA. Quindi, se si vuole esporre JIRA Service Desk abbiamo comunque lo stesso problema.
In questo caso, le API di JIRA Service Desk sono state introdotte solo dopo. Di conseguenza la strada di un applicativo a se stante non è percorribile.
Che alternative abbiamo?
Se non abbiamo a disposizione di un team di sviluppo, se siamo magari una azienda medio piccola e l’informatica non è il core business, che cosa possiamo fare? Cercheremo di dare delle risposte nei prossimi post.
Conclusione
Abbiamo introdotto un nuovo argomento molto delicato ma mooooooooooolto interessante 🙂 . Cercheremo di svilupparlo molto bene nei prossimi post.
