Description of user administration at Uniarts Helsinki
This document describes the functionalities and key data content of the UniAulis register (general access rights database) and user databases (LDAP and eDIR directories) of University of the Arts Helsinki (Uniarts Helsinki).
1. Connection between the user database and the basic registers
1.1. Student register
It is assumed that the information in the student register is up to date.
How is the user database connected to the student register?
- Information about individuals is read from Peppi (an integration database updated hourly) to the UniAulis system (general access rights database).
- Information read from Peppi is enriched by the UniAulis system. The enriched information is read in real time into the eDIR metadirectory of the IDM system using the JDBC driver.
- From the eDIR metadirectory, user and group information is provisioned (in real time) to the LDAP authentication directory. Shibboleth IdP is connected to the LDAP authentication directory.
1.1.1. New students
How is the information of a new student updated from the student register to the user database?
When is a new student provided with a username/student role?
What happens to the username if the new student does not accept the study place or accepts the study place but registers as a non-attending student?
- All new students who have accepted a study place are automatically created a username in the general access rights database (UniAulis), based on the information about attendance or non-attendance stored in Peppi.
- A username is created for new students regardless of whether they register as an attending student or as a non-attending student.
- If a study place is not accepted, a username is not created.
- In principle, usernames are provided through the IT access right service of University of the Arts Helsinki. Identification through the Suomi.fi service is required.
- In exceptional cases, a username may be given to a student at the IT support desk. The student must show an ID.
1.1.2. Changed student information
How is changed student information updated from the student register to the user database?
- Changed information is updated automatically: Peppi (integration database) –> UniAulis –> eDir metadirectory –> LDAP authentication directory (–> Shibboleth IdP).
1.1.3. When a student is no longer a student
In the eyes of the organisation (e.g. administration of student affairs), when is a student no longer a student?
- After the student graduates?
- When the semester changes and the student has not registered for attendance?
- When the student announces that they will discontinue their studies?
How long after the above events does it take before the organisation (e.g. IT administration) turns off the student’s username and removes the student role?
Academic affairs administration:
- If a student does not register their attendance by the deadline, they lose their right to study.
- If they want to continue their studies later, they must submit a written application to the Academy to be re-admitted as a student.
- After graduation, the right to study ceases at the end of the semester in which the student graduated.
IT administration:
- In all of the above cases, usernames have a so-called grace period (8 months/240 days).
- A username is turned off 8 months after the end of the last semester attended or unattended.
- The student role is removed from the username (Student –> Affiliate) after the first month of the grace period.
1.2. Personnel register
How is the user database connected to the personnel register?
- Information about individuals is read from Peppi (an integration database updated hourly) and the Mepco HR system to the UniAulis system (general access rights database).
- This read information is enriched by the UniAulis system. The enriched information is read in real time into the eDIR metadirectory of the IDM system using the JDBC driver.
- From the eDIR metadirectory, user and group information is provisioned (in real time) to the LDAP authentication directory. Shibboleth IdP is connected to the LDAP authentication directory.
1.2.1. New employees
How is the information of a new employee updated from the personnel register to the user database?
When is a new employee provided with a username/personnel role?
- A username is automatically created for a new employee in the general access rights database (UniAulis), based on the validity of the employment relationship.
- In principle, usernames are provided through the IT access right service of University of the Arts Helsinki. Identification through the Suomi.fi service is required.
- In exceptional cases, a username may be given to an employee at the IT support desk. The employee must show an ID.
1.2.2. Changed employee information
How is the information of an employee updated from the personnel register to the user database?
- Changed information is updated automatically: Peppi (integration) and Mepco HR –> UniAulis –> eDir metadirectory –> LDAP authentication directory (–> Shibboleth IdP).
1.2.3. When an employee is no longer an employee
Personnel roles are removed at the end of the employment relationship. The username is also locked if there is no other reason to keep it unlocked (e.g. a valid student role).
Teaching staff is the exception. A grace period (1.5 years) is applied to their usernames. Employee roles are removed from the username at the start of the grace period (Faculty –> Affiliate).
1.3. Other users and timeliness of their personal data
Are there some other users in the organisation who have a username and are able to log in to Haka infrastructure services through the Identity Provider (Shibboleth IdP) server? (Researchers of the Academy of Finland? Restaurant staff? Persons undergoing non-military service? Adjunct professors? Alumni? Emeriti? Library customers?)
What type of application and approval system is connected to these usernames?
How is the timeliness of their user information and turning off/updating of role information ensured?
Users who are not natural persons (e.g. department clubs) are not end-users as intended in the Haka infrastructure and they should not be allowed to log in to services through the Identity Provider server.
Usernames can be created for external users, if necessary. This type of usernames are always fixed-term and roles are determined on a case-by-case basis.
2. Authentication of identity
2.1. In connection with providing the username
How is the identity of a new user verified when they are provided with a username?
- Suomi.fi identification (IT access right service of University of the Arts Helsinki).
- Showing ID (IT support desk in exceptional cases)
2.2. Logging in using a username
Quality requirements for password authentication
Available authentication methods more secure than passwords, if available.
Password quality requirements:
- At least 10 characters long
- At least one UPPERCASE letter (A–Z)
- At least one lowercase letter (a–z)
- At least one number (0–9)
- Cannot contain your username
- Cannot contain the name of the user
You must change the password at least once a year.
3. Information available in the user database
Select “Saatavuus” (Availability) if the personal data in question is up to date and available over the Identity Provider server. In the section “Miten ajantasaisuus turvataan” (How is timeliness secured), you can for example refer to systems mentioned in chapter 1. If the organisation has its own attributes (not in accordance with funetEduPerson) that are externally visible in the Identity Provider server, add them to the end of the table. If necessary, add a link to a document that describes the own attribute scheme in detail.
| cn / commonName | X | UniAulis | Created on the fly on the IdP server from the user’s first name and last name | |
| Description | | |||
| displayName | X | UniAulis | Created on the fly on the IdP server from the user’s first name and last name | |
| employeeNumber | X | UniAulis | Only for the staff; not available for students | |
| facsimileTelephoneNumber | | |||
| givenName | X | UniAulis | Mandatory; First name | |
| homePhone | | |||
| homePostalAddress | | |||
| jpegPhoto | | |||
| l / localityName | UniAulis | Only for the staff; not available for students | | |
| labeledURI | | |||
| X | UniAulis | firstname.lastname@uniarts.fi | ||
| mobile | | |||
| o / organizationName | | |||
| ou / organizationalUnitName | | |||
| postalAddress | | |||
| postalCode | | |||
| preferredLanguage | X | UniAulis | Options: FI/SV/EN | |
| seeAlso | | |||
| sn / surname | X | UniAulis | Mandatory | |
| street | | |||
| telephoneNumber | X | UniAulis | Only for the staff; not available for students | |
| title | X | UniAulis | Only for the staff; not available for students | |
| uid | X | UniAulis | Username | |
| userCertificate | | |||
| eduPersonAffiliation | X | UniAulis | Student, Faculty, Staff, Employee, Member, Affiliate (multi value) | |
| eduPersonPrimaryAffiliation | X | UniAulis | Student/Faculty, Staff/Employee/Member/Affiliate (single value) | |
| eduPersonEntitlement | X | UniAulis | urn:mace:dir:entitlement:common-lib-terms | |
| eduPersonNickName | | |||
| eduPersonOrgDN | | |||
| eduPersonOrgUnitDN | | |||
| eduPersonPrimaryOrgUnitDN | | |||
| eduPersonPrincipalName | X | UniAulis, Ei vaihdu | Mandatory | abc12345@uniarts.fi, example@siba.fi, example@teak.fi |
| eduPersonScopedAffiliation | | |||
| eduPersonTargetedID | | |||
| schacMotherTongue | | |||
| schacGender | | |||
| schacDateOfBirth | | |||
| schacPlaceOfBirth | | |||
| schacCountryOfCitizenship | | |||
| schacHomeOrganization | X | UniAulis | uniarts.fi | |
| schacHomeOrganizationType | X | UniAulis | urn:mace:terena.org:schac:homeOrganizationType:fi:university | |
| schacCountryOfResidence | | |||
| schacUserPresenceID | | |||
| schacPersonalUniqueCode | | |||
| schacPersonalUniqueID | X | Personal identity code with schac prefix. Submitted only to certain SPs. | | |
| schacUserStatus | | |||
| funetEduPersonHomeOrganization | superseded | | ||
| funetEduPersonStudentID | superseded | | ||
| funetEduPersonIdentityCode | superseded | | ||
| funetEduPersonDateOfBirth | superseded | | ||
| funetEduPersonTargetDegreeUniversity | superseded | | ||
| funetEduPersonTargetDegreePolytech | superseded | | ||
| funetEduPersonTargetDegree | | |||
| funetEduPersonEducationalProgramUniv | superseded | | ||
| funetEduPersonEducationalProgramPolytech | superseded | | ||
| funetEduPersonProgram | | |||
| funetEduPersonMajorUniv | superseded | | ||
| funetEduPersonOrientationAlternPolytech | superseded | | ||
| funetEduPersonSpecialisation | | |||
| funetEduPersonStudyStart | | |||
| funetEduPersonPrimaryStudyStart | | |||
| funetEduPersonStudyToEnd | | |||
| funetEduPersonPrimaryStudyToEnd | | |||
| funetEduPersonCreditUnits | | |||
| funetEduPersonECTS | | |||
| funetEduPersonStudentCategory | | |||
| funetEduPersonStudentStatus | | |||
| funetEduPersonStudentUnion | | |||
| funetEduPersonHomeCity | | |||
| funetEduPersonEPPNTimeStamp | | |||
| funetEduPersonLearnerId | X | UniAulis | | |
| funetEduPersonGivenNames | X | UniAulis | All first names, if available. If not, only the first name. | |
| funetEduPersonFullName | X | UniAulis | Created on the fly on the IdP server from the user’s first names and last name | |
| electronicIdentificationNumber | | |||
| nationalIdentificationNumber | X | UniAulis | Personal identity code. Submitted only to certain SPs. | |
| |