Feature Wiki

Information about planned and released features

Tabs

SAML Authentication

Page Overview

1 Initial Problem
2 Conceptual Summary
3 User Interface Modifications
- 3.1 List of Affected Views
- 3.2 User Interface Details
- 3.3 New User Interface Concepts
4 Technical Information
5 Contact
6 Funding
7 Discussion
8 Implementation

1 Initial Problem

ILIAS has no SAML ADFS authentication yet. There is work in progress or finished to implement SAML for customers. We are looking forward to implement it in core

2 Conceptual Summary

Have a look on the examples of an already finished implementation for more details.

3 User Interface Modifications

3.1 List of Affected Views

Login
Login » New Account Registration
Administration » Authentication and Registration
Administration » Authentication and Registration » SAML » Settings (new)
Administration » Authentication and Registration » SAML » SAML IDP List (new)
Administration » Authentication and Registration » SAML » SAML IDP » IDP Settings (new)
Administration » Authentication and Registration » SAML » SAML IDP » User Profile Mapping (new)

3.2 User Interface Details

The following scenarios are possible:

A user already has a valid/active session in ILIAS and calls it regularly:
The user gets into his user context in ILIAS respectively to the requested target resource.
A user has no valid/active session in ILIAS and calls it with his browser:
- The user is redirected to the login page of ILIAS. There he's offered a standard login form (for local users, e.g. administrators) as well as a reference to ADFS (IDP):

If a non-authenticated user clicks on the link, the SAML authentication is triggered by the configured IDP. A SAML round trip to the IDP is triggered
If the authentication with IDP fails, IDP handles errors accordingly
In case of a successful authentication with IDP and following return to ILIAS there will be an attempt to authenticate the user with the supplied data from the IDP (SAML response). In case of success there are two possible cases:
- If a linked user account to a well-defined attribute (one of the SAML claims, e.g. sAMAccountName or e-mail address) is found in the database of ILIAS the user gets a valid/active session in the context of this user account.
- If no linked user account is in the database of ILIAS, there are two possible options:
  - The possibility of account migration in ILIAS is active. The user will see a form like this (example):

This form can link an already existing user account in ILIAS with the well-defined attribute (one of the SAML claims, e.g. sAMAccountName or e-mail address). If the user authenticates successfully against the local database of ILIAS (with the entered user name and password), the local user account will be linked with the SAML-Unique-Credential afterwards (and then only). This linking (if already existing) can be removed by a logged in user in ILIAS at any time. In this case an authentication by ADFS wouldn’t be possible anymore unless the linking process is initiated again. Another possibility would be the recreation of a user account in ILIAS linked with the well-defined SAML claims.

In both cases the user will get a valid/active session for ILIAS. Alternatively, the user has the opportunity to cancel the account migration. In this case there is no linking between the local user account and the SAML identity provider. The user will not get a session for ILIAS.

Second Option for no linked user account: Account migration is deactivated: A new user account will be created in ILIAS which is linked with the well-defined attribute of the ADFS. The user will get a valid/active session in the context of this user account

Password

If a user logs in with the standard form in ILIAS, he could be forced to change his local password (if expired) for ILIAS after a successful authentication (and possibly following SAML round trips). Furthermore he has at any time the possibility to change his own local password in ILIAS as needed. After a SAML login (i.e. the user has not logged in with standard form in ILIAS) with an already linked user account, the user cannot change his local password during the current browser session anymore. User interfaces allowing such aren’t shown, HTTP-requests to change the password are not allowed by ILIAS in this case (instead: HTTP-redirect on the welcome page).

The password assistant in the public space of ILIAS will also work with those local user accounts that are already linked with SAML. Users will be able to create a new local password for their local user account.

The login with the local user account and password will continue to work, even if a link for the user account in ILIAS to the IDP was already established.

New SAML Tab

SAML Settings

SAML IDP list

IDP Settings

User Profile Mapping

Authentication and Registration

User Profile (User Administration)

3.3 New User Interface Concepts

None

4 Technical Information

Technical Dependencies:

Authentication (general service, conceptional intersection/interference with Shibboleth)
The implementation is based on SimpleSAMLphp (new composer dependency)

5 Contact

Author of the Request: Wischniak, Stanislav [wischniak]
Maintainer: Meyer, Stefan [smeyer]
Implementation of the feature is done by: Jansen, Michael [mjansen]

6 Funding

Rhomberg
Aptar
Krohne
Qualitus
ILT Solutions

7 Discussion

Raimann, Marcel [raimann], Mar 29, 2017: Nice feature! But there is already a SAML Integration in ILIAS. Shibboleth is an Authentication methode based on SAML, and you can use it for ADFS.

Schmid, Fabian [fschmid] 29 Mar 2017: Agreed, as the Shibboleth-Maintainer I think it's a bad idea to implement another "version" of this authentication. The correct way would be to have the Shibboleth-Authentication supporting SAML ADFS.

Killing, Alexander [alex], 29 Mar 2017: I am confused. Shibboleth and ADFS implement the SAML protocol, right? What is the "ADFS" specific implementation that is additionally required here? Maybe Michael and Fabian can outline this somehow under technical information.

Jackisch, Ingo [jackisch], 31 Mar 2017: From my understanding (but still untested in my implementation) Shiboleth should be able to work wit SAML SPs. But there ist a software calles "simplesamlphp" which very much eases the configuration of saml and is very flexible to use autentication sources. I use this software with moodle an a plugin that directly interfaces the LMS with this software.
Using shibboleth with apache imposes some issues in my installation, since the shibboleth module in apache is problematic (means not working for now) in conjunction with other apache authentication methods, so alltogeter I like the idea of a SAML- functionality. Since SAML and shibboleth are very similar, they probably could be integrated into one module (just a suggestion...)

I could try to get some funding for this feature.

Bromberger, Norbert [bromberger], 11 July 2017: After several meetings with Stas, Michael, Fabian and Stefan, Michaeld could provide a pull request.

Jansen, Michael [mjansen] 12 Jul 2017: https://github.com/ILIAS-eLearning/ILIAS/pull/576

Wischniak, Stanislav [wischniak], 17. July 2017: As requested, here are the minutes of the VC meeting on 14. June 2017.
(Michael Jansen, Fabian Schmid, Stefan Meyer, Stanislav Wischniak)

Q: How is SAML related to Shiboleth?
A: SAML can be considered as a part (a subset) of Shiboleth.

Overlaps in SAML/Shiboleth implementation:

Registration of new accounts (could be provided as a central feature for any kind of user interface)
Mapping and sync of user data
Field titles from ILIAS
Rule based role mapping
SAML: few IDP (Identity Provider) similar to LDAP implementation
Automated login creation, based on provided data (like last name, email, id etc.)
Further settings in Personal Data and Profile
Initial mapping of users (based on login, ext_account, rules etc.)

Further thoughts:

Support for several auth methods (Feature Request)
Usage of XML Import is reasonable
In long run it would be more efficient to create a function (layer) behind XML Import Parser to be able to import users without creating/parsing the XML (especially with high quantity data)
Implementation using auth plugin slot possible

Next steps:

Provide Pull Request for JF, TB, Maintainer as subject of discussion
Verify the requirements for the implementation
Develop the overall, future objective of the implementation, to take the next steps along that path

Kunkel, Matthias [mkunkel], July 20, 2017: Thank you for the additional information about the workshop's results. Concerning the current feature request:

First of all: please respect the given structure and intention of the page template for further feature requests. No chapters should be deleted or deactivated. Write down "not applicable" or "n.a." if there is nothing to mention instead of deleting a chapter. Use chapter 2 for describing your solution while chapter 3 is just about UI elements. Chapter 3.1 is just a list of changed screens. Descriptions should be placed in 3.2 and 3.3. Filling out the chapter about technical information is a requirement to tackle the request in the Jour Fixe. I restored the structure this time.
Login Screen: your suggestion for the SAML login looks like a bad hack. Sorry, but this needs improvement and should fit to the following login form and to the presentation of other authentication modes like Shibboleth.
Account migration screen: in forms we never use centered text! Please align text to the left as it is usualls done in ILIAS' forms.
Administration » Authentication and Registration » Authentication: don't forget to list "SAML" in the "Select authentication mode" table
SAML Settings: Please offer a checkbox to enable SAML authentication (similar to Shibboleth or CAS auth mode)
SAML IDP List:
- Please use a better column title for the available IDPs. 'Title' is not very helpful. And please change the order of columns and place 'Active' after the name/URL of the IDP (like usually done in ILIAS).
- Please explain how one can add a new / additional entry to this list. I don't see an Add or Remove button on any of the screens.
User Profile Mapping: Handling this form is not self-explaining. I assume that the keys at the left side are related to ILIAS while the input fields at the right side are related to the Identity Provider. Best would be to add bylines to every input field and explain what input is expected. According to the screen shot input could be a link or a text, right?

Jansen, Michael [mjansen], July 20, 2017

Regarding the account migration sceen: We did not create/add an own migration screen. This auth. method uses exactly the same account migration GUI that is used for other authentication methods (LDAP, ...). The screenshot is outdated...
Regarding the login form: Yes, if the feature is appreciated in general, we will add small improvements.
Regarding 'don't forget to list "SAML" in the "Select authentication mode" table"': Every IDP configured is listed there (similar to multiple LDAP servers). The implementation covers all ILIAS screens (as mentioned very similar to LDAP/multiple LDAP servers).
Regarding 'Please offer a checkbox to enable SAML authentication (similar to Shibboleth or CAS auth mode)': Yes, we can add this if the feature is appreciacted in general.
Regarding 'User Profile Mapping': It is exacly the same form (and user experience) used for the LDAP attribute mapping... But of course we could add some more information if the feature is appreciated in general.
Regarding 'SAML IDP List': It is currently not possible to add new IDPs via the ILIAS user interface. The IDP configugration has to be done in the configuration file of the underlying SimpleSAMLphp library (also used in the Moodle and Mahara impl.). Once an IDP is listed in the configuration file, it appears in the table and can be further configured (activation, attribute mapping, etc.). Of course we need to add some more information about this process, e.g. by linking the SimpleSAMLphp documentation and provide some information on the respective ILIAS screens. Adding new IDPs via the ILIAS UI etc. could be done in a future implementation.

JourFixe, ILIAS [jourfixe], July 24, 2017: We highly appreciate this suggestion and schedule the feature for 5.3. In general, we would like to have a centralised authentication for 5.4 and to use the support of different authentication services offered by SimpleSAML. The following changes are still required for this feature:

The screen 'SAML IDP List' should be first tab in 'SAML' tab. Additionally, a text (and link) should be added about how to add a IDP to the list.
Matthias' requests for screen modification should be taken into account (as Michael has already noticed in his posting).
Fabian's suggestion to the related PR will be taken into consideration, too,.

Jansen, Michael [mjansen] 21 Aug 2017: https://github.com/ILIAS-eLearning/ILIAS/pull/614

8 Implementation

Implemented as described above, except the following changes:

SAML IdPs can be created via the ILIAS user interface by inserting/saving the respective IDP metada XML
SimpleSAMLphp cannot be configured with 'phpsession' as session storage/handler, 'sql' or 'memcached' have to be used instead