[eduVPN-deploy] Profile Authorization / ACLs / Permissions

[François Kooman]

Hi all!

One of the big(ger) changes planned [1] for Let's Connect!/eduVPN is to
move away from "real time" authorization to determine which profiles a
particular user has access to. This is only relevant if you want fine
grained access control to the VPN profiles you defined. For example,
only certain users that can login to your VPN service get access to a
restricted profile.

Currently, two mechanisms are supported for this:

- LDAP
- OpenVOOT

When you configure them correctly, this means that when the user logs in
to the portal, uses the API from the native applications or connects to
the VPN, a check is performed if the user (still) has the required
permissions to access the profile.

This actually works really well for the LDAP case, but it is the only
case where it works well. The drawback is that an LDAP "system account"
is required that is able to connect to the LDAP server "out of band" to
verify the user's permissions.

OpenVOOT has some problems, which has mostly to do with the
implementation in The Netherlands, not _specifically_ VOOT. As we do not
foresee any improvements in the VOOT implementation in The Netherlands,
and no other party implements VOOT, we decided to drop support for it,
simplifying the code base significantly.

As LDAP would be the only "real time authorization" option left, we
decided to drop support for this as well, and instead take a different
approach to handling profile authorization that will be neatly supported
by all authentication backends.

The currently supported authentication backends are: local database
(default), LDAP, RADIUS and SAML. Those mechanisms all have the option
to provide additional "attributes" to the service that can be used to
make authorization decisions. For example LDAP has the "memberOf"
attribute, SAML has, at least in R&E federations, eduPersonEntitlement
and/or eduPersonAffiliation. With RADIUS additional (authorization)
information can be provided as well!

So the solution we arrived at is this: cache the authorization
information for a certain amount of time for all authentication backends
and make the cache duration configurable for every VPN server. Some
servers would like to require the user to authenticate every 8 hours,
others may be happy with 3 months, and maybe some would not require the
user to ever authenticate again.

There is some precedent for this: in R&E identity federations the
browser session duration for access to SAML protected web services is
typically 8 hours, thus "caching" the authorization information for up
to 8 hours.

Of course in case of "emergency" there is always the option to
(manually) disable users if their VPN connection needs to be terminated
immediately, for normal operations there would be no such need though.
Even if a student is no longer a student, they typically have access to
the university's resources for a certain amount of time after they graduate.

The way this new permissions model will be implemented is this: issue
OAuth tokens and certificates that expire at the exact same time
together with the browser session. So if a VPN server chose to require
the user to authenticate every 8 hours, the browser session, the OAuth
token (actually the refresh_token) and the issued X.509 client
certificate will all be valid for exactly 8 hours after user
authentication, thus forcing a new authentication every 8 hours. This
already works well with the Let's Connect!/eduVPN applications!

The nice thing about this is, that also 2FA authentication can be added
to this flow. So whenever the user needs to authenticate, also a second
factor may be required, removing the need to integrate this in the
"connect to the VPN server" flow as currently supported by the
applications. There are additional reasons why we want to move in this
direction regarding 2FA, but more on this later.

If you have any questions, ideas, worries, let me know!

Regards,
François

[1]
https://helium.tuxed.net/fkooman/SN_2018-11/Short%20Term%20Work%20Items.pdf