Show Advanced KnowledgeHide Advanced Knowledge

Multiple Accounts for a User

1 Requirements

Some institutions have different ways to authenticate their users. Currently ILIAS only supports one authentication mechanism per user account. We would like to split up the current datamodel "user" into the model "account + credential(s)". 

1.1 Implementation

The user interface should stay as similar as possible, not confronting the end-user too much with the datamodel. There will be two main changes in the user interface:

1. The detail list for a user is changed in order to no longer display "User Data" at the top. The information about the different accounts is displayed in a separate tab "Credentials".
2. In the administration "Authentication and Registration" there is a new subtab with a form allowing to turn off the possibility to add multiple credentials to an account.

An account has N credentials. Credentials have the following fields, stored in a table usr_credentials:

• Password*
• Password-Type*
• Password-Salt*
• Login-Type*
• User-Id
• Ext-Id
• Custom-Fields

Data with (*) will be removed from the current user tabel (usr_data).

The login field of the usr_data table does not have to be migrated as it is currently used as a "display name" and can stay the same (according to discussions at the JF 16.01.2016 Stefan Meyer).

1.2 Mockups

1.3 Use case and illustration

The separation of aan account and its credentials is especially of interest in connection to the concept Introducing Transfer-Service. This concept tries to implement the functionality that allows to move certain items from one user to the other (e.g. testresults, course membership, ...). This leads to the  overlapping use case of the two concepts: We have an enduser with two ILIAS Accounts (Account1 and Account2) and the according credentials (Credential1 and Credential2). He has passed tests on both accounts. We don't have a good overview of which tests this person passed and want to merge the enduser. With the concept of Multiple Accounts for a User and Introducing Transfer-Service we can do that with ease. We move all test results from Account2 to Account1 and we move Credential2 from Account2 to Account1. Now we can deactivate Account2. The end user can use logindata from Credential1 or Credential2 and still ends up with the same Account1 and the test results are both related to that user.

The use case is described given below. 

2 Additional Information

• Idea / concept: Oskar Truffer
• Interest in funding: Customers of studer + raimann ag
• Maintainer: (will be set by Jour Fixe / maintainer)
• Implementation of the feature is done by (will be set by Jour Fixe / maintainer)
• Testcases by: (please add your name if you want to create the testcases for this feature)

3 Discussion

Killing, Alexander [alex] 4 Jan 2016: Should the account data be included in user import/export/SOAP calls?

Glaubitz, Marko [mglaubitz] 15 Feb 2016: This sounds very interesting, because we have encountered the same problem in our considerations on coupling ILIAS and CampusManagement software such as HISinOne which which use / provide person-based IDMs and not account-based IDMs.

Truffer, Oskar [otruffer] 29 Nov 2016: Reopened for a potential release in 5.3.

Meyer, Stefan [smeyer]: 2017-01-16: Regarding the "login name". Wouldn't it be easier, and produce less problems, if this field is not part of the account but part of the user. The field "login" is currently more a "disaplay name" than a "login name".
Will the feature account migration still be available? I guess, yes.
Will the feature "Allow local authentication" still be available or will it be implemented with "multiple accounts"?
Why are custom fields part of the usr_accounts table?

JourFixe, ILIAS [jourfixe], 16 Jan 2017: We appreciate the feature request in general but would like to have some more details and information:

• we prefer not to say 'one person has several accounts' but 'one account has several 'login credentials'
• 'login' is not part of the account table but singular per user as login is today the user name presented on the interface. Please change the data model accordingly.
• a description of the user interface is necessary. It should also make clear how a new credential can be added to an existing user account.
• the feature for several credentials should become a distinct setting in 'Authentication'. Default is 'deactivated'. Installations that do not need this feature will not see it (and probably get confused).

, 24 Jan 2017: 

• we prefer not to say 'one person has several accounts' but 'one account has several 'login credentials'

I edited the wording.

• 'login' is not part of the account table but singular per user as login is today the user name presented on the interface. Please change the data model accordingly.

The login part is removed with a short explanation why.

• a description of the user interface is necessary. It should also make clear how a new credential can be added to an existing user account.

There are 3 mockus on what views are changed.

• the feature for several credentials should become a distinct setting in 'Authentication'. Default is 'deactivated'. Installations that do not need this feature will not see it (and probably get confused).

Described in the mockup. Here we have a small collition between guidelines: We shouldn't add a form to the credentials part because there is already a table and there's a guideline "no forms where there is a table". On the other hand a tab with a form with currently only one setting seems like an overkill. I hope the JF can decide on the design.

4 Implementation

{please give a description of the final implementation and add screenshots if possible}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.