7:40 p.m.
On 2017-04-17 21:12, Scott Koranda wrote:
Overriding metadata with a local setting in SATOSA allows us to
configure one tool instead of having to add additional tools to manage
the local copy of metadata.
I guess ... but where does that end? Do we support overriding endpoints?
On 2017-04-17
21:01, Scott Koranda wrote:
Isn't that the federation operators job - to fix issues?
I am not a federation operator.
I do know that this particular IdP uses a software stack that is not
Shibboleth or SimpleSAMLphp and is not particularly well operated from a
federation perspective, but is considered important because of the
community it represents (if it does not actually serve the community).
Progress with it has been slow, if at all, and the federation operator
has other higher priorities.
Doesn't it make sense to let metadata govern this? Just lookup the IdP
in metadata and sign the authn request if "wantAuthnRequestSigned" flag
is set (at least thats what I think its called) ?
In an ideal federation, yes. Unfortunately we find some IdPs cannot
or will not update their metadata appropriately.
We could always provide our own copy of the IdP's metadata, but that
brings with it its own maintenance issues.
The primary reason for deploying the proxy is to work around limitations
of federated IdPs. This is just another example.
sure but how is keeping a local copy of the metadata any different (or
any simpler) than overriding metadata with local settings? I think SATOSA should offer as much flexibility for
overriding as other
software used by SPs, such as the Shibboleth SP or SimpleSAMLphp.
Thanks,
Scott K