Feature Wiki

Information about planned and released features

Tabs

Shibboleth Authentication: Customizable User Creation

If you need any help in filling out this wiki page, please visit our ILIAS Community FAQ. And please complete the metadata information in the right column after having created the page.

1 Initial Problem

Users with a valid Shibboleth login will automatically have a new ILIAS account if they do not already have one. This is not yet customizable and can result in problems. 

2 Conceptual Summary

In the Shibboleth settings, it should now be possible to (de)activate the following function:
Users who want to log in via Shibboleth authentication but do not have an ILIAS account will not be able to log in. The Shibboleth session will be destroyed.

The setting is deactivated by default in new and updated installations.

3 User Interface Modifications

3.1 List of Affected Views

  • Administration > Authentication and Registration > Shibboleth

3.2 User Interface Details

Blue frame around new function to be customised

3.3 New User Interface Concepts

The feature is implemented with existing UI components and does not introduce any new UI concepts.

3.4 Accessibility Implications

The use of existing UI components does not introduce any new implications for accessibility.

4 Technical Information

The implementation takes place in ilAuthProviderShibboleth. At this point, a decision is already made as to whether a new account needs to be created or not. 

5 Privacy

No new personal data is collected or processed as a result of the implementation of the feature. 

6 Security

The implementation of the feature does not introduce any new attack vectors. there are no further special security-related considerations to be made.

7 Contact

8 Funding

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

9 Discussion

Seeland, Per Pascal [PerPascalSeeland] 2024-03-21: Could you please describe the issue you want to solve with this feature? What are the reasons to allow the user a have a valid shibboleth session and then don't create a ILIAS user account. In my opinion, a user should not get a valid shib session if he should not get an ILIAS user account. I would suggest looking into shib entitlements, which could be used to flag users which should get a valid shib session.

[goju] 27.03.2024: Hallo Pascal,ich

stimme dir grundsätzlich zu, dass der Zugriff weitestgehend über Shibboleth gesteuert werden sollte.

Wir haben zum Beispiel ein ziemlich komplexes Setup. Wir setzen auf eine automatisierte Verwaltung der Accounts über die SOAP-Schnittstelle, bevor sich die Nutzer zum ersten Mal anmelden. Da es sich bei der Datenquelle jedoch um die gleiche wie bei Shibboleth handelt, kann es vorkommen, dass sich Benutzer über Shibboleth anmelden, ohne dass ihre Konten zuvor entsprechend bereitgestellt wurden. Dies kann insbesondere dann passieren, wenn einzelne Jobs nicht rechtzeitig starten, neu gestartet werden oder unvorhersehbar abbrechen.

Ein weiterer Fall ist die Umbenennung von Accounts – auch hier lässt sich der Zeitpunkt zwischen der Änderung in Ilias und in Shibboleth nur bedingt synchronisieren.

Die Möglichkeit, das Standardverhalten zu ändern, würde einen solchen Workflow stabiler, einfacher und vorhersehbarer machen und unerwünschte Konten auf der Ilias verhindern.

JourFixe, ILIAS [jourfixe], 15 APR 2024: We highly appreciate this feature and schedule it for ILIAS10.

JourFixe, ILIAS [jourfixe], 08 JUL 2024: We accept the suggested change of the UI for using a radio group with the three mentioned options.

10 Implementation

Test Cases

Test cases completed at {date} by {user}

  • C18639 : Erstmaliger Login bei erforderlicher Account-Aktivierung
  • C75219 : Erstmaliger Login bei deaktivierter Account-Erstellung
  • C75220 : Erstmaliger Login bei aktivierter Account-Erstellung

Privacy

Information in privacy.md of component: no change required

Approval

Approved at 2024-08-20 by goju.

Last edited: 21. Aug 2024, 10:15, Lorenz, Katharina [klorenz]