Single Sign-On (SAML / OpenID) #3
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
OpenID is probably easier.
But, we've already done Ansible config for SAML, and it'd be useful for that project.
Made a little progress on SAML in the
simplesaml
branch.Currently stuck on how best to edit the
mediawiki
container Apache config to also serve SimpleSAMLPHP, or whether to have yet another HTTP server container in the stack.Maybe it's possible to route
/simplesamlphp
to another container without having to modify the Mediawiki container Apache config, using Traefik routing rules?In that case, the only puzzle left for SAML is the best way to provide metadata to the container. At worst, making the
metadata
a volume and asking users to copy it over manually might be bearable.Yeah, the rules documentation kinda looks a bit scary but it was not that bad to manage. An example of it in use is for the SSH access for the Gitea instance, see https://git.autonomic.zone/autonomic-cooperative/git.autonomic.zone/src/branch/master/compose.yml#L52. I think it is a good approach and yes, very nice to avoid modifying the container config.
I got the Traefik routing working (thanks!) and SimpleSAML is up'n'running on the same domain, now I just need to hack on the Mediawiki plugin side.
Working!
Statement of technical debt:
/var/simplesamlphp
is mounted as a volume to be able to share the SimpleSAML code with Mediawiki's SAML plugin. I think this is going to make SimpleSAML upgrades harder, because all the code lives on that volumeconfig/config.php
after install, because SimpleSAML can't use the samephpsession
store as Mediawiki, butvenatorfox/simplesamlphp
doesn't have an env var option to setstore.sql.dsn
. There's already a custom SimpleSAML entrypoint so we can probably swap it out withsed
or something./var/simplesamlphp/log
is volume mounted - this might be fine, as not mounting it requirestty: true
, and--raw
when usingabra logs
, but it's worth making sure. If we want to setDOCKER_REDIRECT_LOGS
, we'd need to special-case the SimpleSAML code when running in the Mediawiki container, because it can't access the/dev/console
symlink that thesimplesaml
service sets up.Copyingmetadata
andcert
to thesimplesaml
container is currently manual, although it's not too bad withabra cp
. We should at least document this.~~The worst bit, and what's blocking me merging this into
main
, is that I'm not sure how to selectively disable adding thesimplesaml
volume to themediawiki
service ifSAML_ENABLED=0
. @decentral1se any ideas on that? ~~Otherwise we could have alternative, manually-synced compose files for SAML / non-SAML..I think your best best is to go with another compose file for this. You can override them easily with something like
docker stack deploy -c compose.yml -c compose.saml.yml
or something like that. In yourcompose.saml.yml
you only need to write the high-level service key and the volumes + the new volume. This might mean you need to abstractSAML_ENABLED=0
out of your config in some way? I hope that is clear...