Single Sign-On (SAML / OpenID) #3
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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
simplesamlbranch.Currently stuck on how best to edit the
mediawikicontainer Apache config to also serve SimpleSAMLPHP, or whether to have yet another HTTP server container in the stack.Maybe it's possible to route
/simplesamlphpto 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
metadataa 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/simplesamlphpis 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.phpafter install, because SimpleSAML can't use the samephpsessionstore as Mediawiki, butvenatorfox/simplesamlphpdoesn't have an env var option to setstore.sql.dsn. There's already a custom SimpleSAML entrypoint so we can probably swap it out withsedor something./var/simplesamlphp/logis volume mounted - this might be fine, as not mounting it requirestty: true, and--rawwhen 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/consolesymlink that thesimplesamlservice sets up.Copyingmetadataandcertto thesimplesamlcontainer 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 thesimplesamlvolume to themediawikiservice 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.ymlor something like that. In yourcompose.saml.ymlyou only need to write the high-level service key and the volumes + the new volume. This might mean you need to abstractSAML_ENABLED=0out of your config in some way? I hope that is clear...