~samer_m 2 years ago

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'

~fkooman 2 years ago

It would be nice to keep this as simple as possible. Perhaps we need to rework the permissionList idea 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).

~fkooman 2 years ago

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?

~samer_m 2 years ago

the reason we used the already existing permissionList is 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.

~fkooman 1 year, 10 months ago

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.

~fkooman 1 year, 8 months ago

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.

~fkooman 1 year, 8 months ago

https://todo.sr.ht/~fkooman/php-oauth2-server/4

working on it here.

~fkooman 1 year, 8 months ago

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.

~fkooman 1 year, 8 months ago

Hook again doesn't work, here is the commit for vpn-user-portal: https://git.sr.ht/~fkooman/vpn-user-portal/commit/7c535098f3b47479904787651d1e73eb360aaf95

~fkooman added v3.x 1 year, 8 months ago

~fkooman 1 year, 8 months ago

Notes: currently if 0 (or more than 1) permissions match the http://eduvpn.org/expiry# prefix, the default is used.

~fkooman 1 year, 8 months ago

we could introduce a list of acceptable (user) sessionExpiry values that the admin can configure, that way things become a bit simpler...

~fkooman 1 year, 8 months ago

what to choose if there are >1 user session expiry? the longest or the shortest? should this be configurable?!

~fkooman 1 year, 8 months ago

François Kooman referenced this ticket in commit ac96c53.

~fkooman 1 year, 8 months ago

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?

~fkooman 1 year, 8 months ago

How to use:

'sessionExpiry' => 'P90D',
'userSessionExpiryList' => ['P7D', 'P1Y'],

This allows for users to have a value through permissionAttributeList from the IdM to either change the sessionExpiry to P7D or to P1Y. There can only be 1 value per user, if there is no value, the default sessionExpiry is 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?

~fkooman 1 year, 8 months ago

François Kooman referenced this ticket in commit 86c9501.

~fkooman 1 year, 7 months ago

François Kooman referenced this ticket in commit 9d19e0e.

~fkooman REPORTED CLOSED 1 year, 7 months ago

https://docs.eduvpn.org/server/v3/session-expiry.html#per-user-session-expiry

Available in 3.3.4 release.