sessionExpiry is hard coded per server. We'll investigate to make this dynamic, for example through an attribute value provided by the IdM, e.g.
eduPersonEntitlement. We could define an attribute value that indicates the expiry for that particular user and override the global
sessionExpiry. For example:
'sessionExpiry' => 'P90D',
The attribute value could contain the scoped value:
i have included similar functionality in https://github.com/eduvpn/vpn-user-portal/pull/206 the feature is connectionExpiresAt and it affects connection expiry. authorization is kept as global settings 'sessionExpiry'
in the pull, UserInfo Class was modified to allow for more fields to be added in future like 'sessionExpiry'
It would be nice to keep this as simple as possible. Perhaps we need to rework the
permissionListidea to be something more generic, i.e. some additional user specific "flags" that is obtained from the IdM and update UserInfo with this information.
We could for example also move whether the user is an "admin" to this mechanism to have something generic.
The difficulty would be to make this somehow also work in SAML environments where you can't always control everything, so additional "mapping" might be needed (somewhere).
and it affects connection expiry
Okay. So not the OAuth authorization. Why did you separate those? It was intended for them to remain the same. I guess it is easier to implement to only focus on the VPN configuration?
the reason we used the already existing
permissionListis that it is coming from the same source and provide similar functionality. and as you mentioned it opens for more flags to be added.
we applied the expiry on the connection for some reasons 1- existing vpn deployment will have to do maintenance to delete existing OAuth authorizations for users that the configure with expiry. this would put some load on admin when configuring users is taking place on batches. having on connection level puts configuration on immediate effect upon connection as existing connection is removed the first thing. 2- the main purpose is to limit the user from connection. in some scenarios the user needs to get back to admin to extend his/her expiry. he/she does not have to reauthorize clients then. 3- there is a maintenance script for deleting disabled users. that can take care of non-extended expiry when it lapse.
Perhaps the easiest way to solve this is to only allow this for manual configuration downloads and not for the API. This would allow power users (with the required entitlement) to download configurations and (themselves?) specify the expiry. Or the maximum expiry from the entitlements is chosen, something like this.
Seems there is more interest in this feature. So I'll have to investigate how to implement this based on an attribute value from the IdM.
Now that the OAuth server part is (sort of) done, we also need to add this to vpn-user-portal. Work is ongoing. What started simple turned into a big refactor that I am currently not really happy about.
Hook again doesn't work, here is the commit for vpn-user-portal: https://git.sr.ht/~fkooman/vpn-user-portal/commit/7c535098f3b47479904787651d1e73eb360aaf95
Notes: currently if 0 (or more than 1) permissions match the
http://eduvpn.org/expiry#prefix, the default is used.
we could introduce a list of acceptable (user) sessionExpiry values that the admin can configure, that way things become a bit simpler...
what to choose if there are >1 user session expiry? the longest or the shortest? should this be configurable?!
Hmmm... the validation of the sessionExpiry value only takes place when it is actually used somewhere, e.g. on the "Home" page. Perhaps this should fail hard before loading any page/endpoint?
How to use:
'sessionExpiry' => 'P90D', 'userSessionExpiryList' => ['P7D', 'P1Y'],
This allows for users to have a value through
permissionAttributeListfrom the IdM to either change the sessionExpiry to
P1Y. There can only be 1 value per user, if there is no value, the default
sessionExpiryis used. If the value is not supported an error is shown to the user.
Unfortunately the user can't fix it themselves. So if there is >1 expiry, or an unsupported value perhaps it should simply be ignored and the default used?
Available in 3.3.4 release.