Managing Federated Authorisation for Research

Research, and particularly the on-line collaborative research referred to as e-science, creates a new challenge for federated access management systems. In teaching, the authoritative statement whether an individual is entitled to access an on-line resource comes from their home organisation: are they a member of that course? are they covered by that institutional licence? Thus it is natural to provide a source of authorisation attributes alongside, or even as part of, the home organisation's authentication systems. In collaborative research, by contrast, the authoritative source of permission is an individual - the principal investigator or group leader - not an organisation and the group to whom he wishes to grant permission are unlikely to all belong to the same institution. This requires a different type of attribute source, which may not be linked to any particular home institution. At the TERENA Networking Conference this year presentations, discussions and a birds of a feather session considered what such an attribute authority might look like.

The basic function of a group management tool is to allow the group manager to select which individuals are members of the group and to allocate permissions among them. In an e-science context the manager is likely to be the Principal Investigator (PI) and the permissions to be managed might, for example, include the ability to read, modify, or create documents, directories or datasets, or to use a portion of the project’s allocation of storage space or CPU time. Providers whose services the group uses should then be able to obtain this permissions information from the group management tool and implement the appropriate technical access rules and quotas automatically, rather than requiring individual manual configuration.

Since the group management service provides the PI’s interface to establish and manage her group of collaborators, two additional functions seem a natural fit. It is unlikely that all the PI’s desired group members will be registered with the group management service, so there needs to be a way for her to invite others to join. This is most often done by e-mail: the PI might, for example, list the e-mail addresses of those she needs as group members, with the system sending invitation e-mails to those who are not already registered. Using an invitation interface even for those who are registered may, in fact, be preferable for privacy and operational reasons, since displaying a list of all registered users for the PI to choose from will rapidly become unmanageable. Some group members may not have federated logins at all, either because their organisation is not a member of a research and education federation or because they conduct their research as an individual. For these individuals – who are selected, authenticated and authorised by a Principal Investigator – the group management system may be the best place to either issue a username and password or to link to an external authentication source such as a social network.

Whereas the functions of Identity Provider and Service Provider are naturally associated with specific organisations, the group management function has several possible locations. A presentation by Bob Hulsebosch looked at the advantages and disadvantages of each. A group management service could be provided by the Principal Investigator’s home organisation. This works well where all or most of the group members belong to the same organisation, since the group management service can link to local directories (for example to automatically add "all members of my department") and policies. For groups that span many organisations, however, this benefit is lost and the home organisation can end up running a complex service with many external dependencies for comparatively little benefit. Requiring all, or most, home organisations to run their own group management service, each supporting only a small number of groups, does not seem efficient. Another alternative is for the group management service to be run by the service provider, since here it can be tightly linked to the service’s own role and permissions systems. However this location means that a group is tied to a particular service; if the same group wish to use another service then the membership is likely to have to be recreated from scratch on that service’s management platform. Finally the group management service could be run as an independent entity, allowing cross-organisational groups to be established and used on multiple services. This would, however, require all relevant identity and service providers to implement common standard interfaces for group management and it appears these are not yet widely available. Since the group management service plays a critical role in protecting the interests of home organisations, services and researchers, the organisation running it must be strongly trusted by all of these.

The range of software packages currently used for group management was highlighted in a presentation by Kristof Bajnok. Some have been specifically written for a particular service; others borrow the functionality they need, for example from mailing list managers. A few projects have tried to implement general group management functions, but apparently suffer from a lack of standard ways to communicate group membership information to services: ways of doing this range from mailing unix group files to LDAP or SAML queries. It seems that, at present, anyone considering an independent group management service should plan to spend significant effort on configuring individual interfaces to the services its users want to access. An attempt to improve collaboration between some of these developments is being carried out as a GEANT Open Call project, but it seems there is still work to do both on defining what a group management system should do, and on making them a bit easier to work with.