Table of Contents
Registration
Authors: Paolo Andreetto (INFN Padova), Eric Frizziero (INFN Padova)
Use cases
1: L'utente si registra per la prima volta ad Openstack tramite IDP
- 1.1: L'utente gia' registrato tramite IDP e mappato nell'utente "userLocalA" vuole accedere anche tramite username/psw
2: L'utente si registra per la prima volta ad Openstack tramite usr/psw
3: L'utente gia' registrato e mappato nell'utente "userLocalA" vuole chiedere l'affiliazione anche ad altri tenant
4: L'utente gia' registrato e mappato nell'utente "userLocalA" vuole accedere anche con IDP (anche nuovo IDP) ed essere mappato nello stesso utente "userLocalA"
5: L'utente gia' registrato e mappato nell'utente "userLocalA" vuole accedere anche con IDP (anche nuovo IDP) ed essere mappato in un utente locale diverso
Form di Registrazione
Form di Registrazione tramite IDP
Form di Registrazione tramite usr/psw
Descrizione Use cases
Use case 1: L'utente si registra per la prima volta ad Openstack tramite IDP
FASI: A) Accesso tramite IDP B) Registrazione utente C) Pre-accettazione registrazione D) Approvazione affiliazione tenant E) Approvazione registrazione utente
DESCRIZIONE USE CASE
(FASE A) L'utente si presenta con userIDP "user1", IDP "IDP1" e emailIDP1: user1@IDIP1
(FASE B) l'utente usa il form di registrazione per inserire le informazioni richieste tra cui l'affiliazione scegliendo tra (vedi descrizione form di registrazione):
- un tenant o piu' tra quelli esistenti
- un nuovo tenant da creare (privato o pubblico)
- il tenant GUEST
(FASE C) Se il CloudManager dopo eventuali controlli NON accetta la richiesta di registrazione, viene inviata un'email all'utente informandolo che la sua richiesta di registrazione non puo' essere accettata per uno dei seguenti motivi:
- persona non autorizzata ad accedere a questa infrastruttura cloud
In caso contrario la richiesta e' pre-accettata e il CloudManager sceglie per l'utente lo username “userLocalA” (uguale o diverso da quello proveniente dall'IDP).
(FASE D)
(D.1) Affiliazione "un tenant o piu' tra quelli esistenti"
Se l'affiliazione richiesta e' verso un tenant o piu' tra quelli esistenti, allora le richieste di affiliazione a ciascun tenant richiesto arriva al corrispondente TenantManager. Ciascun TenantManager approva o meno la richiesta di affiliazione pervenutali. Gli esiti delle singole approvazioni dei TenantManager arrivano al CloudManager che raccoglie gli esiti per comporre una risposta aggregata.
Se gli esiti sono tutti negativi (richiesta di affiliazione non accettata), viene inviata un'email all'utente informandolo che la sua richiesta di registrazione non puo' essere accettata per uno dei seguenti motivi:
- Le richieste di affiliazione non sono state accettate
Se almeno un esito e' positivo (richiesta di affiliazione accettata), allora il CloudManager:
(FASE E)
- crea l'utente locale "userLocalA"
- crea l'affiliazione di "userLocalA" con I tenant per cui la richiesta di affiliazione ha avuto esito positivo
- Viene inviata un'email all'utente informandolo che la sua richiesta di registrazione e' stata approvata, che il suo utente locale e' "userLocalA" e quali affiliazioni sono state accettate e quali invece respinte.
(D.2) Affiliazione a "un nuovo tenant da creare (privato o pubblico)" o "tenant GUEST"
Se l'affiliazione richiesta e' verso un nuovo tenant da creare o verso il tenant GUEST, allora la richiesta di affiliazione viene gestita dal CloudManager che fa le veci di TenantManager.
Se il CloudManager non da' esito positivo alla richiesta di affiliazione (richiesta di affiliazione non accettata), viene inviata un'email all'utente informandolo che la sua richiesta di registrazione non puo' essere accettata per uno dei seguenti motivi:
- Le richieste di affiliazione non sono state accettate
Altrimenti (richiesta di affiliazione accettata)
(FASE E) Se l'affiliazione richiede la creazione di un tenant, il CloudManager crea il tenant nuovo. Inoltre se il tenant richiesto deve essere pubblico (vedi form di registrazione), allora l'utente ne diviene TenantManager e il tenant viene inserito nella lista dei tenant pubblici.
Il CloudManager per terminare la fase di registrazione:
- crea l'utente locale "userLocalA"
- crea l'affiliazione di "userLocalA" con il tenant richiesto
- Viene inviata un'email all'utente informandolo che la sua richiesta di registrazione e' stata approvata, che il suo utente locale e' "userLocalA" e l'affiliazione al tenant richiesto.
Osservazioni:
a) Deve essere possibile per il CloudManager monitorare lo stato di approvazione delle varie richieste di affiliazione per utente.
b) Deve essere prevista la possibilita' di cambiare il TenantManager.
Use case 1.1: L'utente gia' registrato tramite IDP e mappato nell'utente locale "userLocalA" vuole accedere anche tramite username/psw
DESCRIZIONE USE CASE
L'utente accede tramite IDP alla Dashboard (mappato come "userLocalA") ed usando il pannello "Setting" imposta la sua password.
CONCLUSIONE:
Oltre che con l'IDP, l'utente ora potra' accedere anche con username “userLocalA” e la psw impostata.
Use case 2: L'utente si registra per la prima volta ad Openstack tramite usr/psw
DESCRIZIONE USE CASE
L'utente effettua la registrazione seguendo la descrione dello use case 1 a partire dalla (FASE B).
Use case 3: L'utente gia' registrato e mappato nell'utente locale "userLocalA" vuole chiedere l'affiliazione anche ad altri tenant
FASI: A) Pre-accettazione affiliazione B) Approvazione affiliazione tenant
DESCRIZIONE USE CASE
L'utente accede alla Dashboard (mappato come “userLocalA”) ed usando il pannello “Nuova Affiliazione Tenant” sceglie tra:
- un tenant o piu' tra quelli esistenti
- un nuovo tenant da creare (privato o pubblico)
(FASE A) Se il CloudManager dopo eventuali controlli NON accetta la nuova richiesta di affiliazione, viene inviata un'email all'utente informandolo che la sua nuova richiesta di affiliazione non puo' essere accettata.
(FASE B)
(B.1) Affiliazione "un tenant o piu' tra quelli esistenti"
Se l'affiliazione richiesta e' verso un tenant o piu' tra quelli esistenti, allora le richieste di affiliazione a ciascun tenant richiesto arriva al corrispondente TenantManager. Ciascun TenantManager approva o meno la richiesta di affiliazione pervenutali. Gli esiti delle singole approvazioni dei TenantManager arrivano al CloudManager che raccoglie gli esiti per comporre una risposta aggregata.
Se gli esiti sono tutti negativi (richiesta di affiliazione non accettata), viene inviata un'email all'utente informandolo che la sua richiesta di affiliazione non puo' essere accettata per uno dei seguenti motivi:
- Le richieste di affiliazione non sono state accettate
Se almeno un esito e' positivo (richiesta di affiliazione accettata), allora il CloudManager:
- crea l'affiliazione di "userLocalA" con i tenant per cui la richiesta di affiliazione ha avuto esito positivo
- Viene inviata un'email all'utente informandolo quali affiliazioni sono state accettate e quali invece respinte.
(B.2) Affiliazione "un nuovo tenant da creare (privato o pubblico)"
Se l'affiliazione richiesta e' verso un nuovo tenant da creare, allora la richiesta di affiliazione viene gestita dal CloudManager che fa le veci di TenantManager.
Se il CloudManager non da' esito positivo alla richiesta di affiliazione (richiesta di affiliazione non accettata), viene inviata un'email all'utente informandolo che la sua richiesta di affiliazione non puo' essere accettata per uno dei seguenti motivi:
- Le richieste di affiliazione non sono state accettate
Altrimenti (richiesta di affiliazione accettata)
Il CloudManager crea il tenant nuovo. Se il tenant richiesto deve essere pubblico, allora l'utente ne diviene TenantManager e il tenant viene inserito nella lista dei tenant pubblici.
Il CloudManager per terminare la fase di affiliazione:
- crea l'affiliazione di "userLocalA" con il tenant richiesto
- Viene inviata un'email all'utente informandolo che la sua richiesta di affiliazione e' stata approvata
Use case 4: L'utente gia' registrato e mappato nell'utente "userLocalA" vuole accedere anche con IDP (anche nuovo IDP) ed essere mappato nello stesso utente "userLocalA"
DESCRIZIONE USE CASE
L'utente accede alla Dashboard (mappato come "userLocalA") e nel pannello degli IDP accettati, preme il pulsante relativo all'IDP scelto. Viene contattato l'IDP per la verifica e la richiesta di accesso tramite IDP da parte dell'utente locale "userLocalA" arriva al CloudManager. Il CloudManager puo' approvare o meno la richiesta. All'utente viene inviata un'email per informarlo dell'esito dell'approvazione.
Use case 5: L'utente gia' registrato e mappato nell'utente "userLocalA" vuole accedere anche con IDP (anche nuovo IDP) ed essere mappato in un utente locale diverso
DESCRIZIONE USE CASE
L'utente effettua una nuova registrazione tramite IDP seguendo lo use case 1.
Descrizione Form di Registrazione
Form di Registrazione tramite IDP
Tutti i campi indicati con * sono obbligatori.
- UserNameIDP * (non editabile, forse anche da non visualizzare)
- EmailUtenteIDP * (editabile se vuoto)
- NomeUtente * (editabile se vuoto)
- CognomeUtente * (editabile se vuoto)
- Istituto * (editabile se vuoto)
- Telefono * (editabile se vuoto)
- NomeReferente/Responsabile_PD/LNL (editabile)
- ComboBoxSceltaTenant *
- CheckBox Accettazione Policy CloudPadovana *
Form di Registrazione tramite usr/psw
Tutti i campi indicati con * sono obbligatori.
- UserName * (editabile, e scrivere che e' una proposta di UserName)
- Password * (editabile)
- EmailUtente * (editabile)
- NomeUtente * (editabile)
- CognomeUtente * (editabile)
- Istituto * (editabile)
- Telefono * (editabile)
- NomeReferente/Responsabile_PD/LNL (editabile)
- ComboBoxSceltaTenant *
- CheckBox Accettazione Policy CloudPadovana *
— Eric Frizziero 2014/03/11 12:01