Trip Report: Shibboleth Workshop LMU TUM

Summary

The workshop was focused on sharing ideas, experiences and expertise concerning Shibboleth, the open source distributed AA system developed by Internet2. Two talks about the use of this software in a scholarly environment were followed by a general discussion of the app. 20 participants from the LMU, the TUM and the LRZ which organized the workshop. An optionally planned developers' meeting was cancelled because it was agreed that, at this point in the process, it is too early.

Wolfgang Hommel: Overview on the DFN-AAI and the LMU/TUM integration

Wolfgang Hommel is responsible for the identity management at the Leibniz-Rechenzentrum which, among other things, offers IT services for the universities. He has four years of experience with Shibboleth.

• The DFN-AAI, actually in formation, has several use cases for the use of distributed AA systems: Libraries, e-Learning or the licencing of software in an educational context.
• The use of Shibboleth as such a system has some striking advantages:
  • The participating organizations can keep their AA systems and simply register it as an Identity Service Provider (IDP) in the so-called federation.
  • A single sign-on mechanism avoids the creation, storage and synchronization of tons of login information, not to speak of the necessity to keep these logins and passwords in mind.
  • The services, equiped with a Shibboleth Service Providers (SPs) can authenticate and (theoretically) authorize users on the basis of identity attributes (e.g. course or university information).
  • This enables a very distinct data protection policy because a service only gets a previously agreed set of user information.
• But there are also still some lacks and disadvantages of Shibboleth:
  • Only ONE IDP per transaction can be used for AA. Distributed rights management therefore is not yet possible.
  • Shibboleth only has read access to the IDPs which means that user attributes cannot be added or modified by the system.
  • It is not possible to access user data outside of a user's session. Therefore features like references to other users (e.g. citations) are not possible.
  • Only user-scope data can be accessed, not group-scope data.
  • A federation-wide attribute definition and provision is needed.
• LMU and TUM will build up the necessary infrastructure to act as IDPs in the DFN-AAI.
• The TUM already uses Shibboleth for its internal SSO.
• With CASUS, a first SP prototype exists.

Martin Adler: CASUS as Shibboleth Service Provider

Martin Adler founded the IN.struct AG as a follow-up of a LMU workgroup on e-Learning. CASUS is a LMS primarily used in medical and veterinary contexts.

• Shibboleth was introduced to CASUS due to requirements of swiss veterinary organizations that wanted to use the system and replaced SCORM/AICC/HACP protocols for AA.
• CASUS now is integrated in the Swiss Educational & Research Network
• Here are some of Mr. Adler's experiences:
  • Support documentation for Shibboleth has become much better recently.
  • All a SP has to implement is the Shibboleth component and a mechanism to retrieve the user attributes given in the request's http header.
  • It makes no bigger difference which flavour of the Shibboleth component is chosen, the binary apache webserver module or the Java Filter Servlet.
  • Although still announced in beta stadium, the Java variant was taken for CASUS and, after a little bugfixing, works satisfying.
  • Implementation is easy, more time-consuming are other related tasks like getting server certificates and clarifying legal issues between the Shibboleth Federation and the SP.
  • Shibboleth configuration is complex, but well-documented. A GUI tool for administering the authorization rules (written in SAML) is actually in development.
  • The Shibboleth authorization in CASUS is very rudimentary: It is only checked if the user is from a medical context to grant read access to the CASUS courses. Write access for authors and administrators is managed locally. The reason for this is, as Mr. Adler stated, the attributes given by Shibboleth that do not allow a more fine-grained distinction of user roles.
• Mr. Adler also offered his expertise in implementing SPs.

General discussion

The discussion, led by Armin Rubner from the LMU, responsible for LMSs, focussed on the following.

• How does the attribute list of the DFN-AAI look like? What can be changed there? An overview was given by Mr. Hommel.
• How can a SP setup a role-based AA? IMHO, this question is not yet answered satisfyingly, neither by this workshop nor by the recent talk of Nate Klingenstein of Internet2.
• What next steps will be taken by the LMU, TUM and LRZ?

Abbreviations

• AA: Authentication/Authorization
• AAI: Authentication and Authorisation Infrastructure
• DFN: Deutsches Forschungsnetz
• IDP: Identity Service Provider
• LMS: Learning Management System
• LMU: Ludwig-Maximilians-Unversität München
• TUM: Technische Universität München
• SP: Service Provider
• SSO: Single Sign-On

see also: MPG-AAI

Deutsches Forschungsnetz

Authentication, Authorization and Identification

Ludwig-Maximilians Universität München

Informationstechnik

Logging-in system for computer networks

Intrusion Detection & Prevention

Service Provider

Graphical User Interface

Leibniz-Rechenzentrum