So I have
login -> This is my login server - I have APM protecting it
auth -> this is my oauth server it talks to login to get login its a saml call
Lets say I have
https://uat/<some protected URL>, that I use a OAuth claim to protect it.
So when i go to https://uat/<some protected URL> I get
redirect to /my.policy
then redirect to auth/oauth url
redirect to auth/my.policy
redirect to login/saml end point
redirect to /my.policy
redirect to /my.policy the login process
redirect to auth/sam return end point
redirect to https://uat/Oauth return point
redirect back to https://uat/<some protected URL>
When it works its okay, but what happens with a bad password or if a user takes to long to login and has to start a new login session any break from normal means that user ends up on https://login/
I have noticed on other SSO work flows - the originating url is in the url passed around - that doesn't happen on F5
I checked the landing on the inital entry to https://auth and the browser doesn't even send the referrer url ...
How do poeple cope with this. Note my apm session are on different F5, so I can't share behind the scene variables !
28-Nov-2022 02:09 - edited 28-Nov-2022 02:23
I admit I do not follow the text as the way you have written it is not very clear at least for me and maybe a picture can help. About sharing session variables can't you insert a session variable an an HTTP header between the F5 devices?
Also for Oauth just you can use F5 Oauth SSO in "Passthrough" with a JWT token if possible and I think you are not using the F5 devices as Authorization servers and the first f5 APM is Oauth Client/Resource Server then you can make the second F5 with the SAML just resource server and use the info in the token.
If I got it wrong and the F5 APM is authorization server with claims and JWT Access token you can share info like session variables between the F5 APM AS and the F5 that is Client/Resource server.
If the customer first accesses the first F5 APM oauth device and then the customer accesses the second F5 SAML device with Browser URL redirection you may need to share the session varibles by inserting them in a cookie and then reading from them.
Still why you are using Oauth and SAML is strange as Oauth can do anything SAML can do but better with the authorization codes that Oauth uses and for now there is no way to exchange SAML token for an Oauth or vice versa or to use the same token for SAML and Oauth to make life easier 😀
28-Nov-2022 13:05 - edited 28-Nov-2022 13:07
Thanks for the input, see if i can try again
https://uat/some/protected/url << APM policy that use oauth client - client/resource
If I don't have a APM session the first response is a 302 to /my.policy
I don't get to run any code - how do I insert a cookie at this stage don't think i can ?
https://uat/my.policy does the redirect to https://auth/someOAuth URL (<< this is the oauth server ) it doesn't know what the original URL was.
01-Dec-2022 06:11 - edited 01-Dec-2022 06:22
About the cookie it is in the links I shared with you that you can take a look at 🙂
Stange from what I have seen after you are returned from the Azure AD you get the url you tried to open. The issue you mentioned I have only when playing for example with the https://petstore.swagger.io/ as a pool member test app as to when I do not send a specific correct request the F5 APM just can't fetch the page. The issue was resolved when I attached URI rewrite profile so that when I send the http traffic to the pool members to change the URI to the real one that that the pool members use so I do not see this issue as it is normal when F5 can't resolve the HTTP request will the backend servers to give you a hint like in my case it was""" xxxx/oauth/login.jsp """ and the below message.
Outside of that it could be a bug so I am on 188.8.131.52 so upgrade to it or you may try URI redirec in the policy as the your landing URI is saved to variable session.server.landinguri , so you may to use something like the link below or an iRule as given in the next Links to "get" the session variable and then to use it for an redirect event.
That are all my ideas.
Think I haven't explained to well.
Setting a cookie on a APM call. why I asked about this is because of the interaction between irules and APM, I can set it on http_request but that just sets it to the back end pool. I thnk I need to set it on http_response - how does that work on APM calls
Not sure where azule AD came up. All components are on F5 - different boxes
SAML login -> https://login.local
OAUTH server -> https://auth.local
resource server -> https://resource.local
The protected URL
APM for VS that has https://resource.local protects the url with an OAuth client (VPE). then does the redirect. At this point the original URL is lost - its not part of the URL and it hasn't been saved as a URL.
I guess because I have lots of landing places for OAUTH I can't use client id and post back.
I notice a lot of other SSO's append the destiation URL to the url so
https://resource.local/protectedURL would turn into https://resource.local/login/protectedURL
and maybe https://auth.local/login/https://resource.local/protectedURL
presumably with url encode.
As I mentioned on my Azure AD intergration I do not see your issue, so this could be limited to your environment. Also for the cookie part there is really a lot of examples from F5 or in the commnity if you just search for them.
Examples. It is for portal access but you may test it to see if it works for you as well as your issue indicates that you may need to do a lot of testing. You may need to access the session variable for the landing URL in with "ACCESS::session data gest", save it to a normal irule variable as to use it in later events like HTTP_RESPONSE or HTTP_RESPONSE_RELEASE (this is when the F5 generates the response but as it is not the case with you maybe using portal access HTTP_RESPONSE could be the right event for you).
You can trigger iRules in APM with an Agent but maybe this willl not be needed as when you want to add something to the the Response not Request then this means that the user should have passed the APM policy, but I am just sharing with you.
Outside of that I can't suggest anything else as I am not familiar with your network environment like you are as you can see that F5 generates HTTP 301/302 redirect to the client (you can see with HTTP debuging on the client https://support.f5.com/csp/article/K35932460 ) and maybe not the cookie but as mentioned in previous messages changing the HTTP redirect could help. That is what I can share and hopefully it helps you to investigate your issue.
You - well I haven't been able to set a cookie during the initial redirect to /my.policy
cookie going to the client not the back end.
31-Dec-2022 05:20 - edited 31-Dec-2022 05:24
Cookies go to the clients not the backend as this is just how they work. For backend just set http header as there are many ways for that, so you just need a server side event like HTTP-RESPONSE . Happy New Year from me as now is not the time to do F5 stuff but to celebrate 🤩