# Use of SAML with Containerized Ignition

**URL:** <https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269>\
**Category:** Ignition\
**Created:** [August 22, 2022, 2:15pm UTC](https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269 "2022-08-22T14:15:16Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\
**Post date:** [August 22, 2022, 2:15pm UTC](https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269/1 "2022-08-22T14:15:16Z")

</div>

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**

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

```

**SAML Trace**

```auto
    <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:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/8/a8b36bfe774e8ea457f31176d2d66e15ffe1ca50.png)

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

Thanks,

Nick

---

<div class="post-metadata">

**Author:** ![jspecht](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jspecht/32/6465_2.png) [@jspecht](https://forum.inductiveautomation.com/u/jspecht)\
**Post date:** [August 22, 2022, 3:14pm UTC](https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269/2 "2022-08-22T15:14:09Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\
**Post date:** [August 22, 2022, 4:28pm UTC](https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269/3 "2022-08-22T16:28:48Z")

</div>

@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:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/f/bfe38336d8d95e3cab1263e8dfed16ca36d39308.png)

What can I say, thanks for the inspiration?!

Nick

---

<div class="post-metadata">

**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\
**Post date:** [August 22, 2022, 6:27pm UTC](https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269/4 "2022-08-22T18:27:53Z")

</div>

Just to supplement this, you can also drive/override that setting for the Docker image by supplying [Gateway Arguments](https://docs.inductiveautomation.com/display/DOC81/Docker+Image#DockerImage-GatewayArguments): `gateway.useProxyForwardedHeader=true`

---

<div class="post-metadata">

**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\
**Post date:** [August 22, 2022, 8:25pm UTC](https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269/5 "2022-08-22T20:25:49Z")

</div>

@kcollins 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](https://docs.inductiveautomation.com/display/DOC81/Docker+Image#DockerImage-GatewayArguments): `gateway.useProxyForwardedHeader=true`

Thanks,

Nick

---

<div class="post-metadata">

**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\
**Post date:** [August 22, 2022, 9:52pm UTC](https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269/6 "2022-08-22T21:52:14Z")

</div>

> [@nicholas.robinson](#):
>
> is that something we can incorporate into the docker file

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:

```auto
# 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:

```auto
<?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:

```auto
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.

---

<div class="post-metadata">

**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\
**Post date:** [August 22, 2022, 10:11pm UTC](https://forum.inductiveautomation.com/t/use-of-saml-with-containerized-ignition/63269/7 "2022-08-22T22:11:39Z")

</div>

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