Guida alla esposizione multiportale delle applicazioni

Cosa si intende per "esposizione multiportale" e qual'è il livello di supporto di guigen

Con il termine "esposizione multi-portale" si intende la possibilità di esporre una stessa applicazione su due siti web differenti con l'installazione dell'applicazione in un unico ambiente server. L'installazione su più di un portale/sito tipicamente comporta:

• la potenziale differenziazione della rete telematica dalla quale l'applicazione dovrà essere raggiungibile (es. internet vs intranet)
• la potenziale differenziazione del parco di utenza dell'applicativo (es. cittadino vs personale della P.A);
• la potenziale differenziazione del livello di autenticazione richiesto (es. nessuna autenticazione vs autenticazione con credenziali testuali vs autenticazione con certificato digitale...);
• la potenziale differenziazione dell'aspettto grafico delle schermate.

guigen ha il seguente grado di supporto:

• differenziazione della rete telematica di esposizione: è realizzata tramite la creazione di una location sul web server di ciascun sito
• differenziazione della modalità di autenticazione: in caso di esposizione multiportale attualmente è necessario che la modalità di autenticazione sia la medesima su tutti i portali di esposizione
• differenziazione del livello minimo di credenziali necessarie per l'autenticazione: in caso di esposizione multiportale attualmente è necessario che il livello di credenziali richieste per l'autenticazione sia la medesima su tutti i portali di esposizione
• differenziazione dell'apparenza grafica: è realizzata tramite l'utilizzo a runtime di uno skin differente sulla stessa struttura di HTML; è pertanto possibile personalizzare esclusivamente ciò che è possibile specificare con gli strumenti della stilizzazione CSS.

Inoltre la modalità multi portale è utilizzabile esclusivamente in queste condizioni:

• cartuccia "neutral"
• schema di referenziamento delle risorse statiche: M2
• collocazione remota delle risorse statiche

L'architettura di implementazione dell'esposizione multiportale effettuata da guigen prevede come punto centrale l'implementazione del meccanismo di WAYF (Where Are You From), ovvero il riconoscimento a tempo di esecuzione del portale su cui l'utente corrente è collegato. Nella piattaforma CSI attuale le possibili fonti di tale informazione sono:

• Informazioni rese disponibili dal sistema di Single-Sign-On (se presente)
• Informazioni esplicite fornite alla componente server in fase di primo accesso dell' utente all' applicazione.

Le due modalità sono gestite in modo armonizzato dal codice generato:

• l'informazione proveniente dal sistema di autenticazione è inserita dall'infrastruttura di autenticazione (N.B: questa modalità è deprecata).
• l'informazione esplicita è utilizzata solo in caso di assenza di sistema di autenticazione. L'implementazione di default prevede che tale informazione sia fornita tramite un parametro di nome "PORTALE" da inserire nella url di accesso iniziale (per il valore da impostare a seconda del portale consultare la sezione "portal profiles")
• è inoltre possibile (ed è consigliato) modellare esplicitamente un elemento di tipo WAYFProfile che permette di personalizzare il comportamento relativamente alla risoluzione del portale di provenienza (vedere sotto l'apposita sezione).

Portal profiles

Dal punto di vista degli strumenti MDD ciascun portale è caratterizzato da un certo numero di informazioni che ne descrivono i codici identificativi, l'insieme delle librerie JS utilizzate per le funzioni di front-end, l'insieme delle risorse statiche che costituiscono lo skin.

Queste caratteristiche sono mantenute, ad uso principalemnte della modellazione guigen, ma non solo, in modelli specifici denominati Portal Profiles: ad un certo istante e per uno specifico portale esiste una versione di questo modello che ne descrive le caratteristiche.

I Portal Profiles sono modelli utilizzati da chi modella le applicazioni, ma la loro predisposizione è a carico di chi cura l'evoluzione delle componenti infrastrutturali di portale, ovver skin e librerie javascript: sarà cusa di questi ultimi mettere a disposizione di chi sviluppa l'applicazione le corrette configurazioni.

A titolo informativo si riporta di seguito l'elenco delle informazioni principali che fanno parte del Portal Profile:

• codice identificativo del portale: a scopo mnemonico
• codice identificativo del portale per il meccanismo di Where Are You From (che varia a seconda che si usi un particolare WAYFProfile personalizzato)
• codice discriminante del resource provider (utilizzato dal meccanismo di inclusione remota)
• elenco dei moduli JS utilizzati, con versione e collocazione su repart (non utilizzati - solo a scopo di gestione di configurazione)
• elenco dei moduli di stilizzazione (CSS, etc.) utilizzati, con versione e collocazione su repart (non utilizzati - solo a scopo di gestione di configurazione)

Modellazione dell'esposizione multiportale

Per modellare l'esposizione dell'applicativo su un insieme di portali è sufficiente modellare, come figlio dell'elemento TargetPlatform all'interno del modello principale dell'applicazione un elemento PortalExposition per ogni deifferente esposizione; ciascuno di questi elementi:

• referenzia il modello di PortalProfile corrispondente al portale
• specifica il codice dell'area tematica sulla quale, per quel portale, deve essere esposto l'applicativo (non è detto che per due portali differenti l'area tematica sia la stessa nè che tutti i portali possiedano il concetto di differenziazione in aree tematiche). Nel caso in cui il portale non preveda area tematica viene assunta l'area tematica di default 'general'

Attività di sviluppo per l'esposizione multi-portale

Non sono previste attività di sviluppo aggiuntive per abilitare l'esposizione multi-portale, a parte la necessità di definire un progetto di risorse statiche per ogni distinta esposizione.

Attività di dispiegamento in esercizio legate all'esposizione multi-portale

Per dispiegare in esercizio un'applicazione multiportale generata con guigen è necessario:

1. creare una location sul web server di ciascun portale coinvolto
3. nel caso in cui sia necessario impostare il meccanismo esplicito di Where Are You From ricordarsi di aggiungere, nella pagina che contiene il link di accesso all'applicazione, il parametro "PORTALE" nell'url stesso. Il valore da impostare è il codice contenuto nel PortalProfile corrispondente

WAYF profile

E' possibile personalizzare il modo in cui il sistema risolve il portale di provenienza, utilizzando un elemento di tipo WAYFProfile, che può essere modellato nell'oggetto TargetPlatform.

Come figlio dell'oggetto WAYFProfile è necessario modellare un elemento di tipo WAYFRequestAdapter ch epermette di personalizzare il modo in cui il sistema di risoluzione del portale di provenienza ottiene le informazioni discriminanti a partire dalla request o dalla sessione.

Nell'elemento WAYFRequestAdapter è necessario modellare:

• la property sourceType: può assumere i seguenti valori:
  • REQUEST_PARAM
  • REQUEST_ATTRIBUTE
  • REQUEST_HEADER
  • REQUEST_COOKIE
  • REQUEST_URL
  • SESSION_ATTRIBUTE
• la property infoSourceName:
  • in tutti i casi diversi da REQUEST_URL il valore di questo parametro indica da quale parametro/header/cookie, ... prendere il valore discriminante)
  • nel caso REQUEST_URL questo parametro può valere solo DOMAIN_L2 oppure DOMAIN_L3: in entrambi i casi il comportamento prevede che venga estratto dalla url di richiesta l'hostname e il valore discriminante sia la parte finale di tale hostname, fino al dominio di secondo o terzo livello a seconda che si sia specificato il valore DOMAIN_L2 o DOMAIN_L3

Ad esempio per fare in modo che il portale di provenienza sia risolto dall'url è, prendendo come chiave di decodifica il dominio di secondo livello, è necessario modellare un WAYFProfile con un WAYFRequestAdapter così, costituito:

• sourceType: REQUEST_URL
• infoSourceName: DOMAIN_L2

Considrazioni su WAYFProfile di tipo REQUEST_URL e attiivtà di sviluppo

Come visto in precedenza è possibile modellare un WAYFProfile custom in modo tale che l'informazione discriminante sia reperita da una parte dell'URL di richiesta (es. il dominio di secondo livello). Poichè i codici associati ai vari portali di esposizione sono modellati nell'oggetto PortalProfile, una volta generato il progetto affinchè il meccanismo WAYF funzioni correttamente è necessario che l'URL di richiesta rispetti con precisione tali specifiche.

Ad esempio se nel PortalProfile viene configurato il codice "sistemapiemonte.it", il virtual host su cui deve essere esposto l'applicativo deve appartenere a tale dominio di rete.

Questo non rappresenta ovviamente un problema per gli ambienti di esercizio, ma potrebbe essere un problema se le attività di sviluppo sono effettuate utilizzando ad esempio un virtual-host situato su una rete differente.

Per superare questo problema è disponibile una modalità alternativa attivabile non a tempo di generazione ma a tempo di build, ovvero attivabile solo sugli ambienti di sviluppo, ad esempio.

La modalità si attiva tramite una proprietà di nome devmode che, se impostata a true nel file di properties specifico di un determinato ambiente di installazione, attiva un meccanismo di risoluzione alternativo che entra in gioco come "salvagente" nel caso in cui l'informazione discriminante non sia reperibile o decodificabile correttamente a partire dalla fonte specificata

Una volta abilitata la modalità di sviluppo il meccanismo di riserva deve essere innescato manualmente inserendo nella URL di accesso un parametro HTTP che:

• si chiama come la proprietà infoSourceName modellata nell'oggetto WAYFRequestAdapter (nell'esempio: DOMAIN_L2)
• ha come valore il codice configurato nell'oggetto PortalProfile (nell' es. sistemapiemonte.it o ruparpiemonte.it)

(in pratica il meccanismo di riserva è equivalente ad un WAYFRequestAdapter di tipo REQUEST_PARAM corrispondente a quello effettivamente modellato)

Pertanto per far funzionare, ad esempio, il meccanismo di WAYF su un'applicazione installata su un apache con virtual-host non conoforme alle specifiche di nome dominio, occorrerà effettuare la prima chiamata in modo simile al seguente:

http://127.0.0.1:17000/mycontext/?DOMAIN_L2=sistemapiemonte.it

(dove ovviamente l'hostname/ip dell'apache e il nome del contesto sono solo esemplificativi, mentre il nome del parametro e il suo valore sono quelli dell'esempio di cui sopra).

N.B: si consiglia di non attivare la modalità di sviluppo per i pacchetti destinati ad ambienti dove ciò non sia necessario. In ogni caso, però, il meccanismo di riserva interviene solo in caso di fallimento del meccanismo principale.