Permissions#

The VPN service supports access control, i.e. authorization. You can:

Restrict who has access to the server;
Restrict who has access to certain VPN profiles;
Determine who has admin privileges.

Restricting access to the server and to VPN profiles is documented here. To configure who has access to the admin, look here.

There are currently two sources for authorization information:

User Authentication
- LDAP attribute, SAML attributes/claims, OIDC claims, …
Static Permissions
- Locally assign permissions based on User ID

The information obtained during user authentication (1) is cached for the duration of the browser session when using the portal, and for the duration of the Session Expiry when using the VPN.

The reason for the caching is that there is not always a way to obtain fresh information about the user directly from the authentication source, for example when using SAML (WebSSO), or it might be “expensive” to do that on every page load.

In vpn-user-portal >= 3.5.0 we implemented Live Permissions for “real time” updating of authorization information when using the API for authentication backends that support this.

In vpn-user-portal >= 3.5.0 we implemented the ability to also specify the name of the attribute, to bind the attribute and value together. See Attribute Value Binding for more information, the old way, of only specifying the value, will of course keep working.

The configuration of permissions is done primarily through /etc/vpn-user-portal/config.php, see below for more details.

User Authentication#

Here you’ll find how to obtain authorization information through the various user authentication mechanisms.

SAML#

We assume SAML is already configured and working.

You have to choose a SAML attribute you want to use for determining the membership. Typically, that would be eduPersonEntitlement or eduPersonAffiliation, but any SAML attribute will do.

In order to configure this, modify /etc/vpn-user-portal/config.php and add the attribute to the permissionAttributeList list. For example:

'ShibAuthModule' => [

    // ...

    'permissionAttributeList' => ['entitlement'],

    // ...
],

In order to test whether everything works fine, you can enable the showPermissions option in /etc/vpn-user-portal/config.php by setting it to true. This will show the “raw” permissions on the user’s “Account” page.

LDAP#

We assume LDAP is already configured and working.

You have to choose an LDAP attribute you want to use for determining the membership. Typically, that would be memberOf, but any LDAP attribute will work.

In order to configure this, modify /etc/vpn-user-portal/config.php and set the permissionAttributeList to the name of the attribute:

'LdapAuthModule' => [

    // ...

    'permissionAttributeList' => ['memberOf'],

    // ...
],

NOTE: LDAP is (for some things) case-insensitive. However, if you are trying to match permissions coming from the LDAP server you MUST specify them in the exact case as returned from the LDAP server! Matching permissions is NOT case-insensitive in the VPN server software! Example: if your permission is cn=Foo,ou=Groups,..., you MUST specify it exactly like this in accessPermissionList, aclPermissionList and adminPermissionList. Using e.g. cn=foo,ou=Groups,... will NOT match it.

Static Permissions#

NOTE: this has been implemented in vpn-user-portal >= 3.1.8

See Static Permissions

Access to the Service#

You can restrict access to the Portal/API to certain permissions. For example, if you only went employees to be able to access the VPN service and not students, you can in addition to profile restrictions (see next section), prevent them from accessing the service at all.

In /etc/vpn-user-portal/config.php you can configure it like this:

'accessPermissionList' => ['employees'],

This requires everyone to have the permission employees. If you specify more than one “permission”, the user needs to have only one of the listed permissions. The permissions are thus “OR”.

If you specify [], nobody will get access. If you leave this option away, everyone (who can authenticate) gets access (the default).

Profile Authorization#

Add the authorized attribute values to aclPermissionList for each of the profiles where you want to restrict access, for example:

The values of aclPermissionList come from the permissionAttribute as configured in your authentication module. You can verify which values are available for your account by going to the “Account” page in your portal. It will be listed under your “User ID”. If nothing is shown there, you need to either make sure your account has any permissions, or logout and login again.

'aclPermissionList' => [
    'employees',
],

This requires everyone to have the permission employees. If you specify more than one “permission”, the user needs to have only one of the listed permissions. The permissions are thus “OR”.

If you specify [], nobody will get access. If you leave this option away, everyone (who can authenticate) gets access (the default).

Attribute Value Binding#

In vpn-user-portal >= 3.5.0 it is possible to “bind” a value to an attribute, this means that the value specified in aclPermissionList, accessPermissionList or adminPermissionList MUST come from the specified attribute.

For example, it is possible to specify eduPersonAffiliation!student. This means that the value student MUST come from the eduPersonAffiliation attribute. This avoids “mix-ups” where different attributes MAY have the overlap in values.

NOTE: this “binding” is done when users authenticate to the portal when the portal has version >= 3.5.0 installed. So you will have to wait for all users to authenticate (at some point) before you can make use of this feature. It may make sense to only implement it on new installations, or make sure you wait at least until the amount of time indicated by sessionExpiry has expired since installing vpn-user-portal 3.5.0.