Forum Discussion
OAuth server setup Q - APM
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 ??
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.
- AlexS_ybJan 28, 2023Cirrocumulus
Hi
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 🙂
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com