Can env vars be referenced in shibboleth2.xml?

[Wessel, Keith]

Scott, any chance that there's an undocumented env var for the location of the Unix socket that both shibd and mod_shib will consult? If not, I can just include a modified shibboleth2.xml in both containers, but an env var would be lovely.

Keith


-----Original Message-----
From: Wessel, Keith 
Sent: Wednesday, September 30, 2020 8:45 AM
To: users at shibboleth.net
Subject: RE: Can env vars be referenced in shibboleth2.xml?

Peter,

I hadn't actually thought of sharing a volume mount between the two containers for the unix socket. I'll try that this morning. That would certainly make my life simpler.

If that doesn't work, yes, I'm already planning to set an env var in both containers of the shibd TCP address. Since I'm not exposing port 1600 to anything outside the container, there's seemingly no risk at setting my acl cidr to 0.0.0.0/0 and letting the firewall around the container keep it safe.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Peter Schober
Sent: Tuesday, September 29, 2020 6:30 PM
To: users at shibboleth.net
Subject: Re: Can env vars be referenced in shibboleth2.xml?

* Wessel, Keith <kwessel at illinois.edu> [2020-09-30 00:17]:
> In AWS, the TCP listener address will always be localhost, and the acl 
> list will always be localhost (equivalent IP, of course).
> In docker-compose, though, it's going to be an IP address other than 
> localhost's. So, doing this somewhat dynamically is the goal, of 
> course.

To support the most fundamental workings of the software (telling shibd where to listen on and from whom to allow connections, telling Apache httpd where to connect to shibd) I suppose literally extending the SP to take the values of these settings (address, port, acl attributes on the TCPListener) from environment variables would be a sensible way forward.
(Or maybe sharing the Unix domain socket from the shibd container to the httpd one via a volume mount.)

Something else would then still have to perform the service discovery parts and inject the dynamically determined IP address of a running shibd container as env vars into your httpd container, but that'll be the same whatever you're doing here.

Btw, the network between httpd and shibd is assumed to be "private"
and hence "secure"? Otherwise you'd have to ensure transport layer security, e.g. using stunnel (on both ends!) for that connection, too. Which would mean two additional processes. And if you stuck these additional processes into additional containers (as per your own
requirements) you're stuck in a loop trying to secure the connection to the stunnel process.
Also stunnel doesn't allow reading of IP addresses to connect to (or listen on) from environment variables, either. So that would merely shift the problem from Shib (which would always have address and acl set to localhost) to stunnel configuration.
(While the alternative ghostunnel doesn't seem to support environment variables either at least it supports supplying the necessary parameters as options on the command line, contrary to stunnel. Everything else above applies just the same.)

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net