Metropolia University of Applied Sciences user administration described
Version | Author | Data |
---|---|---|
0.7 | Jukka Veikkolainen | 13.6.2013 |
0.6 | Jukka Veikkolainen | 26.10.2010 |
0.5 | Jukka Veikkolainen | 27.1.2010 |
0.4 | Jukka Veikkolainen | 23.3.2009 |
0.3 | Jukka Veikkolainen | 19.3.2009 |
0.2 | Jukka Veikkolainen | 3.2.2009 |
This document discusses the general principles of the implementation of the freshness up-to-dateness of the user database and its data at a level that yields information sufficient to judge the quality and freshness of user information.
...
In this document the term "user database" refers to the end user attributes' collection available to the organization's Identity Provider server. The technical implementation of the user database can be e.g. an LDAP directory or a relational database or a combination of the two in such a way that the Identity provider server can import some of the attributes from the LDAP directory and some of them from over the JDBC from the student registryregister.
1. The link between the user database and the base
...
register
1.1.
...
Base register
The initial starting assumption is that the student registry identity Base register personal data is up-to-date.
How is the user database linked to the student registryBase register?
The student registry Base register is a Winha relational database, that is linked to the user database in real-time with triggers initiating data synchronization.
1.1.1 A new student
How is a new student's data updated from the student registry Base register to the user database?
A new student's data is updated in the user database in real-time. A username is created on the basis of the data automatically. If the person already has a username, a new username is not created.
When does a new student get a username/student role?
A new student gets a username after accepting the offer of admission. She will get a student role after registering as present.
What happens to the username if the new student does not accept the offer of admission or accepts it but registers as absent?
A username is not created if the student does not accept the offer. The username of a student registering as absent remains valid.
1.1.2 A change in a student's
...
data
How do changes in a student's information propagate from the student registry register to the user database?
A student's changed information is updated in the user database in real-time.
1.1.3 A student ceases to be a student
When does the organization (e.g. student administration) consider that a student no longer is a student...
...
How long does it take after the above mentioned events until the organization (e.g. student administration) close the student's user account or removes the student role?
a) Graduation is recorded in the study register after graduation meeting.
...
Logging in to the Haka infrastructure will be prevented immediately after the above recordings.
1.2. The staff
...
register
The personal data registry register is the HR system's relational database, and it is linked to the user database via a user interface showing the latest changes which are polled after short scheduled intervals.
1.2.1. A new employee
A new employee's data is updated in the user database almost in real-time. A username is created for the user on the basis of the data. If the person already has a username, a new username is not created.
The username is provided to the new employee during orientation.
1.2.2. A change in an employee's
...
data
Changed data is updated in the user database almost in real-time.
1.2.3. An employee ceases to be an employee
An employee ceases to be an employee after she no longer has a current work contract. At the same time also the permission to use the username in that role ends and logging in to the Haka infrastructure is prevented immediately.
1.3. Other users and the
...
up-to-dateness of their identity data
Are there other users in the organization who have a username and who can log in via the Identity Provider server to the Haka infrastructure services (The Academy of Finland researchers? the restaurant staff? persons undergoing non-military service? Docents? Alumni? Professor Professors emeriti? Library clients?). What kind of application and acceptance procedure do these usernames have? How is the users' user data freshness and closing/updating of role data ensured? Users who are not natural persons (e.g. student organizations) are not end users as meant by the Haka infrastructure and their logging in via the Identity Provider server must not be allowed.
Only Metropolia students and staff can log in to the Haka infrastructure services.
2. Confirming identity
2.1 When providing the username
How is a new users user's identity confirmed when she is provided with a username?
A student user gets her user information from Helpdesk, Study Affairs Office, or from the tutor at the beginning of studies. The student's identity is confirmed before providing her with the user information.An employee's get her user information from Helpdesk or her superior. The employee's identity is confirmed at the signing of the work contract and always when the person is not already known.infromation about her username by authenticating with a finnish netbanking account or a mobile certificate at http://salasana.metropolia.fi.
A student or an employee (who doesn´t have finnish netbank or mobile certificate) gets her user information by other means (instructions)
2.2. When a user logs in using a username
Quality requirements of password authentication. Possible other authentication methods stronger than password authentication.
The minimum length of the password is 8 characters.
3. Data available in the user database
Attribute | Availability | How is freshness secured | Else (e.g. interpretation guide) | |||
---|---|---|---|---|---|---|
cn / commonName | x | updated in real-time | MUST | |||
description |
|
|
| |||
displayName | x | updated in real-time | MUST | |||
employeeNumber |
|
|
| |||
facsimileTelephoneNumber |
|
|
| |||
givenName |
|
|
| |||
homePhone |
|
|
| |||
homePostalAddress |
|
|
| |||
jpegPhoto |
|
|
| |||
l / localityName |
|
|
| |||
labeledURI |
|
|
| |||
x |
|
| ||||
mobile | x | |||||
nationaldentificationNumber | x | |||||
o / organizationName |
|
|
| |||
ou / organizationalUnitName |
|
|
| |||
postalAddress |
|
|
| |||
postalCode |
|
|
| |||
preferredLanguage | x |
|
| |||
seeAlso |
|
|
| |||
sn / surname | x | updated in real-time | MUST | |||
street |
|
|
| |||
telephoneNumber |
|
|
| |||
title |
|
| ||||
uid | x |
|
| |||
userCertificate |
|
|
| |||
eduPersonAffiliation | x |
| What values available? | |||
eduPersonEntitlement |
|
|
| |||
eduPersonNickName |
|
|
| |||
eduPersonOrgDN |
|
| ||||
eduPersonOrgUnitDN |
|
|
| |||
eduPersonPrimaryAffiliation | x |
|
| |||
eduPersonPrimaryOrgUnitDN |
|
|
| |||
eduPersonPrincipalName | x | MUST | ||||
eduPersonScopedAddiliation | x |
| ||||
eduPersonTargetedID | x |
| ||||
schacMotherTongue |
|
|
| |||
schacGender |
|
| ||||
schacDateOfBirth |
|
|
| |||
schacPlaceOfBirth |
|
|
| |||
schacCountryOfCitizenship |
|
|
| |||
schacHomeOrganization | x | MUST. metropolia.fi | ||||
schacHomeOrganizationType | x |
| MUST. urn:mace: | |||
schacCountryOfResidence |
|
|
| |||
schacUserPresenceID |
|
|
| |||
schacPersonalUniqueCode |
|
|
| |||
schacPersonalUniqueID |
|
| x | |||
schacUserStatus |
|
|
| |||
funetEduPersonHomeOrganization |
|
| superseded | |||
funetEduPersonStudentID |
|
| superseded | |||
funetEduPersonIdentityCode |
|
| superseded | |||
funetEduPersonDateOfBirth |
| superseded | ||||
funetEduPersonTargetDegreeUniversity |
| superseded | ||||
funetEduPersonTargetDegreePolytech |
|
| superseded | |||
funetEduPersonTargetDegree |
|
|
| |||
funetEduPersonEducationalProgramUniv |
|
| superseded | |||
funetEduPersonEducationalProgramPolytech |
|
| superseded | |||
funetEduPersonProgram | x | updated in real-time |
| |||
funetEduPersonMajorUniv |
|
| superseded | |||
funetEduPersonOrientationAlternPolytech |
| superseded | ||||
funetEduPersonSpecialisation |
|
|
| |||
funetEduPersonStudyStart |
|
|
| |||
funetEduPersonPrimaryStudyStart |
|
| ||||
funetEduPersonStudyToEnd |
|
|
| |||
funetEduPersonPrimaryStudyToEnd |
|
|
| |||
funetEduPersonCreditUnits |
|
|
| |||
funetEduPersonECTS |
|
|
| |||
funetEduPersonStudentCategory |
|
|
| |||
funetEduPersonStudentStatus |
|
|
| |||
funetEduPersonStudentUnion |
|
| What values are available? | |||
funetEduPersonHomeCity |
|
|
| |||
funetEduPersonEPPNTimeStamp |
|
|
|
4. Other issues
4.1. Cardinality
One identity per real-life user, or one identity per role (e.g. a student-employee with two usernames)?
...
Freed eduPersonPrincipalNames are kept reserved for two years minimum.