Proposals/Done/Moving between SSO institutions: Difference between revisions
From Mahara Wiki
< Proposals | Done
(Created page with ";ToDo This will show a workflow of how you would move users between different institutions with SSO capabilities. There are three different types of moves. * Simple -> SSO * S…") |
(add in workflows, add in description of parking institution) |
||
Line 4: | Line 4: | ||
with SSO capabilities. | with SSO capabilities. | ||
There are | There are four different types of moves. | ||
* Simple -> Simple | |||
* Simple -> SSO | * Simple -> SSO | ||
* SSO -> Simple | * SSO -> Simple | ||
Line 11: | Line 12: | ||
There is also the case when a user wants to be part of | There is also the case when a user wants to be part of | ||
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. | |||
===Simple -> Simple=== | |||
This is moving users from an internal auth method to another | |||
institution that uses internal auth. | |||
The workflow would be as follows: | |||
# Original Institute admin sends student to a parking inst using internal auth | |||
# credentials don't change | |||
# 2nd institute provider uses the Institutions->Members screen to move students from parking to their institution | |||
# auth will be the same as the internal auth already set | |||
There could also be a CSV file workflow with the following fields | |||
username, parkedinst | |||
which will take username out of parkedinst | |||
A CSV file with only username field can take users out of institution and put them in the parking one. | |||
===Simple -> SSO=== | ===Simple -> SSO=== | ||
Line 20: | Line 45: | ||
SSO, and they already had a portfolio they want to keep. | SSO, and they already had a portfolio they want to keep. | ||
The workflow for this would be as follows: | |||
# Original Institute admin sends student to a parking inst using internal auth | |||
# credentials don't change | |||
# 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 | |||
# * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara | |||
This workflow could also include a CSV file upload with the following contents | |||
username, parkedinst, remoteusername (this field is optional, defaults to username) | |||
This will take the user from the parked inst, and change their remoteusername if supplied. | |||
A CSV file with only username field can take users out of institution and put them in the parking one. | |||
===SSO -> Simple=== | ===SSO -> Simple=== | ||
Line 29: | Line 70: | ||
They would still want to keep their portfolio | They would still want to keep their portfolio | ||
The workflow for this would be as follows: | |||
# Original SSO Provider sends student to a parking inst with internal auth | |||
# Mahara generates a password for that student that gets emailed to them, changed on first login. | |||
# 2nd institute provider uses the Institutions->Members screen to move students from parking to their institution | |||
# auth will be the same as the internal auth already set in step 2 | |||
There could also be a CSV file workflow with the following fields | |||
username, parkedinst | |||
which will take username out of parkedinst | |||
A CSV file with only username field can take users out of institution and put them in the parking one. | |||
===SSO -> SSO=== | ===SSO -> SSO=== | ||
Line 36: | Line 91: | ||
This would happen when a student leaves one school and | This would happen when a student leaves one school and | ||
enrols in another. They want their portfolio to follow them | enrols in another. They want their portfolio to follow them. | ||
The workflow for this would be as follows | |||
# Original SSO Provider sends student to a parking institution with internal auth | |||
# Mahara generates a password for that student that gets emailed to them, changed on first login. | |||
# 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 | |||
# * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara | |||
This workflow could also include a CSV file upload with the following contents | |||
username, parkedinst, remoteusername (this field is optional, defaults to username) | |||
This will take the user from the parked inst, and change their remoteusername if supplied. | |||
A CSV file with only username field can take users out of institution and put them in the parking one. | |||
===Parking Institution=== | |||
A dummy institution that maps to the old institution, but only uses internal auth. | |||
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. | |||
==Multiple SSO== | |||
* Wishlist | |||
This happens when a user is part of two institutions that use | 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 | SSO, and they want their portfolio to be the same in both of them |
Revision as of 18:18, 25 Mayıs 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 parking institution, which is described below.
Simple -> Simple
This is moving users from an internal auth method to another institution that uses internal auth.
The workflow would be as follows:
- Original Institute admin sends student to a parking inst using internal auth
- credentials don't change
- 2nd institute provider uses the Institutions->Members screen to move students from parking to their institution
- auth will be the same as the internal auth already set
There could also be a CSV file workflow with the following fields
username, parkedinst
which will take username out of parkedinst
A CSV file with only username field can take users out of institution and put them in the parking one.
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:
- Original Institute admin sends student to a parking inst using internal auth
- credentials don't change
- 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
- * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara
This workflow could also include a CSV file upload with the following contents
username, parkedinst, remoteusername (this field is optional, defaults to username)
This will take the user from the parked inst, and change their remoteusername if supplied.
A CSV file with only username field can take users out of institution and put them in the parking one.
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:
- Original SSO Provider sends student to a parking inst with internal auth
- Mahara generates a password for that student that gets emailed to them, changed on first login.
- 2nd institute provider uses the Institutions->Members screen to move students from parking to their institution
- auth will be the same as the internal auth already set in step 2
There could also be a CSV file workflow with the following fields
username, parkedinst
which will take username out of parkedinst
A CSV file with only username field can take users out of institution and put them in the parking one.
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
- Original SSO Provider sends student to a parking institution with internal auth
- Mahara generates a password for that student that gets emailed to them, changed on first login.
- 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
- * If 2nd SSO has a different username on remote side, they will need to update the user's remote username on mahara
This workflow could also include a CSV file upload with the following contents
username, parkedinst, remoteusername (this field is optional, defaults to username)
This will take the user from the parked inst, and change their remoteusername if supplied.
A CSV file with only username field can take users out of institution and put them in the parking one.
Parking Institution
A dummy institution that maps to the old institution, but only uses internal auth.
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.
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