Institutions are using SURFconext more and more intensively. As a result, they want more control over access to connected services. Right now, either everyone at the institution can get access to a service, or no one can. More fine-grained access control is needed. SURFnet is working on an authorisation infrastructure within SURFconext, which institutions can use to give their users access to services linked to SURFconext at a more fine-grained level. This blog post describes what we have done in recent months to respond to these preferences and how we will achieve what the institutions need. Feedback is still very welcome.
Access control on SURFconext now: coarse grained
The SURFconext infrastructure makes it possible to use your institutional identity as a secure login for many different services and cloud platforms. By creating one institution-wide connection to SURFconext, the institution can use technical links to all the connected services.
At the moment, access control by SURFconext (which user has access to each service) offers no fine-tuning at all. The SURFconext support team can turn a connection to a service on or off as an institution requests. Thereby all users receive access at once, or all users are denied access at once. It is not possible to grant access to specific groups of users and not to others, for instance all students, or all employees from a specific faculty. However, services connected to SURFconext can perform access control themselves, based on a number of attributes. These attributes can be passed on by SURFconext and contain all sorts of information about the person. (Is it a student or employee? Which roles do they have? What is their student ID number?) The service can decide to assign various access rights to different groups based on that information. But each service implements this access control differently, and the institution often has minimal influence on exactly how these services arrange authorisations.
Institutions prefer more fine-grained access control
Institutions use SURFconext to connect to more and more services, and are therefore becoming increasingly dependent on SURFconext. As a result, the model in which an entire institution can be switched on or off no longer suffices. Institutions have expressed a clear preference to have more control over which people log into each service.
To investigate this desire for richer, more detailed authorisation options at the institutions, we conducted an inventory over the past few months. Ton Verschuren of m7 spoke to a number of institutions about their preferences in this area. He presented the initial results at the What’s Next @SURFconext seminar; additional input was gathered in two debate sessions during the event. Preferences in this regard were explored in more detail at a workshop on 13 April.
The conclusions of the inventory were described in a report which is available for SURF-affiliated institutions upon request. The conclusions can be grouped into four different topics: improving documentation, authorisation function in SURFconext, support for groups, and a central OAuth authorisation server. I will address these topics individually below. I will also discuss how SURFnet will be addressing each topic further in the months to come.
First, there appears to be a strong need to have better, more numerous descriptions and documentation of the various aspects that affect authorisation: Which attributes are available and what do they do? How can certain information about users be communicated most effectively through SURFconext? What is the best way to manage your attributes in your directories and IdPs systems? The list goes on.
The SURFconext team will be taking a critical look at the SURFconext documentation in the coming months: Where do we need to improve aspects? Which topics are currently not covered in the documentation? Where can we clarify aspects or structure them more effectively?
The inventory also showed that institutions would like more control over which users can access various services. Although services can in principle arrange access themselves based on attributes that are transmitted during login, this often does not suffice for institutions: the services are often outside the institution’s control — this is especially common amongst commercial service providers — and the responsible authorities within the institution wish to stay in control of which groups have access. IT organisations at the institutions increasingly take on a coordinating role, and therefore would like to have more tools to arrange access control for their users independent from the service provider.
SURFnet will therefore be experimenting with an authorisation infrastructure for SURFconext in the coming months. This authorisation infrastructure is intended to make it possible to grant or deny a user access to a service based on attributes, entitlements, roles or group memberships. The aim is to ensure that authorisation rule management becomes an entirely self-serviced by the institutions.
Since this functionality still needs to be designed and developed, we do not expect to start experiments before the end of 2015 at the earliest. First, a number of pilot institutions will have access to try out the system so we can get feedback on how it works. Only then will we decide whether this functionality will be included in the standard SURFnet service package, and whether it will be a standard feature of SURFconext or an option that institutions can subscribe to separately. We don’t expect that decision to be made until 2016.
The SURFconext Teams service went into production several years ago. This service makes it possible to put together groups of collaborating users at the centralised level. These teams can be administrated in the SURFconext Teams web interface, or directly in the institution’s IdM systems. Those groups can then automatically be provided in all services and be used in that context to work in teams in those services, or to arrange authorisations within a service.
Research shows that the group functionality that SURFconext currently offers is not fully in line with what the institutions want and need in terms of functionality. A number of institutions need more functionality from this type of central group administration, so it can immediately be used in organising research and education.
There was no room within the scope of the inventory to further research which functionalities SURFconext Teams should provide to better fulfil the institutions’ requirements. We will therefore be exploring in more detail what role SURFconext Teams should play, what group management functionality is needed, and how we can improve SURFconext Teams to align better with the needs of the institutions.
Authorisation server based on OAuth
Several institutions have stated a need for SURFnet’s support for authorisation of the APIs they developed themselves (for instance for open education data). Secure access to these types of APIs requires an authorisation server for administration and issuing of OAuth tokens. If SURFnet offered a ready-to-use authorisation server, the threshold for institutions to offer these APIs to their students and staff would be lowered.
We will therefore be looking into whether it would be useful to offer a central OAuth authorisation server. We will specifically be looking at whether there is enough interest for such a service within the SURFnet community, and whether we can offer it in such a way that it is fully aligned to the institutions’ needs.
Brainstorm with us on authorisation within SURFconext
In closing, an appeal: please send us your feedback on these plans and give us your input on one of the topics mentioned above.
If you’d like to brainstorm with us about the functionality of an authorisation infrastructure for SURFconext, or would like to take part in the pilot later, please contact me at email@example.com. If you have preferences you’d like to share regarding SURFconext Teams, or if you would (or wouldn’t!) like to have a central OAuth server, I’d like to hear from you.
For questions about the documentation on our connection wifi , or tips about missing information or aspects you think we should change, please contact our SURFconext Support Team on firstname.lastname@example.org.