auth.demo.com >> APM OAuth server
res.demo.com >> APM Client / resource OAuth server
res.demo.com/protectedurl >> OAuth protected resource
So when you go to res.demo.com/protectedurl you get redirected to auth.demo.com and you get asked to log in
So lets ay I have my OAuth tokens set to 20min refresh max and 5 min access token life
and lets say I have APM session inactivity on auth.demo.com set to 30min.
So once I have gone to auth.demo.com recieved my token and using it now on res.demo.com
I would expect every 5min the access token is refreshed
At 20min a redirect back to auth.demo.com would happen to get a new refresh token
I would expect that my APM session on auth.demo.com would still exist its only been 20min and inactivity is set to 30min.
But no that doesn't happen, it seems like a OAuth authorisation request terminates your APM session on auth.demo.com (also changes your cookies for auth.demo.com) so you don't have a valid APM session - so that means every 30 min you have to log back in.
How do you stop that, I am happy that if they are doing stuff on res.demo.com continiously that they shouldn't have to log back in.
But I also want those 5min and 20 min check in's so I can block at that spot.
Hey @AlexS_yb - it looks like your post might not have gotten an answer because of the holiday lull in traffic. I've asked one of my teammates to take a look and see if they can help you out, and will also feature this in this week's Highlights article to get more eyes on it.
If they've reproduced an error, they'll kick that up to product.
well this is the question is that an error, more research I do seems to suggest its not ...
Going to add some more to this.
The AIM build a SSO framework to protect mulitple uri on different VS with a single OAuth server.
I wanted the auth server (OAuth server) to be the place people login and also the place that OAuth tokens are generated.
It seems though that the way F5 have implemented this that tokens can only be issued via a special APM mode oauth_mode and seems like you can't have 2 APM sessions going at the same time.
So example johny goes to auth logins and setups a APM session - lets say inactivity is set to 1 hour.
Johny goes to https://res1/protectedurl this is protected by OAuth client (VPE). so res1 does a redirect to auth
Now auth realises this is a OAuth /authorise call and terminates the APM session (the login session johnny had) and will ask johny to login again ! thats not good. Because OAuth access token is set to max life 15min - this will happen every 15 min ! even worse.
The VPE object OAuth authorisation can't be created in a per request access policy - or atleast I have failed to do it and this seems to be the problem.
Because I want 1 VS to be auth and login I'm trying to figure out how to do it.
I thought why not put all of the OAuth onto another VS and use a pool to access it so that
https://auth -> VS
https://auth/<anything Oauth> -> p_OAuth server
the hope is here I can generate new mrh session token for the new VS and the pool will hide it away from the user
but how do I get the user info / user session from the auth VS to the OAuth vs - maybe a header with the session id. if the VS's are int he same partition they can access each others sessions !
seems overly complicated - any thoughts ??
I've had similar issues in the past. I'm trying to get a couple of other eyes on this, too..
As you've discovered, APM acting as OAuth AS deletes the user session immediately upon issuing a token. This isn't ideal if you want to keep the session alive doing multiple use cases.
APM as SAML IdP does not have this behavior. You may be better off using SAML. Another benefit of SAML is that you can pass more claims data in the assertion.
Yes seems like a bad design from F5 on this.
Yes i have saml in the mix already - but ... not good for scripting - saml by default uses posts.
there is artifacting binding - which uses a get and allow the SP to talk to the IDP directly by passing the client - but the F5 implementation doesn't work
I explained a potential work around with the OAuth apm being on a VS by itself behind the main VS - you would have to save and restore the APM tokens. Too much hard work for me right now 🙂