Identity and Access Management (IAM)Project Page
This page is for the development and sharing of ideas concerning IAM for the NZ Ministry of Educations MLE Project.
User Scenarios
Scenario # 1
Case Study
School A
- is not in a cluster
- has the LMS Moodle hosted onsite
- has a SMS onsite
Learner requirements
- Single Sign On to Moodle, Schoolzone email, plus other applications?? (browser session-based)
- Is able to change own password
School Administrator requirements
- Control Panel that allows, user disablement, changing of user passwords, allow/disallow user to change passwords, enable/disable applications available for SSO
- Provisioning of user accounts in Moodle and other SSO applications using data from SMS
- Able to add and remove applications to SSO 'group'
- User details (where applicable) are obtained automatically from SMS
- User list is synchronous with user list in SMS
- Staff accounts are handled in same way as pupils
- Roles are available that allow granularity of permissions in different SSO applications
- Able to add users who are not in the SMS
|
Scenario # 2
Case Study
| School B
As school 'A' but:
- is in a cluster of 11 schools
- has the LMS Moodle hosted offsite (must allow for hosting to be by organisations other than vendors). The Moodle instance is shared between all 11 cluster schools
- has a SMS onsite
Learner requirements
School Administrator requirements
- Same as school 'A' plus:
- Require attributes of school B users to be editable only by school B admin (apart from users being able to edit their own password)
|
Scenario # 3
Case Study
School C
- is not in a cluster
- has the LMS Knowledgenet/myclasses/spike@school/Ultranet/Moodle hosted by a vendor
- has a SMS onsite
Learner requirements
Same as school 'A' i.e.:
- Single Sign On to Moodle, Schoolzone email, plus other applications?? (browser session-based)
- Is able to change own password
School Administrator requirements
- Control Panel that allows, user disablement, changing of user passwords, allow/disallow user to change passwords, enable/disable applications available for SSO
- Provisioning of user accounts in Moodle and other SSO applications using data from SMS
- Able to add and remove applications to SSO 'group'
- User details (where applicable) are obtained automatically from SMS
- User list is synchronous with user list in SMS
- Staff accounts are handled in same way as pupils
- Roles are available that allow granularity of permissions in different SSO applications
- Able to add users who are not in the SMS
|
Scenario # 4
Case Study
| School D
As school 'A' but:
- Does not have an LMS onsite or offsite
- has a SMS onsite
Learner requirements
- Single Sign On to Schoolzone email, plus other applications?? (browser session-based)
- Is able to change own password
School Administrator requirements
- Same as school 'A' minus reference to Moodle/LMS
|
Scenario # 5
Case Study
School E
- is not in a cluster
- has its own choice of LMS (Blackboard/Angel/FirstClass/...)
- has a SMS onsite
- uses Google Apps for student email
- uses Google Apps for Student ePortfolios
Learner requirements
Same as school 'A' i.e.:
- Single Sign On to SMS, LMS, (browser session-based) with Windows Domain credentials used where available for browser SSO
- Is able to change own password
- Consistency of SSO behaviour across multiple web browsers and devices (inc iPhones, PDAs etc)
School Administrator requirements
- Control Panel that allows, user disablement, changing of user passwords, allow/disallow user to change passwords, enable/disable applications available for SSO
- Control Panel that shows user last login to each application
- Provisioning of user accounts in LMS and other SSO applications using data from SMS
- Able to add and remove applications to SSO 'group'
- User details (where applicable) are obtained automatically from SMS
- User list is synchronous with user list in SMS
- Roles are available that allow granularity of permissions in different SSO applications
|
