Networks ∙ Services ∙ People Andrea Biancini #TNC15, Porto, Portugal Implementing Grouper to federate user authorization Federated Authorization June 16 th, 2015 JRA3 T1 - Possibilities for Grouper in a cross/inter organizational use R&D Project Consortium GARR and IDEM Part of the GÉANT Project (GN4-1) distributed workshop

Networks ∙ Services ∙ People Currently, the goals of an Identity Federation are: give a delegated mechanism to manage user identification among different entities and within different subjects; provide a set of attributes to an authenticated users to be used by the final application. Federations today We decided to extend the success of current identity federation to the field of user authorization.

Networks ∙ Services ∙ People Traditionally, identity federations have solved the authorization problems with two opposite approaches: SP managed authorization IdP managed authorization A different approach may be followed (leveraging Attributes Authorities and implementing tools like Grouper) where authorization is delegated to a specific system designed for that purpose. How to reach that goal?

Networks ∙ Services ∙ People We want to evaluate the introduction of Grouper for a cross/inter organizational use. Grouper will be used to manage in a centralized way (yet permitting delegation): Groups of users Authorization attributes for users. Tools

Networks ∙ Services ∙ People To prove real use cases, three SPs will be integrated with Grouper in a Proof of Concept: A MediaWiki application: Grouper will manage user groups for read/write access; A Moodle application: Grouper will provide course list and manage students/teachers enrolment to courses; A custom application (not covered within this presentation). Proof of Concept

Networks ∙ Services ∙ People MediaWiki – 1/3 To implement this use case we had to define access groups within MediaWiki. MediaWiki defines standard groups which are always present: Administrators: administrators of the wiki Bureaucrats: technical personnel of the wiki Users: registered users of the wiki Besides, it is possible to define new groups as needed.

Networks ∙ Services ∙ People Inside Grouper we can define a coherent group structure and we can assign different users (even from different VOs) to these groups. In this way the group membership of a user is described in Grouper and will be retrieved by MediaWiki during the login operation of accessing users. MediaWiki – 2/3

Networks ∙ Services ∙ People At login time user groups are retrieved from the Attribute Authority. MediaWiki uses the Shibboleth Authentication module, modified within this activity, to manage the attribute describing group memberships. MediaWiki – 3/3

Networks ∙ Services ∙ People Moodle This use case needs to retrieve groups and attributes for authorization during the login phase (as the case for the wiki). Besides, Moodle also needs some off-line interfaces (executed not only at login time) to query Grouper and retrieve: a list of courses; a list of teachers; and a list of students for each course.

Networks ∙ Services ∙ People VOOT is a protocol for exchanging group information externally to applications. Very simple API: The VOOT protocol

Networks ∙ Services ∙ People Moodle integration – 1/2 In Grouper we create a group for each course that must be activated on the Moodle platform. User members of these groups can be of two kinds: 1. the «admin» members will be teachers of the course 2. all other members will be students of the course.

Networks ∙ Services ∙ People Moodle integration – 2/2 Moodle will use an enrollment plugin to retrieve the group information from Grouper. For this purpose, a specific enrollment plugin has been developed. It is able to retrieve information form a VOOT server.

Networks ∙ Services ∙ People The wiki page for the JRA3 T1 activity: The code developed to integrate MediaWiki with Grouper: The code developed to integrate Moodle with Grouper: The VOOT connector for Grouper: References

Networks ∙ Services ∙ People The architecture explored is being rolled out into two production environments: 1. To model access of the GN4 project, phase 1 activities. 2. To model authorization for the applications operating IDEM (the Italian Identity Federation). During the PoC it we had the opportunity to address problems and future activities, in particular: AAs still have some issue regarding privacy and security. User enrolment must be supported to reduce effort. Conclusion

Networks ∙ Services ∙ People Thank you Networks ∙ Services ∙ People This work is part of a project that has applied for funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No (GN4-1). 15