6:56 p.m.
While we're well and truely off-topic here: I'm happy to receive any
pointers about my actual satosa-related question. :)
* Giuseppe De Marco <giuseppe.demarco at unical.it> [2020-03-26 18:10]:
the signature prevents that a fake entity could access
to the
credential prompt, this latter is the way to do bruteforce attacks.
What prevents the attacker from simply getting another (signed) authn
request from a real SP (or from another SP, any other SP), brute-force
away at the IDP until the context at the IDP expires and then start
over with a new (signed) authn request?
(To answer my own question: Being able to trigger an authn request on
at least one SP the IDP knows. Trivial for widely and publicly
federated entities, not so easy in more "private" federations, I guess.)
Also, it's not the SP's signature per se that would prevent access to
the IDP's login prompt: the IDP would also have to be configured to
reject any unsigned authn request (otherwise I'd simply replace the
signed authn request generated by the SP with an unsigned one of my
own choosing and play that to the IDP).
Additionally the IDP must not support "IDP-initiated" at all,
otherwise I'd similarly replace the SAML authn request to the IDP with
a proprietary authn requests (which very likely doesn't even have
provisions for signed requests).
Whether all of those changes at the IDP are possible depends on the SP
implementations used (can they sign, do they even support sending
authn requests) and how much influence the IDP has over those SP
deployments (can they be changed to send signed authn requests)?
And even then you're still in the unfortunate position of having to
reach 100% of your SPs before the IDP could make such a change.
So all in all very unlikely to happen in most cases, I think.
(Futhermore you now have another asymmetry to deal with: That of the
SPs bearing the costs of the signing -- exposing themselfs to trivial
DoS attacks -- in order for the IDPs to derive potential benefits from
it. Where IDPs and SPs are not all in the same organisation this is
hard to pull off, generally.)
And of course brute-force attacks can continue on other services
(ESMTPA, IMAP, etc.) or systems (webmail, etc.) that have no way of
making signed requests a pre-requisite, but the credentials gained
that way could very likely still be /used/ at the "protected" IDP.
But sure, no single method will be effective, you'll want to have a
chain of defense mechanisms.
Again: Happy to return to my satosa issue/s any time! :)
-peter