Live Permissions#

In vpn-user-portal >= 3.5.0 we support “Live Permissions”.

Previously it was only possible to obtain a user’s permissions from the IdM during the authentication step. For example when SAML was used, the user logged in and their “authorization information” remained valid for the length of sessionExpiry.

When permissions change regularly, it makes sense to be able to use that information in real time, without having the user authenticate with high frequency.

Problems that needed solving:

A user gets a new permission for a profile they didn’t previously have access to;
A user loses a permission for a profile they previously had access to, but should no longer;
The account has been deleted from the IdM, but not (yet) deleted from the VPN server.

Unfortunately not all authentication mechanisms support (re)verifying the user’s permissions in real time, notably SAML when only WebSSO is implemented.

We will implement “Live Permissions” using the Static Permissions and LDAP backends.

Scenarios#

We tested the following configurations, but other combinations are also possible. For “Live Permissions” we currently have the Static Permissions source and the LDAP source.

Authentication	Live Permissions
Local Accounts	Static Permissions
LDAP	LDAP
SAML	LDAP

Local Accounts and Static Permissions#

The easiest to configure and use, we’ll start with that. Make sure you use Local Accounts and have some Static Permissions configured.

You only need to add one snippet to your configuration file /etc/vpn-user-portal/config.php to enable “Live Permissions”.

[
    // ...

    'StaticPermissions' => [
        'isLivePermissionSource' => true,
    ],

    // ...
],

See Testing on how to test your setup.

LDAP#

We assume you managed to configure LDAP properly and that the authentication works.

You MAY need to update your LDAP configuration. It is important that your LDAP server can be queried without the user’s credentials as those are not stored by the VPN server. If anonymous LDAP binds are not allowed, you need to also set searchBindDn and searchBindPass which will then be used to bind to the server to (optionally) perform the server for the user account, and retrieve the attribute values. Another option is to use mTLS if your server supports that.

To enable “Live Permissions”, you also need to enable isLivePermissionSource, see the example.

An example:

[
    // ...

    'authModule' => 'LdapAuthModule',

    'LdapAuthModule' => [
        // the user's "uid" is part of the DN, so we can use the 
        // 'bindDnTemplate'
        'ldapUri' => 'ldap://ldap.example.org',
        'bindDnTemplate' => 'uid={{UID}},ou=people,dc=example,dc=org',
        'userIdAttribute' => 'uid',
        'permissionAttributeList' => ['eduPersonAffiliation'],

        // in case "anonymous bind" is not allowed, set these
        // **NOTE** use a read-only search-only account, not the actual admin 
        // account!
        //'searchBindDn' => 'cn=admin,dc=home,dc=arpa',
        //'searchBindPass' => 's3r3t',

        // explicitly enable "Live Permissions" for LDAP
        'isLivePermissionSource' => true,
    ],

    // ...
],

If you need to perform a search, for example because users authenticate with the mail attribute, you can do that as well:

[
    // ...

    'authModule' => 'LdapAuthModule',

    'LdapAuthModule' => [
        'ldapUri' => 'ldap://ldap.example.org',
        'baseDn' => 'ou=people,dc=example,dc=org',
        'userFilterTemplate' => '(mail={{UID}})',
        'userIdAttribute' => 'mail',
        'permissionAttributeList' => ['eduPersonAffiliation'],

        // in case "anonymous bind" is not allowed, set these
        // **NOTE** use a read-only search-only account, not the actual admin 
        // account!
        //'searchBindDn' => 'cn=admin,dc=home,dc=arpa',
        //'searchBindPass' => 's3r3t',

        // explicitly enable "Live Permissions" for LDAP
        'isLivePermissionSource' => true,
    ],

    // ...
],

See Testing on how to test your setup.

SAML and LDAP#

When combining SAML and LDAP, you MUST make sure you configure both SAML and LDAP to use the same userIdAttribute and permissionAttributeList.

It is important that, when using SAML for authentication, the attribute you use there to identify the user, i.e. userIdAttribute is available “as-is” in the LDAP. You can’t use eduPersonTargetedID, pairwise-id, or any other “derived” attribute. Good candidate for user identification are mail, eduPersonPrincipalName, or uid, but feel free to choose one that is identical for both SAML and LDAP.

To configure LDAP, see the above LDAP section. For SAML we’ll use php-saml-sp as an example.

A complete example:

[

    // ...

    'authModule' => 'PhpSamlSpAuthModule',

    'PhpSamlSpAuthModule' => [
        'userIdAttribute' => 'uid',
        'permissionAttributeList' => [
            'eduPersonAffiliation'
        ],
    ],

    'LdapAuthModule' => [
        // the user's "uid" is part of the DN, so we can use the 
        // 'bindDnTemplate'
        'ldapUri' => 'ldap://ldap.example.org',
        'bindDnTemplate' => 'uid={{UID}},ou=people,dc=example,dc=org',
        'userIdAttribute' => 'uid',
        'permissionAttributeList' => ['eduPersonAffiliation'],

        // in case "anonymous bind" is not allowed, set these
        // **NOTE** use a read-only search-only account, not the actual admin 
        // account!
        //'searchBindDn' => 'cn=admin,dc=home,dc=arpa',
        //'searchBindPass' => 's3r3t',

        // explicitly enable "Live Permissions" for LDAP
        'isLivePermissionSource' => true,
    ],

    // ...
],

See Testing on how to test your setup.

Limitations#

The real time permission validation is currently ONLY done when using the VPN server API, i.e. when using the eduVPN / Let’s Connect! applications. The permissions will be retrieved “fresh” when the application requests a list of available profiles, and when it tries to connect.

If “Live Permissions” are retrieved during the use of the API they are not stored in the database, so they do not “propagate” and simply only used for that particular API call. There are currently two ways to propagate the changes.

Perform a new authentication (to the portal, or OAuth authorization);
Enable showPermissions option and have the user click the “Refresh” button on the “Account” page, see Testing below.

See Future Enhancements for work we plan to do on this.

Testing#

When “Live Permissions” is enabled, the portal has a “Refresh” button on the “Account” page that you can use to test the “Live Permissions”. You do need to enable the showPermissions option in /etc/vpn-user-portal/config.php to enable showing the permissions and the “Refresh” button:

[
    // ...

    'showPermissions' => true,

    // ...
]

After configuring “Live Permissions” you MUST test the following:

Pressing “Refresh” without changing anything in the IdM, i.e. your LDAP server or Static Permissions file, MUST show exactly the same permissions after the “Refresh”;
Changing something in the IdM, e.g. removing or adding a permission MUST immediately show up after pressing “Refresh”.

Once both these tests are successful all is configured properly.

If you do not want to expose the permissions or “Refresh” button to your users, you can remove (or set to false) the showPermissions option again. It is not required for this feature to work.

Future Enhancements#

There is still some work to be done:

Periodically check for connected VPN clients whether their permissions are still current, if not, kick them offline;
Make this also work for manual configuration downloads (solving previous point also solves this);
Introduce some kind of mapping, e.g. attribute X with SAML should be mapped to attribute Y with LDAP;
Make OIDC (OpenID Connect) a fully supported authentication mechanism with /userinfo calls to verify “Live Permissions”.