UserSessionTimeOutInterval key doesn't take effect on VM Portal

[gregsheremeta]

Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=1667489

UserSessionTimeOutInterval for engine-config is used to set timeout interval in minutes, after which inactive user sessions expire. It doesn't take effect for VM Portal, but works perfectly for Admin Portal.

See also #598

[sjd78]

UserSessionTimeOutInterval for engine-config is used to set timeout interval in minutes, after which inactive user sessions expire. It doesn't take effect for VM Portal, but works perfectly for Admin Portal.

We use the same SSO token (with the same grant type and scope) for all of the REST calls. So the background data update task cannot be differentiated from real user generated traffic. The token will never expire like that. The REST calls would need to have some kind of HTTP request header available to instruct SSO token validation not to update the last access date. I have no idea if that is currently an option.

[gregsheremeta]

I have no idea if that is currently an option.

@noriravi what do you think?

[noriravi]

Currently all restapi queries will update the last access date, we would need to modify the restapi code and backend code to achieve what is requested here. I would suggest opening a BZ.

[gregsheremeta]

Currently all restapi queries will update the last access date, we would need to modify the restapi code and backend code to achieve what is requested here. I would suggest opening a BZ.

Thanks! @sjd78 can you open the BZ and describe what we need? team = infra Thanks!

[gregsheremeta]

[ blocked by REST API enhancements needed ]

[michalskrivanek]

@sjd78 are you sure about the same scope for all queries. Some time ago when iportal was timing out for everyone, iirc we made a differentiation for the refresh andnother calls. Or maybe we just wanted to and didn’t do it, i don’t quite recall

[sjd78]

@michalskrivanek - As I understand how the SSO works, the scope and grant type are correlated to the SSO token at the time the token is created (so login box time). The REST code all uses the same SSO token either from the dev engine pulling it or passed from the wrapping WAR. I also can't find any instances where API calls are made with custom headers other then content types and "Filter".

So as long as the scope for a single SSO token is constant, then yes, all the requests use the same scope.

[michalskrivanek]

Ok, them we omly wanted to do that but didn’t:) right, it’s #308 I do not understand why we ended up using ovirt-app-api and not ovirt-app-portal scope

[noriravi]

Michal is right, if you obtain the token using ovirt-app-portal scope the last access date is not updated on restapi calls for that token.

[michalskrivanek]

@noriravi yes, but AFAICT from the code it's not doing anything right now - QueriesCommandBase::executeCommand() updates session time when
getParameters().getRefresh() || SessionDataContainer::isSsoOvirtAppApiScope() which is set by
scopes.contains(OVIRT_APP_API_SCOPE) &&
!scopes.contains(OVIRT_APP_ADMIN_SCOPE) &&
!scopes.contains(OVIRT_APP_PORTAL_SCOPE));

so...the portal scope currently behaves same as admin and then...does it just honor the refresh parameter? If yes we can just set it explicitly...

[michalskrivanek]

but if that doesn't work we can really just use a app-level timeout

[michalskrivanek]

@gregsheremeta @sjd78
which is basically what #399 was opened for. So...just do that:-)

[sjd78]

@michalskrivanek, @noriravi - If the last access date in not updated on the token, won't it simply expire after the configured session timeout all the time? So the token would only be good for say 15 minutes and then require a re-login? Or is there another SSO call that we can pulse to keep the session alive?

One more question - is it possible to use a SSO token to grab a new derived SSO token with a different scope and use that derived non-refreshing token for the background refresh?

[noriravi]

We have 3 scopes on engine side.

ovirt-app-api scope for restapi. Tokens obtained using this scope when used to execute a query will always refresh the last access date. This was intended to be used by SDK which always closes the connection and performs a logout which terminates the session.

ovirt-app-admin scope for webadmin: Tokens obtained using this scope when used to execute a query will only refresh the last access date when the webadmin constructs the QueryParameters and set refresh to true. This works very similar to ovirt-app-portal scope. Only a period of inactivity will close the session.

ovirt-app-portal scope for UserPortal: Tokens obtained using this scope when used to execute a query will only refresh the last access date when the UserPortal historically constructed the QueryParameters and set refresh to true.

Any "action" executed using a token obtained using any of the 3 scopes will refresh last access date.

Issues with restapi:
We do not have a way to set "refresh" to true when using restapi since for SDK we always assumed SDK will logout after all the work is done.

Now if we want to use ovrt-app-portal scope to access restapi, the token will not get refreshed and will expire after 30 minutes. If we would like to have more control over when the session expires or some how would like to refresh the session we have 2 options. Both require code changes

1. Add ability to send "refreshToken" parameters with restapi calls. This requires touching restapi code and would be an RFE

2. Execute an action in the backend with the token obtained with ovrt-app-portal scope. This will refresh the last access date. I can add a simple RefreshTokenLastAccessDateCommand or KeepSessionAliveCommand which will set the last access date. The action needs to execute once every 29 minutes (session expires in 30 minutes) to keep the session alive. Much simpler to implement.

@michalskrivanek
Yes ovirt-app-admin and ovirt-app-portal work the same way. We have no way to send refresh via restapi. We need to construct QueryParameterBase and set the value to true to pass it.

@sjd78

We cannot use a SSO token to grab a new derived SSO token

[sjd78]

We have 3 scopes on engine side.

Thanks for the summary, very much appreciated.

2. Execute an action in the backend with the token obtained with ovrt-app-portal scope. This will refresh the last access date. I can add a simple RefreshTokenLastAccessDateCommand or KeepSessionAliveCommand which will set the last access date. The action needs to execute once every 29 minutes (session expires in 30 minutes) to keep the session alive. Much simpler to implement.

I like this approach. web-ui can pulse the keep alive as needed and be able to give a count down timer to auto log off. I'll create a BZ to get that service created.

@sjd78

We cannot use a SSO token to grab a new derived SSO token

That is what I suspected, thanks for confirming.

[michalskrivanek]

You could also implement app-side timeout and just track time within ovirt-web-ui and discard token when exceeded. It’s kind of redundant to the potential engine side change, but OTOH it keeps the logic and control in one place

[sjd78]

You could also implement app-side timeout and just track time within ovirt-web-ui and discard token when exceeded. It’s kind of redundant to the potential engine side change, but OTOH it keeps the logic and control in one place

Ok, it took me awhile to sort out what you're saying, but I think I'm there now. Easiest solution looks to be to add user activity detection to the app. If the app thinks the user hasn't interacted for an amount of time, follow the session timeout pattern (patternfly pattern description, patternfly-react3 impl) and give the user a count down to logout timer w/ 1 minute remaining. When the timer expires, make the call to invalidate the SSO token and push the user back to the login page.

If we change the SSO token scope, we would need the mechanism to keep the token alive while the user is navigating the app. Leaving the scope alone lets us handle it ourselves in the react app.

NOTE: We should probably query a configured user session/inactivity timeout from the server. I'm not sure if one exists that we can reuse or if we should create a new one just for web-ui. Either way, that's an easier part of the work.