Although many of the services that an institution uses via SURFconext must be available to all of an IdP’s users, some connected services may be directed at a limited set of users only. There are a number of reasons for this, e.g.:
- licensing factors: it allows an institution to purchase a service for a restricted group of users (e.g. staff only, or members of a specific faculty only);
- protection of sensitive services: for example, the connection of management tools via SURFconext avoids the reuse of passwords and has the advantage of single log-on; but it is not the intention to grant access to all users.
In this blog I describe how a service that is connected via SURFconext can be protected so that use of the service is limited to a restricted group of users within an institution (e.g. students only, or staff from a specific faculty only).
This protection can be achieved in a number of different ways. I describe the three most common methods below.
Many services have their own facilities for defining access to and rights within the service. Typically this means that, although it is accessed via SURFconext, the service only grants access to users that have been added to the service (provisioned) previously.
Users can be created in the service in a number of different ways:
- manually in a user interface in the service;
- by uploading a (CSV) file with users to the service;
- by creating a direct link between the service and the institution’s IdM system. Depending on what the service supports, a link of this type can be implemented on the basis of AD/ldap (as is the case with Office 365, for example), via a service-specific API (as is the case with Google Apps, for example) or via a standard provisioning protocol such as SCIM. The group of users that is to be synced to the service is then determined in the configuration of the link.
Clearly however, not all of these options will necessarily be supported by the service provider.
Another common option is for the institution’s IdP to specify additional attributes on the basis of which access can be granted.
The following attributes are possible:
- eduPersonAffiliation: this attribute specifies the roles that a user has within the institution. So, on the basis of this attribute, it is possible to restrict access to a particular service to staff only or students only.
- eduPersonScopedAffiliation: this attribute specifies the roles that a user has within parts of an institution.
So, for example, it can specified that a person is a lecturer/researcher in the Faculty of Mathematics (firstname.lastname@example.org) or a student in the Faculty of Law (email@example.com). On this basis, access can then be granted to users of a specific part of an institution (e.g. the Institute of Origami Art firstname.lastname@example.org), or to users with a specific role within this part of the institution (e.g. lecturers/researchers in the Faculty of Astronomy email@example.com).
- eduPersonEntitlement : this attribute can include values that grant a user access to one specific service or to a group of services. For example, in order to be granted access to a data storage service, a user must have the following entitlement value: “urn:x-surfnet:fancyservice.example.edu:access:true“.
The above attributes are forwarded to SURFconext by the institution’s IdP. The actual enforcement of the access control itself can be implemented in two locations: in SURFconext or in the service itself.
If the enforcement is provided by SURFconext, this workflow can be used without any support from the service provider. The enforcement can be configured by means of Authorisation Rules. The institution’s SURFconext coordinator can add a filter based on one (or more) of the above attributes under the Authorisation Rules tab on the SURFconext Dashboard. As a result, the selected groups will be granted or refused access.
If the protection is provided by the service itself, SURFconext will forward the necessary attributes, as described above, to the service. All users will then be admitted to the service, and the service can grant or refuse access on the basis of these attributes. Clearly, the service can also assign various rights on the basis of these attributes (e.g. read access for all users but write access for staff only). However, this depends entirely on the support and features of the service.
Rather than adding an attribute for specific users in the IdP, access can also be granted to users in a specific group. There are two options here:
- The groups are managed manually via SURFconext Teams. This is a good option if a relatively small group of users is involved or if the group is managed at local level (e.g. within a research group). This approach is also recommended if access is to be granted to users of different institutions or to a combination of institutional users and guests from the OneGini IdP.
A group manager who can independently add users to and remove users from a group can be designated through SURFconext Teams.
- The groups are managed within the institution’s group management system, and this system is directly connected to SURFconext. The groups that have been defined within the institution can then be used directly in SURFconext. Depending on the implementation within the institution (the groups are either stored in the IdM, for example, or in local systems such as an LMS or an SIS), the groups are managed centrally or locally.
Here too, there are two options for provision of the actual protection itself: within SURFconext on the basis of Authorisation Rules or within the service:
If the SURFconext option is selected, protection can be implemented by means of Authorisation Rules. These can be modified on the SURFconext Dashboard, where protection based on group membership can then be selected. This workflow can be used without support from the service provider.
If the protection is to be provided in the service itself, every time a user logs in, the service also has to make a separate call to SURFconext to request the user’s groups. The SURFconext wiki explains how this works.
The table below compares the key features of the various methods of protection once again.
|Provisioning||dependent on SP
institution or local
|Attributes||institution: IAM management||SURFconext||not required|
IAM management or local
|SURFconext Teams||local||SURFconext||not required|
This blog is an edited version of an article from the SURFconext Wiki.
If you have a comment or query, please contact the SURFconext Support team (firstname.lastname@example.org)