Hi all,
There will be a SaToSa bar BoF on Wednesday, April 26, starting around
4:30pm at the I2GS conference hotel (though if that bar is too small, we
may move). If you are going to be at I2GS and want to talk about SaToSa,
come join us!
-Heather
Hello,
We are using SATOSA primarily as a SAML-to-SAML proxy. One of the IdPs
that federated with the proxy requires signed authn requests. I do not
see that the current verion of SATOSA allows one to configure that
authn requests sent to a particular IdP are signed. Please let me know
if I am incorrect.
The underlying pysaml2 library, of course, does support sending a signed
authn request. It also supports the option "authn_requests_signed":
"Indicates if the Authentication Requests sent by this SP should be
signed by default. This can be overriden by application code for a
specific call."
I suspect SATOSA would pass through the authn_requests_signed option to
pysaml2 already, but I am more interested in being able to control
signing on a per-IdP basis, rather than making it the default for all
IdPs.
Patching SATOSA so that one could configure signing for particular IdPs
looks straightforward. I suspect the largest issue would be the
configuration (yaml) syntax.
My proposal is that saml2_backend.yaml look like this for such a scenario
(leaving out the other options and boilerplate):
module:
satosa.backends.saml2.SAMLBackend
name:
Saml2
config:
sp_config:
service:
sp:
relying_parties:
https://some.idp/entityid:
authn_requests_signed: True
https://another.idp/entityid:
authn_requests_signed: True
This format would be easy to extend over time to enable per-relying party
overrides for the options that pysaml2 allows to be configured per flow.
Thoughts?
Thanks,
Scott K
Hello,
Does SATOSA currently have a URL endpoint that is "satisfactory" and
"clean" for a service health check when running the service behind a
load balancer like Amazon ELB?
I am thinking of something like
https://proxy.my.org/status
If it does not exist already, I propose such an endpoint be added.
Initially all it needs to do is reply with '200 OK' to indicate that the
service is alive. Eventually as time and needs permits it could be
evolved to do something more sophisticated.
Thoughts?
I will open a GitHub issue if nobody objects or tells me that this
functionality already exists.
Thanks,
Scott K
