On Thu, 7 Jun 2018 at 11:54, Rainer Hoerbe <rainer at hoerbe.at> wrote:
I guess that either the frontend or the backend implement some deployment profile, or
both. Within this profile I expect the set of algorithms to be identical for AuthNrequest,
Response, SLO, etc; probably for metadata as well. However, frontend and backend could
belong to different policy domains. While a SOATOSA-wide „global“ option might work in
many cases, it should be possible to override it per plugin. But not deeper to avoid
unnecessary complexity on the configuration side.
That is right and we agree. When I say "global" I mean it is global in
the service context (where service is an idp, or sp, etc).
To make this clearer, I am thinking in the context of pysaml2, not
SATOSA. With this in mind, an IdP uses pysaml2 to implement support
for SAML2, and in pysaml2's configuration 'sign_alg' is used
"globally" wherever signing is needed. Another app, this time an SP,
can use pysaml2 to support SAML2 - the same rules apply. When one is
thinking about SATOSA, one might mix frontend/IdP and backend/SP
configurations, but those are very different entities - and their
configurations are separate (separate backend and frontend configs) -
so the same reasoning applies. I can extend this further by mentioning
that (a) there can be multiple frontends and backends and (b) it
should be possible to swap out frontend/IdP and backend/SP
implementations to ones not based on pysaml2 (this is a project goal
that defines a framework to think inside). I cannot imagine how a
"global-for-all-plugins" could even work.
So, global is in contrast to an option for every specific operation:
- sign_alg option is global - it applies to authnrequest, logout, etc
- authn_sign_alg is not global, it applies only to authnrequest
I do not want a "global" configuration for every signing operation
under SATOSA,
but the configuration can apply "globally" for the service it
configures (per IdP/frontend, SP/backend, etc).
The way things stand now, is that we have separate configurations for
frontends and backends - this is good and how it is supposed to be,
and how it will continue to be.
Where things go wrong is that configuration options set in the pysaml2
config are handled by SATOSA. Other apps using pysaml2, when defining
those configuration settings see no change in pysaml's behaviour, as
if the settings where never set - this is bad.
I hope this is clear - thanks
--
Ivan c00kiemon5ter Kanakarakis >:3