Federated Authorization Implementing Grouper to federate user authorization

Federated Authorization Implementing Grouper to federate user authorization Andrea Biancini JRA 3 T 1 - Possibilities for Grouper in a cross/inter organizational use R&D Project Manager @ Consortium GARR and IDEM #TNC 15, Porto, Portugal June 16 th, 2015 Part of the GÉANT Project (GN 4 -1) distributed workshop Networks ∙ Services ∙ People www. geant. org

Federations today 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. We decided to extend the success of current identity federation to the field of user authorization. Networks ∙ Services ∙ People www. geant. org

How to reach that goal? Traditionally, identity federations have solved the authorization problems with two opposite approaches: • • SP managed authorization Id. P 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. Networks ∙ Services ∙ People www. geant. org

Tools 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. Networks ∙ Services ∙ People www. geant. org

Proof of Concept To prove real use cases, three SPs will be integrated with Grouper in a Proof of Concept: • • • A Media. Wiki 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). Networks ∙ Services ∙ People www. geant. org

Media. Wiki – 1/3 To implement this use case we had to define access groups within Media. Wiki 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 www. geant. org

Media. Wiki – 2/3 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 Media. Wiki during the login operation of accessing users. Networks ∙ Services ∙ People www. geant. org

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

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 www. geant. org

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

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 www. geant. org

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 www. geant. org

References The wiki page for the JRA 3 T 1 activity: • https: //wiki. terena. org/display/gn 3 pjra 3/Grouper+in+a+cross+organisational+context The code developed to integrate Media. Wiki with Grouper: • https: //www. mediawiki. org/wiki/Extension: Shibboleth_Authentication The code developed to integrate Moodle with Grouper: • https: //github. com/Consortium. GARR/moodle-enrol_voot The VOOT connector for Grouper: • https: //github. com/Internet 2/grouper/tree/master/grouper-misc/grouper-voot Networks ∙ Services ∙ People www. geant. org

Conclusion The architecture explored is being rolled out into two production environments: 1. To model access of the GN 4 project, phase 1 activities. 2. To model authorization for the applications operating IDEM (the Italian Identity Federation). During the Po. C 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. Networks ∙ Services ∙ People www. geant. org

Thank you Networks ∙ Services ∙ People www. geant. org 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. 691567 (GN 4 -1). Networks ∙ Services ∙ People www. geant. org 15