8:27 p.m.
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
6:48 p.m.
On 2017-04-16 22:27, Scott Koranda wrote:
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.
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) ?
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
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
7:01 p.m.
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.
Thanks,
Scott K
7:04 p.m.
On 2017-04-17 21:01, Scott Koranda wrote:
Isn't that the federation operators job - to fix issues?
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?
Thanks,
Scott K
7:12 p.m.
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?
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
7:47 p.m.
I guess ... but where does that end? Do we support
overriding endpoints?
I understand the concern and agree that it bears watching.
My vision/hope for SATOSA is that it is a pragmatic tool for research
VOs to deploy a proxy and make international federation work. It should
not do everything and be any more complex than it has to be, but at the
same time it will be helpful to the VOs I work with if it can help
"paper over" the realities of international federation today.
Thanks,
Scott K
9:39 p.m.
On 2017-04-17 21:47, Scott Koranda wrote:
Thinking pragmatically here.. how about we at least make a structure
for these overrides that matches metadata structure so the config
makes some amount of sense...
The reason I'm worried about this is that this is one place where
SSP started to fall apart: by having an internal representation of
metadata it was "php-easy" to manage metadata but in the end the
dual representation broke the platform.
Cheers Leif
I guess ...
but where does that end? Do we support overriding endpoints?
I understand the concern and agree that it bears watching.
My vision/hope for SATOSA is that it is a pragmatic tool for research
VOs to deploy a proxy and make international federation work. It should
not do everything and be any more complex than it has to be, but at the
same time it will be helpful to the VOs I work with if it can help
"paper over" the realities of international federation today.
Thanks,
Scott K
9:44 p.m.
Thinking pragmatically here.. how about we at least
make a structure
for these overrides that matches metadata structure so the config
makes some amount of sense...
The reason I'm worried about this is that this is one place where
SSP started to fall apart: by having an internal representation of
metadata it was "php-easy" to manage metadata but in the end the
dual representation broke the platform.
Understood.
I am traveling at the moment so let me put some thought into that and
come back with another proposal for the configuration "format".
Of course I would be very grateful to hear suggestions from others...
Cheers,
Scott K
2588
days inactive
2589
days old
8 comments
2 participants
participants (2)
-
leifj＠sunet.se -
skoranda＠gmail.com