|
<< Click to Display Table of Contents >> Navigation: Admin Menu > Login & Role Assignment |
Login & Role Assignment provides access to the login parameters used to authenticate and authorise system users.
All users must successfully login to the system in order to use it. The login procedure authenticates the user.
Other than the login parameters, it is important to understand a login record contains no other detail about the participant. That is the role of the Participant record.
It is possible to have a login that is not a U3A participant and it is also possible to have a U3A participant that does not have a login. Typically however, they are linked and that linkage is created when both the login and the participant records share the same email address.
It is possible for a participant to have two logins. Usually, they are used as follows...
1.The first is the participant's real personal email address. It is used for non-administrative purposes; to gain access to the Member Portal and receive email.
2.the second is used to access the Administration Portal. This can be a real email address or a Domain Login (see below). In either case both use the U3A's registered domain in their address.
The password is never stored on the login record. Rather a password hash is stored. A hash is a seemingly random sequence of characters generated from the actual password plus a predefined seed value.
To validate a password, the system takes the entered password and re-generates the hash value. If the re-generated value equals the stored value the entered password passes validation.
Importantly, it is currently impossible to reverse the process. You cannot obtain the password from the stored hash value.
Therefore, user passwords cannot be obtained by hacking the database.
Password hashing is a specific form of a more generalised Key Derivation Function (KDF). For a in-depth discussion of password storage refer Password Storage Cheat Sheet.
Roles authorise the user to allow or deny them access to procedures and modules within the system (that is, menu items).
Those assigned a role will have access to the Administrative Portal. Those without a role will have access to the Member Portal only. Roles are assigned using this procedure.
The available roles are...
Role |
Description |
|---|---|
Security Admin |
Access to this procedure and Tenant Details procedure. |
System Admin |
Access to the Admin menu column except this procedure. |
Course & Class |
Access to the Course menu column |
Membership |
Access to the Participation menu column but not it's Fees & Receipting sub-menu |
Accounting |
Access to the Participation menu and it's Fees & Receipting sub-menu |
Office |
Access to the Portal (Admin) menu item. |
Report View |
Access to the Reports Menu column. |
A login may have multiple roles. In this case the authorisations will be combined. Thus a login with the Security Admin role and the System Admin role will have access to all items on the Admin menu column.
The above table also identifies a hierarchy that for the most part is honoured. Thus, the System Admin has access not only to the Admin menu column but also all menu items to the right of it (or, below it in the table above). The exceptions to this are...
1.The Security Admin role has no access to anything other than this procedure. A purist would consider it a security risk assigning a Security Admin access to any other role. It is also possible for the U3A group to outsource the Security Admin role to a third party without granting access to any other system function.
2.The Office role has no access to any other menu columns.
The role with the least access is the Report View role. It has read-only access to the reports menu column only.
The following buttons are located at the top of the procedure and are typically used to perform an action on a group of participants...
Button |
Description |
|---|---|
Create Domain Login |
A domain login is a login not associated with a physical email address and is typically used to provide a group of persons the same login and password to the system. As such they should be sparingly used if at all. They should never be used with administrative function roles. An example might be, office@myU3A.org.au to allow a group of office volunteers access to the administrative portal and the Office role. |
Populate Logins |
Use Populate Logins to create login records for participants that have been manually created via Add/Edit Participants. It will create a login record for every participant that does not have a login record using the Email Address and Member Identity as the password. |
Set Email Confirmed |
Intended to be used to set the Email Confirmed flag should a participant be not able to respond to their login/password reset confirmation email. This option should be only used after ensuring the email address is correct. Emails can be confirmed as correct by using the Postmark third-party website, To use this option, select the required participant(s) and then click. |
Reset Password |
To reset password(s), select the required login record(s) and then click. The password will be reset to the participant's Member Identity. Password reset is meant to be a self-service activity. Use this option only when problems persist. |
Use the grid's Edit / Delete buttons to maintain logins. Note that logins can only be created using the Populate Logins button as described above or by the participant registering their login via the Member or Administration Portals. Self-registration is the normal form of creating a login.
Field |
Description |
|---|---|
User Roles |
Select from the list provided, the roles to be assigned to the participant. Leave blank for Member Portal access only. |
Is Email Confirmed? |
Tick to set the email confirmation flag as confirmed. Once set, this field cannot be changed. |
Password |
Enter a strong password, or leave blank if the password is unchanged |
Confirm Password |
Re-enter the password, or leave blank if the password is unchanged |