Attributi Identity Provider
Di seguito viene fornita la lista degli attributi (claims) che l’IdP dovrà configurare ed inviare a Cyber Guru tramite asserzione SAML in fase di autenticazione. I valori da utilizzare si riferiscono ad un sistema LDAP qualsiasi. Per i nomi degli attributi dell’LDAP utilizzato dall’Identity Provider si dovrà fare riferimento alla sua guida.
⚠️ | Qualsiasi altro attributo il cliente voglia utilizzare, non presente nella lista, dovrà essere discusso precedentemente con Cyber Guru |
Attributo: username
Valore: Identificativo univoco
Opzionale / Obbligatorio: Obbligatorio
Note: Identificativo univoco all’interno della piattaforma Cyber Guru per il tenant del Cliente. È utilizzato come chiave per l’associazione dell’utente e non può essere modificato a progetto avviato. E’ auspicabile, da parte del cliente, di utilizzare un campo del profilo utente che risulti immodificabile (per es., in Active Directory, ObjectGUID)
Aggiornamento: Al primo accesso
Attributo: firstName
Valore: Nome utente
Opzionale / Obbligatorio: Obbligatorio
Note: Solitamente identificato con user.givenName
Aggiornamento: Ad ogni accesso
Attributo: lastName
Valore: Cognome utente
Opzionale / Obbligatorio: Obbligatorio
Note: Solitamente identificato con user.surname
Aggiornamento: Ad ogni accesso
Attributo: email
Valore: email
Opzionale / Obbligatorio: Obbligatorio
Note: La mail dell’utente. Solitamente identificato con user.mail
Aggiornamento: Al primo accesso. In casi specifici in cui l’email dell’utente potrebbe cambiare nel tempo, è possibile effettuare una configurazione di tipo “Ad ogni accesso”
Attributo: locale
Valore: “IT”
Opzionale / Obbligatorio: Facoltativo
Note: Lingua del sistema del cliente
Aggiornamento: Al primo accesso
Attributo: country
Valore: Codice ISO a due lettere della country dell’utente
Opzionale / Obbligatorio: Facoltativo
Aggiornamento: Al primo accesso
Attributo: Team (*)
Valore: Nome Team di appartenenza
Opzionale / Obbligatorio: Obbligatorio se non precaricato
Note: È il nome del team (o dipartimento) all’interno del quale l’utente deve essere collocato ai fini delle statistiche e della gamification. Team che differiscono anche di un solo carattere sono considerati come team differenti. Se il team viene valorizzato nel precaricamento utenti allora questo attributo non deve essere considerato.
Aggiornamento: Ad ogni accesso
Attributo: Org_{Nome Org1} (**)
Valore: Nome Org 1
Opzionale / Obbligatorio: Facoltativo
Note: Organizzazione1 a cui appartiene l’utente
Aggiornamento: Ad ogni accesso
Attributo: Org_{Nome Org2}
Valore: Nome Org 2
Opzionale / Obbligatorio: Facoltativo
Note: Organizzazione 2 a cui appartiene l’utente
Aggiornamento: Ad ogni accesso
Attributo: Org_{Nome OrgN}
Valore: Nome Org N
Opzionale / Obbligatorio: Facoltativo
Note: Organizzazione N a cui appartiene l’utente
Aggiornamento: Ad ogni accesso
In particolare:
(*) La scelta del team utilizzato ai fini della gamification deve tenere in considerazione la cardinalità degli utenti all’interno dei vari team. Team che hanno 5 vs 100 utenti potrebbero inficiare il bilanciamento della competizione (i punteggi dei team sono calcolati in base alla media dei punteggi dei propri membri).
Se il “team” di appartenenza viene definito con altra categoria, diversa da quella contenuta dall’LDAP e precaricato nella piattaforma, allora il campo “Team” non dovrà essere valorizzato né tantomeno configurato all’interno della risposta dell’SP. Aggiornamenti del team e nuovi utenti dovranno necessariamente essere trattati con user list. Nella definizione dei team si dovrà tener presente quanto detto precedentemente sulla cardinalità.
(**) Gli attributi Organizzazione si riferiscono a ulteriori classificazioni degli utenti per esempio Organizational Unit, sede , Città, fascia di età etc. Tali classificazioni si possono usare in piattaforma come filtri nelle dashboard e nei report.