WikiUp

Moduli di login


Per l'accesso utente ad un'installazione di webup è necessario configurare uno o più moduli di login.

Esistono diverse tipologie di moduli di login, che supportano le esigenze più varie. Esse sono:
  • USRPRF: accesso "classico" con credenziali di sistema operativo
  • FUN: autenticazione gestita da un servizio RPG che verifica le credenziali
  • ROLES: autenticazione gestita da un servizio RPG, con utenti 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
  • GOOGLE: autenticazione esterna, effettuata tramite Google

Nelle pagine successive verranno descritte e documentate nel dettaglio. Si tratteranno inoltre vari concetti generali connessi all'autenticazione in webup, quali ad esempio quelli di external login e di costruzione e validazione di una url per webup. Per le configurazioni lato backend smeup si rimanda, oltre a quanto riportato qui, alla documentazione della UPP WE_110:
Servizio auteticazione standard



Creazione e abilitazione di un modulo di login

Per accedere alla configurazione dei moduli di login occorre entrare nell'area di amministrazione di webup (premendo la combinazione di tasti CTRL+SHIFT+F8, inserendo la password richiesta ed aggiornando la pagina).

Creazione

Per creare un nuovo modulo di login utilizzare la sezione "Create new login module".
Apparirà una form di creazione in cui sarà prima da definire il tipo di modulo di login da utilizzare e successivamente saranno da riempire i parametri di configurazione necessari.


Esiste un insieme di parametri comuni a tutte le tipologie di moduli login. Esistono poi eventualmente parametri specifici di ogni tipologia.

Tra i parametri comuni ad ogni tipologia di modulo di login si evidenziano i seguenti.


Parametri di base
  • Type: tipologia (USRPRF, FUN...)
  • Identifier: un codice alfanumerico univoco per identificare il modulo di login (es: demo, showcase, ..)
  • Title: il titolo descrittivo (es: Webup showcase, Sviluppo CRM, ...)
  • Logo: è possibile associare un'immagine (caricata precedentemente nel sistema e configurata nella sezione Main config > Logo) da mostrare all'utente sulla form di login
  • Visible: gestisce la visibilità del modulo: "Yes" = sempre visibile, "No" = invisibile, "Yes, if in URL" = visibile se l'identificativo del modulo è presente nella url di richiesta a webup
  • Stay connected mode: se abilitato mostra un flag di persistent login nella form di login dell'utente. Se l'utente in fase di login dichiara di volere una login persistente allora se chiude il browser e lo riapre si troverà ancora loggato. Di norma invece se l'utente si logga, chiude il browser e lo riapre deve rieffettuare la login.
  • Smeup encoding: encoding dei caratteri in formato smeup (es: EU, RU, IT...)

Parametri di connessione

Se alcuni di questi campi non sono valorizzati a seconda del modulo di login verranno richiesti nella form presentata all'utente.

  • Smeup Provider: la url dell'applicazione server con cui webup si deve collegare. Generalmente è uno Sme.UP Provider (esempio: https://providertest.smeup.com) o un as400-proxy, nel caso di installazioni webup providerless
  • System: l'indirizzo dell'as400 con cui webup si collegherà (esempio: srvlab01.smeup.com). Nel caso di as400-proxy non è necessario compilarlo in quanto è l'as400-proxy che ha definito al suo interno l'as400 di collegamento
  • Environment: l'ambiente as400 al quale il modulo di login si deve collegare
  • User: l'utente
  • Password: la password utente

Parametri collegati alla validazione della url
Sono parametri di dettaglio collegati alla validazione della url, per cui si rimanda al paragrafo relativo (es: Hashing shared secret, Hashing algorithm, Time skew in seconds between two requests...).

Parametri di personalizzazioni di webup definibili a livello di singolo modulo di login
Nella configurazione del modulo di login sono presenti alcuni parametri di configurazione di webup personalizzabili fino al livello del singolo modulo di login, quali ad esempio i flag di vista Web o Mobile, di abilita Invia Segnalazione...


Abilitazione

Per abilitare il modulo creato andare nella sezione "Main config" e aggiungerlo alla Sezione Login Modules.


Modulo di login di tipo USRPRF


Descrizione

La modalità di USRPRF è generalmente utilizzata per accedere a webup lasciando all'utente la possibilità di inserire i parametri d'accesso (solo quelli che non sono già impostati nella configurazione del modulo).

Questa modalità di login si fonda sull'utente di sistema operativo dell'as400 (registrato nella tabella B£U). Gli utenti che si loggano a webup in questo caso devono loggarsi con le credenziali degli utenti definiti sul sistema operativo as400 configurato nel modulo di login.

Utenti, sessioni e job

Ogni potenziale utente web corrisponde ad un utente B£U. Ogni sessione web corrisponde a un job LO_Exxxxxxx. Il job gira con i permessi dell'utente di sistema operativo.

Diagramma di flusso


Dettagli di configurazione

I parametri da configurare sono quelli di cui si è già parlato nella parte dei parametri comuni ai vari moduli di login.


Modulo di login di tipo FUN


Descrizione

Questa modalità di login è utilizzata in contesti in cui si vuole gestire l'accesso di "n" utenze senza dover creare i relativi utenti di sistema operativo.

Serve solo un utente di sistema operativo per la connessione "master", gli utenti sono utenti applicativi individuati da record registrati nella tabella JAU.

Nella modalità standard, occorre creare le "n" utenze necessarie nella tabella JAU.

Al momento del submit della form, verrà chiamato il servizio WEJAU_01 che riceverà utente/password digitati e, una volta verificate le credenziali nella tabella JAU, restituirà un xml di matrice monoriga contenente tutti i campi della tabella JAU e permetterà quindi l'accesso al sistema.

Il valore di ogni campo della matrice sarà inoltre disponibile all'interno delle schede smeup (nel contesto webup) nella forma *WebUser.<nomeCampo> (es: *WebUser.T$JAUF).

Il servizio è estendibile a piacimento e può quindi restituire una matrice arricchita di tutti i dati necessari.

Ad esempio, aggiungendo alla matrice il campo XXABCD, lo stesso sarà poi disponibile nelle schede come *WebUser.XXABCD.

Utenti, sessioni e job

Ogni potenziale utente web corrisponde a un utente JAU. 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 di B£U configurato nel modulo di login.

Diagramma di flusso



Dettagli di configurazione

I parametri specifici correlati a questo modulo di login sono i seguenti:
  • Login fun: la fun che webup chiamerà al submit della form di login. La fun standard è: F(EXB;WEJAU_01;USR.LGI) INPUT(USR({0}) PWD({1}))
  • Fun for external authentication: la fun che webup chiamerà alla richiesta a webup di una external login. La fun standard è F(EXB;WESER_00;EXT.LGI) INPUT(USR({0}))
  • Fun password lost: se valorizzata appare un link di recupero password nella maschera di login di webup. Inserendo lo user e cliccando il link viene chiamata la fun. La fun può rimandare ad un servizio personalizzato come si desidera (ad esempio che invia all'utente una mail).
  • AppUser field name: il campo con il nome dell'utente nella tabella JAU
I parametri di connessione da inserire saranno quelli dell'utente di sistema operativo con cui veranno creati tutti i job.


Modulo di login di tipo ROLES


Descrizione

Questa modalità di login è utilizzata in contesti in cui si vuole gestire l'accesso di "n" utenze senza dover creare i relativi utenti di sistema operativo, ma a differenza della modalità FUN, possono essere associate ad ogni utente delle autorizzazioni di gruppo.

Occorre per prima cosa creare utenti di gruppo nella tabella B£U. Potrebbero essere ad esempio SMECLI, SMEAGE, SMECAP qualora si voglia creare tre tipologie di utenti: Cliente, Agente, Capo area.
Nella modalità standard, occorre creare poi le "n" utenze necessarie nella tabella JAU ed associare ad esse il relativo utente di gruppo, specificandolo nei campi di JAU.

Ad esempio gli utenti JAU CLI001, CLI002, CLI00n si assoceranno a SMECLI
Tipo ogg.associato=TA
Par. ogg.associato=B£U
Cod. ogg.associato=SMECLI

analogamente gli utenti JAU AGE001, AGE002, AGE00n si assoceranno a SMEAGE:
Tipo ogg.associato=TA
Par. ogg.associato=B£U
Cod. ogg.associato=SMEAGE

Al momento del submit della form, verrà utilizzato un utente "master" con il quale si chiamerà il servizio WEROL_01. Tale servizio che riceverà utente/password digitati e, una volta verificate le credenziali nella tabella JAU, reperirà anche le informazioni B£U legate all'utente associato. In questo modo verrà restituito un xml di matrice monoriga contenente tutti i campi della tabella JAU e tutti i campi della tabella B£U. webup a questo punto cercherà l'utente di gruppo (SMECLI, SMEAGE, SMECAP...) restituito all'interno di una mappa (utente:password:ambiente) precompilata e terminerà la connessione master per ritentarne una con le nuove credenziali.

Nelle variabili di Web.UP avremo, sempre con la sintassi *WebUser.<codice_colonna>, gli elementi della JAU e gli elementi della B£U, in modo da poter distiguere più utenti con lo stesso ruolo.

Un esempio del giro è il seguente: l'utente JAU esegue il login con UTEJAU01. Web.UP si collega all'AS400 con l'utente di sistema WEB_A1. Nella JAU, l'utente associato è UTEB£U07, Web.UP trova che nel modulo di login per l'utente UTEB£U07, va eseguito il login all'AS400 con l'utente di sistema WEB_B5, chiude il lavoro aperto con l'utente WEB_A1 ed esegue una nuova connessione con l'utente WEB_B5.

Di fatto quindi il job su as400 sarà intestato all'utente di gruppo e come tale godrà delle relative caratteristiche.
Relativamente al servizio, analogamente alla modalità fun, esso può essere esteso e modificato a piacimento.

Utenti, sessioni e job

Ogni potenziale utente web è un utente JAU. Per ogni sessione web esiste un job LO_Exxxxxxx. L'utente con cui gira il job dipende dall'utente B£U associato all'utente JAU. Oltre agli utenti B£U che identificano i ruoli serve un utente master di servizio per operazioni pre login utente.

Diagramma di flusso



Dettagli di configurazione

I parametri specifici correlati a questo modulo di login sono i seguenti:
  • Fun to use for roles authentication: la fun che webup chiamerà al submit della form di login. Ad esempio: F(EXB;WEROL_01;USR.LGI) INPUT(USR({0}) PWD({1}))
  • Fun for external authentication: la fun che webup chiamerà alla richiesta a webup di una external login. Ad esempio: F(EXB;WESER_00;EXT.LGI) INPUT(USR({0}))
  • Fun password lost: se valorizzata appare un link di recupero password nella maschera di login di webup. Inserendo lo user e cliccando il link viene chiamata la fun. La fun può rimandare ad un servizio personalizzato come si desidera (ad esempio che invia all'utente una mail).
  • User field name: il campo con il nome dell'utente nella tabella JAU
  • Role master user da 01 a 05: gli utenti di sistema operativo corrispondenti ai ruoli nella forma "user:password:environment" (es: WU3_ADM:z1l9k98sq0:P_WU3)
  • Allow login as Userprofile: se impostato a true, nel caso in cui la fun di roles autentication fallisca viene tentato il login con il master user di servizio
I parametri di connessione da inserire saranno quelli dell'utente master di sistema operativo con cui verrà effettuata la connessione di servizio.


Modulo di login di tipo DIRECT


Descrizione

Questa modalità è utilizzata perché l'utente acceda a webup in maniera diretta, ovvero senza lasciargli la possibilità di cambiare alcun parametro d'accesso.

Questa modalità usa un utente di sistema operativo.

Utenti, sessioni e job

Ad ogni sessione web corrisponde un job LO_Exxxxxxx. L'utente web è anonimo e ogni job gira con lo stesso utente di sistema operativo configurato nel modulo di login.

Diagramma di flusso



Dettagli di configurazione

I parametri da configurare sono quelli di cui si è già parlato nella parte dei parametri comuni ai vari moduli di login.


Modulo di login di tipo GOOGLE


Descrizione

Questa modalità di login permette di utilizzare un'autenticazione esterna, in questo caso quella di Google, per poter entrare in webup.

E' necessario un utente AS400 di sistema condiviso da tutti gli utenti che utilizzano questo modulo di login. Inoltre è necessario un raccordo a sistema tra la mail che verrà utilizzata per autenticarsi su Google e il corrispettivo utente di sistema operativo che verrà utilizzato da webup come utente loggato.

Il funzionamento è il seguente.

Al click su "Accedi" in prima istanza viene aperta una sessione con l'as400 utilizzando le credenziali dell'utente di sistema indicate nella configurazione del modulo. La sessione AS400 è necessaria per reperire mediante la funLogin l'utente applicativo.

Se la creazione e il recupero hanno successo viene fatto effettuata una redirect ad un'api apposita di smeup (https://google-auth.smeup.cloud/google-apis-1.0/oauth2) che implementa il flusso oauth2 per l'autenticazione con gmail.

All'url sarà passato come parametro la url di callback su webup loginGoogleCallback.jsf?moduleName=<idmodulo> sulla quale l'api farà il redirect una volta che l'utente si è autenticato con le sue credenziali gmail. Alla url di callback, l'api aggiungerà anche il parametro: authAccessTokenURL contenente un url temporaneo.

La callback a webup fa si che webup costruisca la fun con l'indirizzo gmail ritornato dall'api. L'indirizzo gmail è letto mediante GET dall'URL temporaneo indicato nel parametro authAccessTokenURL.
Una volta ottenuto l'utente applicativo tramite la sua mail viene distrutta la sessione di sistema e viene creata una nuova sessione as400 passando oltre all'utente as400 di sistema anche l'utente applicativo corrispondente a quell'indirizzo mail.

Per informazioni sulle configurazioni a sistema si rimanda alla documentazione dell'UPP WE_110, relativamente all'Accesso tramite autenticazione esterna:
Servizio auteticazione standard

Utenti, sessioni e job

Per ogni sessione web esiste un job LO_Exxxxxxx. L'utente con cui gira il job è l'utente della B£U che ha associato l'indirizzo mail di google utilizzato durante l'autenticazione Google. Serve un utente master di servizio per operazioni pre login utente.

Diagramma di flusso



Dettagli di configurazione

I parametri specifici correlati a questo modulo di login sono i seguenti:
  • Oauth proxy: web application smeup di gestione dell'autenticazione Google (https://google-auth.smeup.cloud/google-apis-1.0/oauth2)
  • Login fun: la fun da utilizzare per determinare dall'indirizzo gmail l'utente di sistema (quella standard è: F(EXB;WEAUTH_03;USR.OUT) INPUT(OUT({0})))
  • AppUser field name: il campo da cui dall'oggetto tabella restituito dalla login fun si estrae l'utente (di default se vuoto è $$UTEN)


External login


Generalmente l'utente non loggato che accede all'applicazione vedrà comparire una form di login in cui immettere le proprie credenziali o altre informazioni o in cui solo esclusivamente premere il bottone di login.

Esempio 1: login con immissione di informazioni


Esempio 2: login senza immissione di credenziali


L'accesso a qualsiasi url interna all'applicazione riporta infatti un utente non loggato alla pagina di login ({CONTEXT DI WEBUP}/views/../webuplogin.jsf).
Esiste però una particolare url dell'applicazione ({CONTEXT DI WEBUP}/views/webupExtLogin.jsf) a cui è associata una forma di autenticazione definita come "External", che permette di autenticare l'utente attraverso i normali moduli di login, ma senza presentare la form di login.

Questa modalità supportata da tutti i moduli di login, è pensata soprattutto per l'integrazione con altre applicazioni web.

Un esempio pratico è quello di fornire, ad esempio all'interno di una comunicazione o una mail inviata agli interessati, l'accesso diretto allo showcase dell'installazione di webup di demo del laboratorio. Una url di external login è quella che fa al caso suddetto, portando direttamente l'utente all'interno dello showcase:
https://webup.smeup.com/WebUP/views/webupExtLogin.jsf?mod=demo.

Costruzione di una url


Nella url di chiamata a webup è possibile passare alcuni parametri per poter visualizzare una determinata schermata di contenuto.

Questo è l'elenco dettagliato dei parametri ammissibili:

  • mod (modulo di login): definisce quale modulo di login utilizzare
  • t (timestamp): definsce data e ora UTC in formato yyyyMMddhhmmss
  • hash (hash dei parametri): codice di validazione (dettagliato nei paragrafi successivi)
  • callBack (url di callback): url per ritornare all'applicazione chiamante (dettagliato nei paragrafi successivi)
  • sfunction: contiene il nome della variabile SCP_CLO da usare come funzione d'avvio in sovrascrittura dell *SFUNCTION
  • fun: fun da eseguire
  • var (variabili): variabili da passare che verranno messe nel contesto LOO.VAR e impostate subito. La forma è variabile(valore)variabile2(valore2)
  • p (parametro): contiene il parametro specifico in caso di autenticazione (ad esempio il nome utente che verra passato alla fun di autenticazione)
Un esempio di chiamata http a webup potrebbe ad esempio essere il seguente:
https://mobile.smeup.com/AreaRiservata?mod=ges10adv&fun=F(EXD;*SCO;)%201(MB;DOC_VID;A%C2%A3FORM_001)%202(MB;SCP_SCH;MODEMO_VI)%204(;;VIDSCH)&hash=bf63c84eb120ce18b4e93f42f3407bbfcf277fec
Essa porta direttamente l'utente al modulo di login ges10adv dell'installazione webup https://mobile.smeup.com/AreaRiservata. Una volta loggatosi l'utente viene automaticamente eseguita la fun che porta a visualizzare un contenuto di tipo video.

Validazione di una url


E' possibile configurare su un dato modulo di login una validazione per la visualizzazione del contenuto di una url attraverso la compilazione del parametro di configurazione denominato "Hashing shared secret".

Questa validazione è utile quando si vuole impedire la chiamata di fun particolari agli utenti. Solo le chiamate valide permettono all'utente di visualizzare il contenuto, altrimenti riceverà un errore di richiesta non valida.

La validazione della url viene effettuata in questo modo.

Webup calcola l'hash dei parametri presenti nella url richiesta secondo il calcolo riportato più sotto e viene confrontato con il parametro hash passato nella url richiesta. Se hash atteso e hash inviato sono uguali viene calcolato il timestamp attuale e viene confrontato con quello della chiamata fatta, con una tolleranza definita nella configurazione del modulo di login dal parametro "Time skew in seconds between two requests". Se il check dell'hash e del timestamp hanno successo viene eseguito il login sul sistema nelle modalità definite nel modulo utilizzato, altrimenti altrimenti all'utente viene mostrato un messaggio di errore di richiesta non valida.

Si riporta qui un algoritmo in pseudo codice del calcolo dell'hash atteso.

Supponendo, ad esempio, di utilizzare l'algoritmo SHA1, l'encoding UTF-8, e l'hash secret WEBUP91818$.

Supponiamo inoltre che la chiamata sia:
http://mauer.smeup.com/AreaRiservata/views/webupExtLogin.jsf?
mod=areaRiservata
&p=mauro.sanfilippo@smeup.com
&t=20150429075751
&hash=828895f2ee6139d5b8ddaaca05510a6f8b3aceb7
&callBack=http://areariservata.smeup.com/area-demo/web-up-3.html
&sfuncion=CLI
12=A(B)C(DD)E(FFFF)

L'algoritmo sarà il seguente:

String stringToHash= p + timestamp + "WEBUP91818$" + callback + sfunction + var + fun ;

byte byteToHash= encode("UTF8",stringToHash);

byte calculatedHash = hashFunction("SHA1", byteToHash);

if(calculatedHash != receivedHash)
return "INVALID REQUEST";

Per fornire all'utente una url con hash corretto è possibile utilizzare l'api smeup K15.

Url di callback


In una chiamata a webup è possibile impostare anche una url di callback.

Esempio:
http://webuptest.smeup.com/WebUP/views/webupExtLogin.jsf?mod=XXX&sfunction=YYY&callBack=http://www.chiamante.com

La url di callback è una url che viene automaticamente chiamata da WebUP nei seguenti casi:
  • errore di login
  • logout da webup
Generalmente viene utilizzata quando da un determinato sito web X si rimanda a pagine di webup.
Se c'è un errore o l'utente si slogga si desidera che ritorni al sito web X.
Nel caso di errore, per permettere al chiamante di identificare la situazione, viene passato il parametro error.
Supponendo che la callbackUrl impostata sia http://www.chiamante.com verrà ad esempio richiamata con il parametro error valorizzato (es: http://www.chiamante.com?error=hashError).

Gli errori vengono segnalati come segue:
ParametroDescrizione
configCheckErrorErrore nel reperimento della configurazione del modulo
timeErrorRichiesta scaduta
hashErrorHash non valido
userErrorUtente non autorizzato o sconoscuito


Add new attachment

Only authorized users are allowed to upload new attachments.
«