Proposals/Done/Moving between SSO institutions

Tthis feature was funded by the New Zealand Ministry of Education and implemented by Catalyst IT for Mahara 1.5

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 he 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 institution admin sends student to the default institution using internal auth (with a tag saying where he came from)
2. credentials don't change, only email is sent which says that the student is leaving the institution
3. 2nd institution admin uses the Institution Members screen to move students from the default institution to their institution
4. auth will be the same as the internal auth already set

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 institution admin sends student to the default institution using internal auth
2. credentials don't change, only email is sent which says that student is leaving institution
3. SSO provider uses the Institutions->Members screen to move students from default to their institution
4. Mahara will change auth from internal auth to SSO
5. If 2nd SSO institution has a different username on the remote side (authenticating side), they will need to update the user's remote username on Mahara manually
6. The email details etc will change automatically when user logs in the first time if the relevant checkbox is ticked

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 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 institution 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

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 put students into 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 manually
7. The email details etc will change automatically when user logs in the first time if the relevant checkbox is ticked

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 out of their own institution back to the default one (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
• Review of any code produced

If moving to an SSO institution, then the admins will manually have to go and change the remote username

If a user is in a second institution that is not an SSO institution, his membership is not affected. He stays in it.

Potential future functionality

currently out of scope, but possible enhancements:

• Implement option for uploading CSV's to do the same workflow more automated
• Multiple SSO: What 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