In questo articolo descrivo le idee fondamentali che ci hanno guidato nello sviluppo dei moduli di login di Web UP.

Sessioni e Login

Nel momento in cui un utente inizia ad interagire con un sistema software si stabilisce una sessione di lavoro.

La sessione di lavoro è l’intervallo di tempo finito in cui il sistema ricorda le azioni del proprio interlocutore per rispondere appropriatamente alle sue richieste. Non è necessario che l’utente sia noto a priori, ma è ciò che succede di solito in Sme UP. Un esempio di sessione in cui l’utente può rimanere ignoto è quello della gestione del carrello in un sito di e-commerce.

Nel caso in cui l’utente debba essere già conosciuto dal sistema la sessione di lavoro verrà avviata a seguito della cosiddetta autenticazione. L’autenticazione è il processo attraverso il quale l’utente viene riconosciuto in modo sicuro dal sistema.

Server

Tramite il terminale 5250 l’utente inserisce le proprie credenziali e inizia una sessione di lavoro. In ultima analisi la sessione è mantenuta da un job, che permette di memorizzare lo stato dell’interazione dell’utente con il sistema.

Questo modello è stato ereditato prima da Looc.UP e poi da Web.UP. Esiste sempre una corrispondenza uno a uno tra sessione e job as400. Sottolineo che non si tratta dell’unico approccio possibile ma di quello da noi adottato.

Estensione di Web.UP

L’approccio appena descritto non è sempre adeguato alle esigenze delle applicazioni web. In particolare non è sempre possibile codificare un utente di sistema operativo per ogni utente web a cui vogliamo dare accesso.

Per questo si è pensato di dare anche la possibilità di registrare gli utenti web in diversi database. È possibile definire una fun, cioè un servizio, che si occupa della effettiva autenticazione dell’utente.

Molto spesso viene usata la tabella JAU. Con  Web.UP è emersa anche la necessità  di esporre i servizi di Sme.UP a sistemi automatici oltre che agli utenti umani.

Per questo esiste il cosiddetto “external login” dove la parola external sottolinea che l’accesso è effettuato da un programma esterno (estraneo) a Sme.UP. Si è voluto anche nascondere, limitare e semplificare l’accesso ai diversi ambienti di Sme,UP.

Spesso i servizi che i nostri clienti vogliono pubblicare su Internet non hanno bisogno della flessibilità fornita dagli “ambienti” e dagli “ingressi utente” di Sme.UP. In questi casi costringere l’utente a specificare l'”ingresso” costituirebbe più uno svantaggio che una opportunità. Per risolvere tutte queste casistiche il sistema di login di Web,UP è stato progettato in modo modulare.

In particolare sono stati definiti quattro tipi di login:

  • USRPRF (accesso “classico” con credenziali di sistema)
  • FUN (autenticazione gestita da un servizio RPG che verifica le credenziali)
  • ROLES (framework con autenticazione gestita da un servizio RPG, che verifica le credenziali e definisce quale utente usare per il collegamento, in modo che gli utenti siano raggruppati per ruoli, dove ogni ruolo è rappresentato da un particolare utente di sistema operativo)
  • DIRECT (accesso diretto senza inserimento esplicito di credenziali da parte dell’utente)
Modulo Sessioni Autorizzazioni
USRPRF Ogni sessione web corrisponde a un job LO_Exxxxxxx. Il job gira con i permessi dell’utente di sistema operativo Le autorizzazioni funzionano proprio come in Looc.UP
FUN Ogni sessione web corrisponde a un job LO_Exxxxxxx. Tuttavia in questo caso i diversi job gireranno sempre con i permessi
dello stesso utente(master)
La autorizzazioni vanno gestite in modo personalizzato
ROLES Per ogni sessione un job LO_Exxxxxxx.  L’utente con cui gira il job dipende dall’utente di sistema operativo su cui è mappato l’utente web In questo caso si possono usare le autorizzazioni standard di Sme.UP tenendo debitamente conto della mappatura degli utenti.

Poiché la mappatura può essere di tipo molti a uno, questa modalità non obbliga a codificare un utente di S.O. per ogni utente web, ma al contempo di sfruttare le autorizzazioni standard

DIRECT Ad ogni sessione web corrisponde un job LO_Exxxxxxx. L’utente web è anonimo e ogni job gira con lo stesso utente di sistema operativo Le autorizzazioni standard posso essere usate per limitare l’operatività degli utenti “pubblici”

Altre idee

Come abbiamo visto Sme UP ha rimosso, tramite Web UP, il vincolo di usare utenti di sistema operativo ma rimane la corrispondenza uno a uno tra sessioni utente e job.

Questo potrebbe costituire un limite nel caso in cui una stessa istanza di Sme.UP dovesse servire migliaia di utenti.

Ci imbatteremo in un problema analogo al famigerato C10k problem. Il laboratorio sta vagliando nuovi modelli nella gestioni degli utenti per apportare miglioramenti a basso livello, direttamente nel cuore di Sme.UP. Questo potrebbe aprire la strada a nuove idee architetturali in Web UP con conseguenti significativi miglioramenti di performance.

 

Sviluppi futuri

Con le evoluzioni della versione V5R1 di Sme.UP sarà possibile superare i concetti FUN e ROLES e gestire nativamente un database di utenti (B£U) non legati al sistema operativo, ma con le stesse funzionalità, come se lo fossero.