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.