~eduvpn/server#88: 
make sessionExpiry depend on user

Currently the 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:

/etc/vpn-user-config/config.php has:

'sessionExpiry' => 'P90D',

The attribute value could contain the scoped value:

  • http://eduvpn.org/expiry/P1Y (1 year)
  • http://eduvpn.org/expiry/P12H (12 hours)
Status
REPORTED
Submitter
~fkooman
Assigned to
No-one
Submitted
a month ago
Updated
a month ago
Labels
No labels applied.

~samer_m a month 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 a month 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 a month 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 a month 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.

Register here or Log in to comment, or comment via email.