Actions

Difference between revisions of "Developer Area/Specifications in Development/Moving between SSO institutions"

From Mahara Wiki

< Developer Area‎ | Specifications in Development
(Work to Do)
(change parked institutions notion, and update due to already established functionality in mahara)
Line 13: Line 13:
 
two or more institutions that use SSO.
 
two or more institutions that use SSO.
  
Inbetween each transition, we have a parking institution, which is described below.
+
Inbetween each transition, we have a tag attached to each user showing what institution it came from.
  
An extra option will be added to the Institution->Members screen, where new institution admins can transfer users from parked institutions.
+
An extra option will be added to the Institution->Members screen, where new institution admins can transfer users into their institution.
  
 
==Work flows==
 
==Work flows==
Line 26: Line 26:
 
The workflow would be as follows:
 
The workflow would be as follows:
  
# Original Institute admin sends student to a parking inst using internal auth
+
# Original Institute admin sends student to the default institution using internal auth (with a tag saying where they came from)
# credentials don't change
+
# credentials don't change, only email sent says leaving institution
# 2nd institute provider uses the Institutions->Members screen to move students from parking to their institution
+
# 2nd institute provider uses the Institutions->Members screen to move students from default to their institution
 
# auth will be the same as the internal auth already set
 
# auth will be the same as the internal auth already set
  
 +
 +
;ToDo change this from parkedinst
 
There could also be a CSV file workflow with the following fields
 
There could also be a CSV file workflow with the following fields
  
Line 50: Line 52:
 
The workflow for this would be as follows:
 
The workflow for this would be as follows:
  
# Original Institute admin sends student to a parking inst using internal auth
+
# Original Institute admin sends student to the default institution using internal auth
# credentials don't change
+
# credentials don't change, only email sent says leaving institution
# 2nd SSO provider uses the Institutions->Members screen to move students from parking to their institution
+
# 2nd SSO provider uses the Institutions->Members screen to move students from default to their institution
 
# Mahara will change auth from internal auth to 2nd SSO
 
# Mahara will change auth from internal auth to 2nd SSO
 
# * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara
 
# * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara
 +
# The email details etc will change automatically when user logs in the first time if the relevant checkbox is ticked
  
 
+
;ToDo change this from parkedinst
 
This workflow could also include a CSV file upload with the following contents
 
This workflow could also include a CSV file upload with the following contents
  
Line 75: Line 78:
 
The workflow for this would be as follows:
 
The workflow for this would be as follows:
  
# Original SSO Provider sends student to a parking inst with internal auth
+
# Original SSO Provider sends student to the default with internal auth
# Mahara generates a password for that student that gets emailed to them, changed on first login.
+
# mahara sends them a change password link (if they don't already have a password) (this is already part of mahara)
# 2nd institute provider uses the Institutions->Members screen to move students from parking to their institution
+
# mahara sends them an email saying they have left the institution
 +
# 2nd institute provider uses the Institutions->Members screen to move students from default to their institution
 
# auth will be the same as the internal auth already set in step 2
 
# auth will be the same as the internal auth already set in step 2
  
 +
;ToDo change this from parkedinst
 
There could also be a CSV file workflow with the following fields
 
There could also be a CSV file workflow with the following fields
  
Line 98: Line 103:
 
The workflow for this would be as follows
 
The workflow for this would be as follows
  
# Original SSO Provider sends student to a parking institution with internal auth
+
# Original SSO Provider sends student to the default institution with internal auth
# Mahara generates a password for that student that gets emailed to them, changed on first login.
+
# mahara sends them a change password link (if they don't already have a password) (this is already part of mahara)
 +
# mahara sends them an email saying they have left the institution
 
# 2nd SSO provider uses the Institutions->Members screen to move students from parking to their institution
 
# 2nd SSO provider uses the Institutions->Members screen to move students from parking to their institution
# Mahara will change auth from internal auth to 2nd SSO
+
# Mahara will change auth from internal auth to 2nd SSO (this will need to be done)
 
# * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara
 
# * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara
 +
# The email details etc will change automatically when user logs in the first time if the relevant checkbox is ticked
  
 +
;ToDo change this from parkedinst
 
This workflow could also include a CSV file upload with the following contents
 
This workflow could also include a CSV file upload with the following contents
  
Line 112: Line 120:
 
A CSV file with only username field can take users out of institution and put them in their parking institution.
 
A CSV file with only username field can take users out of institution and put them in their parking institution.
  
===Parking Institution===
+
===Tagging users with last institution===
  
A dummy institution that maps to the old institution, but only uses internal auth.
+
When a user leaves an institution, a tag will be attached to them saying what institution they were in last.
  
Each institution has it's own parking institution.
+
This can be done with an extra field in the usr table, null by default, and holds the institution name of their last institution they left
 
 
The parking institution should either:
 
* be created when institution is created
 
* first time a user is moved into it
 
* institutions have an option to have one, which would create/remove it when enabled/disabled.
 
 
 
When a user is put into this institution, they have a password generated if they don't already have one, this is then emailed to them.
 
They are forced to change on first login.
 
 
 
The automatically generated password could be supplied in the csvfile manually?
 
  
 +
Another way this could be done is have an extra table linking user ids to institution names.
 +
This will show all (or limit to 5, 10, ??) the last institutions they were in.
  
 +
This will need updated hooks when a user leaves an institution.
  
 
==Summary==
 
==Summary==
Line 134: Line 135:
 
===Work to Do===
 
===Work to Do===
  
* Create notion of parked institution
+
* Create notion of previous institutions for users
** Most likely a database table, links to old institution (may have multiple per institution
+
** Most likely a database table, links to old institution
** Decide when/how it is created, and possibly removed
+
** Decide when/how it is created, and possibly removed, and whether size is limited (ie only last 5, 10, etc)
  
 
* Change Administration->Institution->Members page
 
* Change Administration->Institution->Members page
** Add dropdown option "Move members to parking institution" (or similar wording)
+
** Add dropdown option "Move members to default institution" (or similar wording)
 
*** When the remove button is clicked, all users are moved to the parking institution (according to workflow above)
 
*** When the remove button is clicked, all users are moved to the parking institution (according to workflow above)
** Add dropdown option "People who are in a parked institution" (or similar wording)
+
** Add dropdown option "People who are in default institution" (or similar wording)
*** When that option is selected, the search field at the bottom can search through parked institutions
+
*** When that option is selected, the search field at the bottom can search through previous institutions
*** The display would be "First Last (user) (parkedinstitution)"
+
*** The display would be "First Last (user) (last institution)"
 
*** When the add button is clicked, all users are moved to the institution according to the above workflows
 
*** When the add button is clicked, all users are moved to the institution according to the above workflows
 
  If moving to an SSO institution, then the admins will manually have to go and change the remote username
 
  If moving to an SSO institution, then the admins will manually have to go and change the remote username
  
* Implement option for uploading CSV's to do the same workflow as the first bullet point
+
 
 +
* Implement option for uploading CSV's to do the same workflow as the first bullet point (out of scope at the moment)
  
 
* Review of any code produced
 
* Review of any code produced
Line 153: Line 155:
 
===CSV Files===
 
===CSV Files===
  
 +
* Out of scope at the moment
 +
 +
;ToDo need to change this from parking institutions
 
Moving to parking institution
 
Moving to parking institution
  

Revision as of 16:48, 7 June 2011

ToDo

This will show a workflow of how you would move users between different institutions with SSO capabilities.

There are four different types of moves.

  • Simple -> Simple
  • Simple -> SSO
  • SSO -> Simple
  • SSO -> SSO

There is also the case when a user wants to be part of two or more institutions that use SSO.

Inbetween each transition, we have a tag attached to each user showing what institution it came from.

An extra option will be added to the Institution->Members screen, where new institution admins can transfer users into their institution.

Work flows

Simple -> Simple

This is moving users from an internal auth method to another institution that uses internal auth.

The workflow would be as follows:

  1. Original Institute admin sends student to the default institution using internal auth (with a tag saying where they came from)
  2. credentials don't change, only email sent says leaving institution
  3. 2nd institute provider uses the Institutions->Members screen to move students from default to their institution
  4. auth will be the same as the internal auth already set


ToDo change this from parkedinst

There could also be a CSV file workflow with the following fields

username, parkedinstitution

which will take username out of parkedinst

A CSV file with only username field can take users out of institution and put them in their parking institution.


Simple -> SSO

This is moving users from an internal auth method to an institution that uses SSO.

This would happen if a student enrols in a school that uses SSO, and they already had a portfolio they want to keep.

The workflow for this would be as follows:

  1. Original Institute admin sends student to the default institution using internal auth
  2. credentials don't change, only email sent says leaving institution
  3. 2nd SSO provider uses the Institutions->Members screen to move students from default to their institution
  4. Mahara will change auth from internal auth to 2nd SSO
  5. * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara
  6. The email details etc will change automatically when user logs in the first time if the relevant checkbox is ticked
ToDo change this from parkedinst

This workflow could also include a CSV file upload with the following contents

username, parkedinstitution, remoteusername (this field is optional, defaults to username)

This will take the user from the parked institution, and change their remoteusername if supplied.

A CSV file with only username field can take users out of institution and put them in their parking institution.

SSO -> Simple

This is moving users from an institution that uses SSO to a simple internal auth method.

This would happen when a student leaves a school for example. They would still want to keep their portfolio

The workflow for this would be as follows:

  1. Original SSO Provider sends student to the default with internal auth
  2. mahara sends them a change password link (if they don't already have a password) (this is already part of mahara)
  3. mahara sends them an email saying they have left the institution
  4. 2nd institute provider uses the Institutions->Members screen to move students from default to their institution
  5. auth will be the same as the internal auth already set in step 2
ToDo change this from parkedinst

There could also be a CSV file workflow with the following fields

username, parkedinstitution

which will take username out of parkedinstitution

A CSV file with only username field can take users out of institution and put them in their parking institution.

SSO -> SSO

This is moving users from one institution that uses SSO to another institution that uses SSO.

This would happen when a student leaves one school and enrols in another. They want their portfolio to follow them.

The workflow for this would be as follows

  1. Original SSO Provider sends student to the default institution with internal auth
  2. mahara sends them a change password link (if they don't already have a password) (this is already part of mahara)
  3. mahara sends them an email saying they have left the institution
  4. 2nd SSO provider uses the Institutions->Members screen to move students from parking to their institution
  5. Mahara will change auth from internal auth to 2nd SSO (this will need to be done)
  6. * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara
  7. The email details etc will change automatically when user logs in the first time if the relevant checkbox is ticked
ToDo change this from parkedinst

This workflow could also include a CSV file upload with the following contents

username, parkedinstitution, remoteusername (this field is optional, defaults to username)

This will take the user from the parked institution, and change their remoteusername if supplied.

A CSV file with only username field can take users out of institution and put them in their parking institution.

Tagging users with last institution

When a user leaves an institution, a tag will be attached to them saying what institution they were in last.

This can be done with an extra field in the usr table, null by default, and holds the institution name of their last institution they left

Another way this could be done is have an extra table linking user ids to institution names. This will show all (or limit to 5, 10, ??) the last institutions they were in.

This will need updated hooks when a user leaves an institution.

Summary

Work to Do

  • Create notion of previous institutions for users
    • Most likely a database table, links to old institution
    • Decide when/how it is created, and possibly removed, and whether size is limited (ie only last 5, 10, etc)
  • Change Administration->Institution->Members page
    • Add dropdown option "Move members to default institution" (or similar wording)
      • When the remove button is clicked, all users are moved to the parking institution (according to workflow above)
    • Add dropdown option "People who are in default institution" (or similar wording)
      • When that option is selected, the search field at the bottom can search through previous institutions
      • The display would be "First Last (user) (last institution)"
      • When the add button is clicked, all users are moved to the institution according to the above workflows
If moving to an SSO institution, then the admins will manually have to go and change the remote username


  • Implement option for uploading CSV's to do the same workflow as the first bullet point (out of scope at the moment)
  • Review of any code produced

CSV Files

  • Out of scope at the moment
ToDo need to change this from parking institutions

Moving to parking institution

username, password (optional)
  • Moves username into parking institution.
    • If password already exists for that user, keep it (or maybe change if supplied in CSV??)
    • Otherwise, if password is supplied in CSV, change to that, notify user
    • Otherwise, generate password, notify user
    • Change auth method to internal


Moving from parking institution

username, parkedinstitution, remoteusername (this field is optional, defaults to username)
  • Moves username from parkedinstitution
    • If moving to an SSO institution, change remoteusername (or use default of username)
    • Change auth method to new institution


Out of scope

Multiple SSO

  • Wishlist

This happens when a user is part of two institutions that use SSO, and they want their portfolio to be the same in both of them