Forum Discussion
OAuth SSO like SAML Inline SSO possible?
Hi Folks,
I have the following challenge and I am unsure, how it can be solved.
- F5 APM as OAuth Authorization Server
- Web Application as OAuth Client + Ressource Server
Szenario 1: Internal Access
This works like a charme. The user go's to the Web Application, clicks on the OIDC Login Link, is redirected to the Authorization Server, etc. The classic grant flow.
Szenario 2: External Access through APM Portal
The customer demand is, to publish this web application through a F5 APM Webtop with single sign on. The Web Application does not support getting the JWT from the authorization header, therefore all Bearer SSO methodes are not working.
The application must go through the OAuth Grant Flow transparently for the user. This looks like the SAML Inline SSO method, but that is not possible with OAuth or do I miss anything?
I have two ideas, how this can be solved. It would be great, If someone knows an even simpler method.
- Publish the OAuth Server in the internet.
- Publish the Web Application through a new Virtual Server with an Access Profile attached.
- Add Portal Link to the Web Application.
- Span the access session accross both Access Profiles.
- Opening the Web Application from the Web Top -> works seamless with the same Access Session
- Clicking on the OIDC Login Link at the Web Application
- Redirect to the OAuth Server
- New Access Session begins and the user must login again -> BAD
The new access session for the Authorization server is required, because:
- The Access Policy must be validated to trigger the OAuth Authorization VPE Agent.
- The Access Policy is closed automatically after OAuth Authorization.
First idea:
- At initial login on the Webtop:
- Generate a secure domain cookie
- Set it in the browser
- Write a mapping table (ltm table) cookie->username
- At the OAuth Server:
- Get the cookie
- Lookup the username in the mapping table
- If found, set the OAuth username, else prompt for authentication
- OAuth Authorization works without user login again
Second idea:
At initial auth-redirect Request from the Web Application:
- Intercept the auth-redirect request
- Use a sideband connection to request the authorization code from the authorization server (skip authentication, authorization server is only available on the f5 itself)
- Use another sideband connection to send the authorization code via the redirect-request back to the Web Application
- Use the redirect-request response as the response for 1. and deliver it to the browser
This are the only two ideas I have, too solve this challenge. However, is it really as complex as I think or is there a really simple method I have overseen?
- Leslie_HubertusRet. Employee
Hi Juergen_Mang - I'm hoping Sven_Mueller can come by and answer this one.
Am I really the first to stumble upon this scenario?
- Dmitriy_SysoevNimbostratus
Hi @Juergen_Mang , we have exactly the same problem with the implementation of the web portal. Could you tell me, please, did you manage to choose the easiest option? the first option seems to be pretty easy.
No, the project is actually on hold.
I tend to implement option 2, because we must not publish the OAuth server and keep the communication internal.
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