# Ignition + Azure SSO + Cloud based web application firewall

**URL:** <https://forum.inductiveautomation.com/t/ignition-azure-sso-cloud-based-web-application-firewall/71578>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [March 24, 2023, 10:27pm UTC](https://forum.inductiveautomation.com/t/ignition-azure-sso-cloud-based-web-application-firewall/71578 "2023-03-24T22:27:34Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rick\_Hornung](https://avatars.discourse-cdn.com/v4/letter/r/e9bcb4/32.png) [@Rick\_Hornung](https://forum.inductiveautomation.com/u/Rick_Hornung)\
**Post date:** [March 24, 2023, 10:27pm UTC](https://forum.inductiveautomation.com/t/ignition-azure-sso-cloud-based-web-application-firewall/71578/1 "2023-03-24T22:27:34Z")

</div>

I have a front-end gateway sitting in a DMZ, and I successfully setup Azure SSO, I can load the HMI by hitting the URL [https://server.net:8043/data/perspective/client/HMI](https://server.net:8043/data/perspective/client/HMI) it redirects me to Azure login, I use my Azure creds and all is right with the world.

When exposing to the internet, I want clients to be able to hit a URL on port 80, get redirected to 443 and continue to use SSO behind a web application firewall, in this case, barracudas web application firewall.

I setup the cloud WAF and everything works well, it forwards port 80 requests over to 443 and proxy's the connection to my front end gateway to port 8043 - but SSO breaks with error 400.

I rebuilt the Azure SSO using the outside URL, no change, under networking \> web server \> Public HTTP Address I've unchecked the box and specified the public address url and ports 80 and 443, no change. Turned on debugging and I get the message below in my ignition logs:

com.inductiveautomation.ignition.gateway.auth.web.strategy.WebAuthStrategyAdapterException: RelayState is empty

at com.inductiveautomation.ignition.gateway.auth.web.strategy.saml.SAMLWebAuthStrategyAdapter.lambda$parseState$0(SAMLWebAuthStrategyAdapter.java:410)

at java.base/java.util.Optional.orElseThrow(Unknown Source)

at com.inductiveautomation.ignition.gateway.auth.web.strategy.saml.SAMLWebAuthStrategyAdapter.parseState(SAMLWebAuthStrategyAdapter.java:410)

at com.inductiveautomation.ignition.gateway.auth.federation.FederationRoutes.callback(FederationRoutes.java:251)

at com.inductiveautomation.ignition.gateway.dataroutes.Route.service(Route.java:254)

at com.inductiveautomation.ignition.gateway.dataroutes.RouteGroupImpl.service(RouteGroupImpl.java:61)

at com.inductiveautomation.ignition.gateway.dataroutes.RouteGroupCollectionServlet.serviceInternal(RouteGroupCollectionServlet.java:59)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 24, 2023, 10:32pm UTC](https://forum.inductiveautomation.com/t/ignition-azure-sso-cloud-based-web-application-firewall/71578/2 "2023-03-24T22:32:03Z")

</div>

> [@Rick\_Hornung](#):
>
> I want clients to be able to hit a URL on port 80

Why? The native port for HTTPS is 443, and nothing should be going over any other protocol on the public internet. (I think you've overcomplicated this.)

---

<div class="post-metadata">

**Author:** ![Rick\_Hornung](https://avatars.discourse-cdn.com/v4/letter/r/e9bcb4/32.png) [@Rick\_Hornung](https://forum.inductiveautomation.com/u/Rick_Hornung)\
**Post date:** [March 27, 2023, 1:48pm UTC](https://forum.inductiveautomation.com/t/ignition-azure-sso-cloud-based-web-application-firewall/71578/3 "2023-03-27T13:48:20Z")

</div>

so any user can simply type in "[server.company.com](http://server.company.com)" and it takes them where they need to go - to make it as simple for my users as possible.

But alas, the redirects are not my issue, Azure SSO breaks through barracuda web application firewall - that's the issue that needs solved. And it's broken even if you don't use the redirects, or when they are turned off for testing so the redirects are a non-issue.