IdP Attributes

Below is the list of attributes (claims) that the IdP must configure and send to Cyber Guru via SAML assertion during the authentication phase. The values to be used refer to any LDAP system. For the names of the attributes of the LDAP used by the Identity Provider, reference should be made to its guide.

Attribute: username
Value: Unique identifier
Optional / Mandatory: Mandatory
Notes: Unique identifier within the Cyber Guru platform for the Client's tenant. It is used as a key for user association and cannot be modified once the project has started. It is advisable for the client to use a field in the user profile that is immutable (e.g., in Active Directory, ObjectGUID)
Update: On first access

Attribute: firstName
Value: User's first name
Optional / Mandatory: Mandatory
Notes: Usually identified as user.givenName
Update: On each access

Attribute: lastName
Value: User's last name
Optional / Mandatory: Mandatory
Notes: Usually identified as user.surname
Update: On each access

Attribute: email
Value: email
Optional / Mandatory: Mandatory
Notes: The user's email. Usually identified as user.mail
Update: On first access. In specific cases where the user's email may change over time, it is possible to configure it as “On each access”

Attribute: locale
Value: “IT”
Optional / Mandatory: Optional
Notes: Language of the client's system
Update: On first access

Attribute: country
Value: Two-letter ISO code of the user's country
Optional / Mandatory: Optional
Update: On first access

Attribute: Team (*)
Value: Name of the belonging Team
Optional / Mandatory: Mandatory if not preloaded
Notes: It is the name of the team (or department) within which the user must be placed for statistics and gamification purposes. Teams that differ by even a single character are considered different teams. If the team is populated during user preloading, then this attribute should not be considered.
Update: On each access

Attribute: Org_{Org Name 1} (**)
Value: Name of Org 1
Optional / Mandatory: Optional
Notes: Organization 1 to which the user belongs
Update: On each access

Attribute: Org_{Org Name 2}
Value: Name of Org 2
Optional / Mandatory: Optional
Notes: Organization 2 to which the user belongs
Update: On each access

Attribute: Org_{Org Name N}
Value: Name of Org N
Optional / Mandatory: Optional
Notes: Organization N to which the user belongs
Update: On each access

In particular:

(*) The choice of the team used for gamification purposes must take into account the cardinality of users within the various teams. Teams with 5 vs 100 users could affect the balance of the competition (team scores are calculated based on the average scores of their members).

If the belonging “team” is defined with another category, different from that contained in the LDAP and preloaded in the platform, then the “Team” field should not be populated or configured within the SP's response. Team updates and new users must necessarily be handled with a user list. In defining teams, the previously mentioned cardinality should be taken into account.

(**) Organization attributes refer to further classifications of users, for example, Organizational Unit, location, City, age group, etc. Such classifications can be used on the platform as filters in dashboards and reports.