Use of SAML with Containerized Ignition

I’m looking to see who has experience using SAML for SSO with containerized Ignition.

We use SAML successfully on all of our gateways which are run on VM’s.

We are beginning to stand up Ignition with Docker but we’re seeing a few new behaviors.

Specifically when dong a test login we cannot get a response and when we look at Ignition logs and google SAML trace we see the following things:

Logs

SAMLHttpResponseFactoryException: Expected SAML Response Status of Success but got 'REQUESTOR'

SAML Trace

    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester" />
        <samlp:StatusMessage>Unknown AssertionConsumerServiceURL http://<snipped>t.com/data/federate/callback/saml</samlp:StatusMessage>
    </samlp:Status>

What is curious in the SAML responses is that the assertion URL is HTTP but we specify HTTPS everywhere (both in the gateway and on the IDP side). Also, in the SAML trace we see this “bridge” which we do not see when we call the IDP from VM’s:

If anyone has experience with SAML in the context of containerized Ignition we’d appreciate any comments.

Thanks,

Nick

It should work the same in a docker container, assuming the same network architecture and configuration. Are there any additional middleware such as reverse proxies in the docker environment that do not exist in your original VM environment?

@jspecht we do have our companies cloud native platform between the Ignition app and the IDP, so it is not the same architecture (probably) but I do not know exactly how it is different.

I did enable this setting in the web server section just to try it and it allowed us to get an expected proper SAML response so functionally this did the trick:

What can I say, thanks for the inspiration?!

Nick

1 Like

Just to supplement this, you can also drive/override that setting for the Docker image by supplying Gateway Arguments: gateway.useProxyForwardedHeader=true

1 Like

@kcollins1 is that something we can incorporate into the docker file or can it only be used at the time of docker run?

Just to supplement this, you can also drive/override that setting for the Docker image by supplying Gateway Arguments: gateway.useProxyForwardedHeader=true

Thanks,

Nick

There are a couple of ways to approach this. First way would be to add a gateway.xml_clean file to your build context that has the added entry for gateway.useProxyForwardedHeader. You can extract the base one from the image with:

# Lets assume you're in the folder on your host with the Dockerfile
# Start up a temporary (--rm) container with a bind-mount to the 
# current directory (-v) and set the entrypoint to bash (--entrypoint)
# so we can run (-c) a copy of the image's `.gateway.xml_clean` to our
# local system.
docker run --rm -v "${PWD}":/host \
    --entrypoint "bash" \
    inductiveautomation/ignition:8.1.19 \
    -c "cp data/gateway.xml_clean /host/gateway.xml_clean"

Inspecting this file will show the following:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Context Settings</comment>
<entry key="gateway.port">8088</entry>
<entry key="gateway.sslport">8043</entry>
<entry key="gateway.acceptCount">100</entry>
<entry key="gateway.maxThreads">300</entry>
<entry key="gateway.maxKeepAliveRequests">200</entry>
<entry key="gateway.connectionTimeout">60000</entry>
<entry key="gateway.keepAliveTimeout">60000</entry>
<entry key="context.props.version">3</entry>
<entry key="context.startup.useautobackups">true</entry>
<entry key="localdb.autobackup.count">5</entry>
<entry key="localdb.faultbackup.count">3</entry>
<entry key="localdb.autobackup.delay">2</entry>
<entry key="gateway.metroSSLPort">8060</entry>
</properties>

You can modify that file to include an XML entry with key of gateway.useProxyForwardedHeader and value true. Once you’ve done that, you can update your Dockerfile to include something like below:

ARG IGNITION_VERSION
FROM inductiveautomation/ignition:${IGNITION_VERSION:?}

COPY gateway.xml_clean "${IGNITION_INSTALL_LOCATION}/data/gateway.xml_clean"

At this point, if you build that image, the entrypoint will use that updated gateway.xml_clean as the base for setting up the gateway on first launch and you’ll observe that box being checked in the UI.

ALL OF THAT SAID, if you are already pre-loading a base GWBK in your Dockerfile, you must update that base GWBK with the setting as it will take precedence over the baseline image configuration.

Hmmm, we have to go into the gateway to manually setup the SAML IDP at least once so it seems like managing this by gateway backup file is the way to go for now.

That brings 2 other topics to my mind:

  1. It could be convenient that when a gateway back up is made, we have some module etc. that automatically sends that backup to the git repo we are working from. Then instead of manually copying the .gwbk to the git repo, whenever the container starts again, it would be using the most recent backup.

  2. If there was some way to pass in the SAML metadata URL and have ignition automatically setup an identity provider (and all associated settings) that could make it worthwhile to automate what we are discussing here so that each new instance starts up using SSO and we never even have to use manually set UUID and PWD

No need to respond, I’m just brain storming here…

Thanks,

Nick