Show Advanced KnowledgeHide Advanced Knowledge

Create ECS user accounts as non-local users (Shibboleth, LDAP, ...) via ECS

1 Initial Problem

Curently, user accounts that are created through the ECS interface (i.e. because a user on a remote platform click on an ECS link and is "tranferred" to the target platform) exclusively as local users.

This has many limitations / problems:

• ECS users cannot login directly to the target platform
• ECS users cannot receive emails (because direct links would not work due to no direct login possible)
• users receive a new local user account with limited activation period on the target platform although they might be able to log on to the platform directly through some kind of federated login service like Shibboleth

In many cases, if LMS platforms are connected through an intermediary ECS server, a high level of mutual trust is granted and additianl IDM-realed processes are triggered between the LMS teams of the relevant institutions. In other words: such platforms connections are built on a high level of insitutional interconnections and trust.

Right now, it is not possible to realise the following scenario:

• Platform A and Platform B both offer authentification through a mutual LDAP or by Shibboleth using a unique user account schema like EPPN. That means, user can login directly on both platforms with the same user account and have the same "login" on both platforms.
• Platform A and Platform B are members of the same ECS community.
• The ECS participant settings of  both platforms have been setup to trust each other and to use Shibboleth-auth accounts with EPPN instead of local ECS accounts.
• Courses are shared between platform A and B.
• Now imagine a user X with the username  x@institution-a.de clicks on an ECS course link in platform A
• User X is transferred to platform B and she/he appears on platform B as "x@institution-a.de"
• User X enters the course on platform B (or requests admission)
• User X can now log on the both platforms and access the shared course thought eitehr platform A (by means of the ECS course link) or by loggin in on platform B directly

2 Conceptual Summary

Conceptual Prerequisites for this "transparent" scenario:

• mutual trust on an institutional and IDM-level has been established
• users can login on both interconnected platforms using LDAP or Shibboleth, meaning that respective IdP backends / LDAP servers are configured in both ILIAS installations
• user accounts are unique, ideally this is realised by using scoped user accounts like the EPPN schema "userxy@institution.de
• it should not be possible to "inject" user accounts with the authentification mode "LDAP" or "Shibboleth" into the target ILIAS without at least one successful login with this user account

The process of user transfer is the following:

When user X clicks on an ECS course link in platform A that targets a course on platform B, the platform B is called via the ECS and then...

The ECS Administration > Participant > Edit Participant Screen need to be extended, in oder to make it possible to configure...

• how incoming users from a participant are supposed to be handled
• which data field (login or external_account) is supposed to be handed over to the target participant i.e. for outgoing users to this participant

3 User Interface Modifications

3.1 List of Affected Views

See 3.2: only the participant configuration in "Administration -> ECS -> Participants" is affected.

3.2 User Interface Details

3.3 New User Interface Concepts

Only existing user interface elements are used. 

4 Technical Information

Modifications need to implemented in "Services/Webservices/ECS"

5 Privacy Information

Depending on the configuration the External-Account-Name instead of the Login-Name will transferred to the target platform. 

6 Security Implications

No security implications. Since a login process is triggered on the target platform, it is not possible to "hijack" user accounts on the target platform by manipulating local user account. 

7 Contact

• Author of the Request: Glaubitz, Marko [mglaubitz]
• Maintainer: Meyer, Stefan [smeyer]
• Implementation of the feature is done by: Meyer, Stefan [smeyer]

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• Universität Freiburg
• EPICUR - European Partnership for an Innovative Campus Unifying Regions

9 Discussion

Kunkel, Matthias [mkunkel], 15 APR 2021: Concerning screenshot 2 in chap 3.2: Why do you want to implement the list of selectable authentications for "User Account Mode for Incoming Users" as a dropdown and not as radio boxes? This is much more common in our forms and works fine for lists up to 10 entries (see also type list below).

Meyer, Stefan [smeyer], 19 APR 2021: I support the request.

JourFixe, ILIAS [jourfixe], 19 APR 2021: We highly appreciate this suggestion and accept the feature for ILIAS 8. We keep the list of authentications as dropdown because it could be a long list if a lot of installations each with its own LDAP are listed.

10 Implementation

{The maintainer has to 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 2022-04-26 by Glaubitz, Marko [mglaubitz].