Cors preflight requests problem

[Johan_Lång]

I have two different web applications that make requests to domain names other than themselves. For example, x.domain.com makes a request to y.domain.com to retrieve certain data. The user is authenticated through APM, and we are using a multidomain sso.

The problem is that when the request is sent, BIG-IP will make an redirect to /my.policy and finally to /my.logout.php3?errorcode=19.

I've tried the workaround with this irule: https://devcentral.f5.com/s/articles/cors-implementation but it does not solve the issue.

The APM still not allow the request to reach its destination.

My only workaround is to let these requests go to a "public VIP", only with ASM as protection, but I want it to go through APM and the same VIP as the original site that is already authenticated.

Thanks!

Johan

[AlexBCT]

Hi Johan,

Do I understand it correctly that the backend server of the first web application (the server hosting x.domain.com) needs to reach y.domain.com in order to gather some information it needs to complete a request for the client?

If so, do you need that backend server to log in to the APM policy, or do you just need it to be able to reach the backend system? If you just need the backend system to gain access to the application, you could put in an agent in the APM policy BEFORE it gets to the login page? This agent can then check if the request is coming from a specific IP, or some other way in which you can identify that it is this server. If so, you can then bypass the login page and go straight through to the "Allow".

Of course, do ensure there is no other way anyone could exploit that 😉

Hope this helps.

[Johan_Lång]

Hmm, not quite, I think.

Isnt it the client who makes the acctual call to the backend server, y.domain.com?

x.domain.com responds with a 302 to the client with a new location header and the client trying to make a new request to the new location?

In your scenario, x.domain.com makes the acctual request to y.domain.com in the back, right?

But if there is way to accomplish that instead, im in! 🙂 but im not sure how to do that really..

Best regards,

Johan

[AlexBCT]

Ahyes, that's another way indeed - there are many ways in which you can get multiple components from different sources.

In that case, I think this is what you are looking for: https://techdocs.f5.com/en-us/bigip-14-0-0/big-ip-access-policy-manager-authentication-and-single-sign-on-14-0-0/single-sign-on-and-multi-domain-support.html You can configure the APM policy to be working for multiple domains, but only have a single login. Check under the heading "Configuring an access policy for SSO multi-domain support" for the exact instructions.

Basically you tell the policy to look out for requests for any of the following domains. In your case you configure the multi-domains as x.example.com and y.example.com, with probably x.example.com as your main authentication URL. You then attach the same APM policy to both virtual servers (x. and y.) and let the user go to either one. If the user is not logged in yet and goes to y., they will be redirected to the primary authentication URL (x. in the above example) for login, and then get redirected back to y. for the content. If the user first goes to x., they will log in first, then get redirected by the backend to y., which will check over the session details and allows it through without showing the login page again.

Hope this makes sense (..and works! 😉

[Johan_Lång]

Sorry for late reply.

I've already using multidomain. But I use it abit differently.

I got z.example.com as my primary url.

Then Ive added x and y as accepted hostnames in the access policy. With around 20 other urls. All dns-names poiting to the same VS.

You are basically telling me to use another VS and adding the same Access Policy to both of em? Does that even work ?

Regards,

Johan

[AlexBCT]

Hi Johan,

Jup, it works a treat - I've used it myself a few times as well.

Just keep a bit of an eye on the Profile Scope (can be found under the Properties tab of a policy) to ensure that multiple virtual servers can see the same sessions.

Have a look at the link I posted earlier for an example on how to deploy it - it will show you how it works with multple virtual servers.

[Johan_Lång]

I did as you suggested but still same problem.

A reference to Profile Scope:

• Virtual Server grants access only the resources behind the virtual server on which the session was established.
• Profile grants access only to resources that are behind the same access profile on any virtual server. (Default.)
• Global is equivalent to BIG-IP 11.x behavior. It grants access to resources behind any virtual server with an access profile for which scope is set to Global.

As default all AP is created with "Profile", and that should be enough and was active.

Primary URI: z.example.com

VS1:

DNS names:

z.example.com

x.example.com

VS2:

y.example.com

If you go to z.example.com, i could login to the webtop and press the link to x.example.com, but when I click the link to recieve data from y.example.com it still fails with an 302 redirect to z.example.com/F5Neworks-SSO-Req.........and so on. And finally get to https://z.example.se/my.logout.php3?errorcode=19 (x is telling the client to recieve info from y, but bigip interfares and dont let the client to get the content from y).

In the same session, if i open a new tab, and go manually to y.example.com i do not need to re-authenticate since im using the same AP, as you explained, and i can do the request without problem.

WIth other words, i can use two VS, with the same AP, but my main problem still persists. 😞

Thanks for your patience!

[AlexBCT]

Hi Johan,

Sounds like you are a step further at least! (just not with a working solution yet 😉

It sounds to me that there may be some entries missing from the Authentication Domains settings. Can you confirm that the Auth Domains tab looks similar to this one:

 

Also, in your reponse you mention a redirect to z.example.se - not sure if that is a typo and you mean z.example.COM or if this is a different domain, but either way ensure that this domain is also part of the Auth Domain list.

Let me know how you get on!

[Johan_Lång]

.se was a typo 🙂 sorry.

There is only z, x and y.example.com 🙂

My auth domains looks like your picture, yes! With the exeption that I have a default SSO config, and ofc not the host that ends with .se, but that should not matter either way 🙂

Thanks,

Johan

[AlexBCT]

Hi Johan,

Hmm, it's getting tricky... 😉 Without knowing the full application or configuration, I'm pretty stumped. My gut feel would be now that there is something missing in the VPE (maybe a branch that's not accepting that domain name, or a certain policy branch that gets taken that wasn't as expected.

Seen that the policy DOES get redirected to the z.xxxx domain, it means it's on the right track.

Here's some further troubleshooting tips;

• Using the log entries for the session, check how the session for y.xxxxxx flows through the access policy.
• Add a few Message Box agents to branches that may see the traffic from y.xxxxx and confirm that the policy follows the path through the policy that you expect it to take.
• By putting a Message Box just before you end up at a "Deny" in a policy, you can keep a session alive to investigate what the session variables looks like and possibly spot some issues in there.

Besides that, I'm not sure if I can help much further. Maybe someone else around here has an idea (and can possibly spot the error in my logic ;), or you could bring the case to F5 support.

[Johan_Lång]

I've partially solved my challanges now.

Most of the time the "second server" responds with json-responses.

Therefore I made an irulelx that get the requested content, chunks (50k chars each) it and send it over to irule since the rpc call has a limit of 64k per call. When all chunks is sent over to the irule, I restore it again and send (with http::respond) over it as an body to the client that did the original request.

So far so good, but then I found some pdf's... Up to 20 mb large. 20 million chars, divided into around 140 chunks, so i guess thats not the solution. I guess im stucked here, since the limit of 64k per call.

Is there something else I can do besides to ask the responsibles of the sites to move all "files" such as pdf and large images to the "main server"?

Best regards,

Johan

[Johan_Lång]

I can see now that my original question can be interpreted exactly as you did.

[samstep]

if you are using ASM it might be the culprit, check this:

Bug ID 746394: With ASM CORS set to 'Disabled' it strips all CORS headers in response.

https://cdn.f5.com/product/bugtracker/ID746394.html

Also if y.domain.com where your request is landing has an ASM policy in blocking mode please do check that OPTIONS method is not blocked in ASM policy (it is blocked by default)

[Johan_Lång]

Thanks for your reply, unfortunately we´re not using ASM together with APM.

/Johan