1:09 p.m.
Hej,
I'm looking at an application (eduMEET, a custom frontend for
mediasoup, AFAICT) that comes with OIDC support but needs to be made
available to our SAML federation members, of course.
satosa seems to be a common choice for this (though I wouldn't be
unhappy if I could avoid protocol translation, e.g. by proxying from
httpd+mod_shib).
I'm going with the current (6.1.0) satosa release from the cheeseshop.
Ignoring my failed attempts to deploy this in uwsgi for now, I start
the application and everything seems to be going well (using
Gunicorn plus HTTP proxying and TLS-offloading):
* I've configured the SAML backend including a remote metadata url and
cert and the logs indicate the metadata is being consumed.
* I've "configured" (guessed at a few things) but not yet used the OIDC
frontend.
* No microservices as of yet.
[2020-03-26 11:43:13 +0000] [7135] [INFO] Starting gunicorn 20.0.4
[2020-03-26 11:43:13 +0000] [7135] [INFO] Listening at: http://127.0.0.1:8080 (7135)
[2020-03-26 11:43:13 +0000] [7135] [INFO] Using worker: sync
[2020-03-26 11:43:13 +0000] [7138] [INFO] Booting worker with pid: 7138
[2020-03-26 11:43:13,860] [INFO] [satosa.base.__init__] Loading backend modules...
[2020-03-26 11:43:13,936] [DEBUG] [saml2.httpbase.send] GET to
https://eduid.at/md/aconet-registered.xml
[2020-03-26 11:43:14,003] [DEBUG] [saml2.httpbase.send] Response status: 200
[2020-03-26 11:43:14,003] [DEBUG] [saml2.httpbase.set_cookie] eduid.at: 'Set-Cookie:
...'
[2020-03-26 11:43:14,606] [DEBUG] [saml2.sigver._run_xmlsec] xmlsec command:
/usr/bin/xmlsec1 --verify --enabled-reference-uris empty,same-doc --pubkey-cert-pem
aconet-metadata-signing.crt --id-attr:ID
urn:oasis:names:tc:SAML:2.0:metadata:EntitiesDescriptor --output /tmp/tmp9gt_vrc6.xml
/tmp/tmpmhnh96n3.xml
[2020-03-26 11:43:14,681] [INFO] [satosa.plugin_loader.load_backends] Setup backends:
['saml']
[2020-03-26 11:43:14,681] [INFO] [satosa.base.__init__] Loading frontend modules...
[2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_frontends] Setup frontends:
['oidc']
[2020-03-26 11:43:14,804] [INFO] [satosa.base.__init__] Loading micro services...
[2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_request_microservices] Loaded
request micro services: []
[2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_response_microservices] Loaded
response micro services:[]
[2020-03-26 11:43:14,805] [DEBUG] [satosa.routing.__init__] Loaded backends with
endpoints: [<satosa.backends.saml2.SAMLBackend object at 0x7f45e59ad0b8>]
[2020-03-26 11:43:14,805] [DEBUG] [satosa.routing.__init__] Loaded frontends with
endpoints: [<satosa.frontends.openid_connect.OpenIDConnectFrontend object at
0x7f45e54d3b70>]
[2020-03-26 11:43:14,806] [DEBUG] [satosa.routing.__init__] Loaded micro services with
endpoints: []
So far so good.
I've also used `satosa-saml-metadata` to generate backend.xml. That
contained a copy of the provided SAML SP certificate, though with a
use="signing" restriction. (I.e., the metadata generated that way
would fail with any default Shibboleth IDP. Unless pysaml2 doesn't
support encrypted assertions or reponses I consider this a bug. At
least neither the satosa nor the pysaml2 docs had anything on this.)
So I've removed that 'use' restriction to cause the IDP to send
encrypted assertions but later also /disabled/ that in the IDP again:
I get the same exception either way, so this may not in fact be
related.
With no idea how to test the SAML side of things (I know nothing about
OIDC and so left the OP setup and RP integration for later) I sent the
SP an unsolilcited response from my IDP. ('allow_unsolicited: True' is
set in the SAML backend config) which ultimately fails with an
"Unknown error". Stdout from Gunicorn below:
[2020-03-26 11:43:41,080] [DEBUG] [satosa.proxy_server.unpack_post] unpack_post::
{'SAMLResponse': ...
[2020-03-26 11:43:41,081] [DEBUG] [satosa.proxy_server.unpack_request] read request data:
{'SAMLResponse': ...
[2020-03-26 11:43:41,081] [INFO] [satosa.base._load_state]
[urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Loaded state {'SESSION_ID':
'urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59'} from cookie
[2020-03-26 11:43:41,081] [DEBUG] [satosa.routing.endpoint_routing]
[urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Routing path: saml/acs/post
[2020-03-26 11:43:41,082] [DEBUG] [satosa.routing._find_registered_endpoint_for_module]
[urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Found registered endpoint: module
name:'saml', endpoint: saml/acs/post
[2020-03-26 11:43:41,083] [DEBUG] [saml2.response._loads] xmlstr: ...
[2020-03-26 11:43:41,086] [DEBUG] [saml2.sigver._check_signature] ==== Certs from metadata
==== https://idp.example.edu/saml: [<tempfile._TemporaryFileWrapper object at
0x7f45e67d67b8>, <tempfile._TemporaryFileWrapper object at 0x7f45e67d67f0>] ====
[2020-03-26 11:43:41,086] [DEBUG] [saml2.sigver._run_xmlsec] xmlsec command:
/usr/bin/xmlsec1 --verify --enabled-reference-uris empty,same-doc --pubkey-cert-pem
/tmp/tmpqaj6buom.pem --id-attr:ID urn:oasis:names:tc:SAML:2.0:protocol:Response --node-id
_b2ea47f03f30638517a9649f8baf4e1f --output /tmp/tmphc_hm0cw.xml /tmp/tmp8mavdoev.xml
[2020-03-26 11:43:41,098] [DEBUG] [saml2.response._postamble] response: ...
[2020-03-26 11:43:41,103] [DEBUG] [saml2.entity._parse_response] XMLSTR: b'...'
[2020-03-26 11:43:41,103] [INFO] [saml2.response.status_ok] status: <ns0:Status
xmlns:ns0="urn:oasis:names:tc:SAML:2.0:protocol"><ns0:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></ns0:Status>
[2020-03-26 11:43:41,104] [DEBUG] [saml2.response.parse_assertion] ***Encrypted
assertion/-s***
[2020-03-26 11:43:41,105] [DEBUG] [saml2.response.parse_assertion] --- AVA: {}
[2020-03-26 11:43:41,105] [ERROR] [satosa.base.run]
[urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Uncaught exception
Traceback (most recent call last):
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
289, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
229, in _run_bound_endpoint
return spec(context)
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/backends/saml2.py",
line 341, in authn_response
if context.state[self.name]["relay_state"] !=
context.request["RelayState"]:
File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py", line
1025, in __getitem__
raise KeyError(key)
KeyError: 'saml'
[2020-03-26 11:43:41,106] [ERROR] [satosa.proxy_server.__call__] Unknown error
Traceback (most recent call last):
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
289, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
229, in _run_bound_endpoint
return spec(context)
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/backends/saml2.py",
line 341, in authn_response
if context.state[self.name]["relay_state"] !=
context.request["RelayState"]:
File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py", line
1025, in __getitem__
raise KeyError(key)
KeyError: 'saml'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/proxy_server.py",
line 117, in __call__
resp = self.run(context)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
307, in run
raise SATOSAUnknownError("Unknown error") from err
satosa.exception.SATOSAUnknownError: Unknown error
Now, the KeyError comes from the 'name' of my SAML backend plugin config:
module: satosa.backends.saml2.SAMLBackend
name: saml
So when context.state[self.name] doesn't exist (or doesn't have a
"relay_state" key itself) in authn_response() from
satosa/backends/saml2.py I guess something about the relaystate of
COOKIE_STATE_NAME or my deployment could be off?
Here's that part from my proxy_conf.yaml (I haven't checked the code
yet what the defaults are, the documentation doesn't mention any):
BASE: https://test.example.edu
COOKIE_STATE_NAME: satosa_state
# Also tried with delete set to False
CONTEXT_STATE_DELETE: True
STATE_ENCRYPTION_KEY: somestring
cookies_samesite_compat:
- [satosa_state, "SATOSA_STATE_LEGACY"]
Another data point: When trying to start SAML SSO by accessing the
discovery_response endpoint at <base>/<name>/disco I end up with the
exception raised in disco_response() from satosa/backends/saml2.py
("No IDP chosen for state" / "No IDP chosen")
Any pointers?
Should I post (even) more config snippets?
Logs from the other exception too, when accessing the disco endpoint?
Cheers,
-peter
1:47 p.m.
Hi Peter,
I'll try to share my poor knowledge on some of the things you wrote, other
users with more experience than mine would be do better. No way otherwise
for my english ... :)
Il giorno gio 26 mar 2020 alle ore 14:16 Peter Schober <
peter.schober at univie.ac.at> ha scritto:
I've also used `satosa-saml-metadata` to generate
backend.xml.
I stopped using the metadata generator, I forge it on the fly with this
parameter:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
and this parameter:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
same approach for backends and frontends.
That contained a copy of the provided SAML SP certificate, though with a
use="signing" restriction. (I.e., the
metadata generated that way
would fail with any default Shibboleth IDP. Unless pysaml2 doesn't
support encrypted assertions or reponses I consider this a bug. At
least neither the satosa nor the pysaml2 docs had anything on this.)
Put it to false:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
Yes shibboleth creates a lot of "conventions" and as I can see many
security restrinctions goes down in its ideal world ... But not the
encryption, pySAML2 (xmlsec1) works fine with shibidp encrypted assertions,
the problem is that a Shibboleth SP doesn't do the same with encrypted
assertion from a pysaml2 IdP.
So I've removed that 'use' restriction
to cause the IDP to send
encrypted assertions but later also /disabled/ that in the IDP again:
I get the same exception either way, so this may not in fact be
related.
To avoid encryption of assertions from a ShibIdP side, if I remember well,
just remove your encryption keys, here:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
then renew sp metadata to shibidp. But I can tell you that pySAML2
(xmlsec1) works fine with shibboleth encryption (but not the inverse!).
With no idea how to test the SAML side of things (I
know nothing about
OIDC and so left the OP setup and RP integration for later) I sent the
SP an unsolilcited response from my IDP. ('allow_unsolicited: True' is
set in the SAML backend config) which ultimately fails with an
"Unknown error".
Yes in a production environment where satosa runs in multiple workers each
with a private memory we have this bane...
I'd need also to try to setup a mongodb to enable some shared sessions
between my workers, but this is another topic.
if context.state[self.name]["relay_state"] !=
context.request["RelayState"]:
File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py",
line 1025, in __getitem__
raise KeyError(key)
KeyError: 'saml'
It seems that something went missing in the session.
BASE: https://test.example.edu
COOKIE_STATE_NAME: satosa_state
# Also tried with delete set to False
CONTEXT_STATE_DELETE: True
STATE_ENCRYPTION_KEY: somestring
cookies_samesite_compat:
- [satosa_state, "SATOSA_STATE_LEGACY"]
Probably I'm wrong, try this:
cookies_samesite_compat:
- ["SATOSA_STATE", "SATOSA_STATE_LEGACY"]
Another data point: When trying to start SAML SSO by
accessing the
discovery_response endpoint at <base>/<name>/disco I end up with the
exception raised in disco_response() from satosa/backends/saml2.py
("No IDP chosen for state" / "No IDP chosen")
Probably this resources takes mandatory entityid arguments
Any pointers?
Should I post (even) more config snippets?
Logs from the other exception too, when accessing the disco endpoint?
Without Python Debugger (import pdb; pdb.set_trace()) I wouldn't have been
in production.
Take some more day to find your configuration and asset, it's normal.
let us know
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
2:14 p.m.
Dottore,
Thanks for your response (and no apologies needed about not being a
native speaker of the English language).
* Giuseppe De Marco <giuseppe.demarco at unical.it> [2020-03-26 14:47]:
Disabling signed auth requests is the first thing I did (an
unfortunate default of pysaml2) but that setting has nothing to do
with the SP not supporting encrytpted responses or assertions, AFAIU.
Indeed, my mistake. See my other post for more exceptions once I
included that.
Cheers,
-peter
I stopped using the metadata generator, I forge it on
the fly with this parameter:
It was fine. And I know I can configure the SP to publish it's own metadata
at the entityID value (if one choses a URL) but that has the same
deficiency with the use="signing" restriction on the published key.
But that was a tangent and doesn't affect the (not) working of my
deployment.
That contained
a copy of the provided SAML SP certificate, though
with a use="signing" restriction. (I.e., the metadata generated
that way would fail with any default Shibboleth IDP. Unless
pysaml2 doesn't support encrypted assertions or reponses I
consider this a bug. At least neither the satosa nor the pysaml2
docs had anything on this.)
Put it to false:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
Yes shibboleth creates a lot of
"conventions" and as I can see many
security restrinctions goes down in its ideal world ... But not the
encryption, pySAML2 (xmlsec1) works fine with shibidp encrypted
assertions, the problem is that a Shibboleth SP doesn't do the same
with encrypted assertion from a pysaml2 IdP.
Not sure I follow about Shibboleth conventions or how encrypted
assertions my differ by implementation, but it seems satosa can
decrypt everything my Shib IDP sent just fine. So that particular
aside was irrelevant (except for my claim that either form of metadata
generation has a bug by adding the use="signing" restriction).
Sorry for including that particular distraction (I wasn't sure it
mattered, back then).
To avoid encryption of assertions from a ShibIdP side,
if I remember well,
just remove your encryption keys, here:
No, the Shib IDP by default terminates with an error for any SPs that
doesn't have encryption keys. And the default SAML SP metadata
generated by satosa does not have any keys usable for encryption in
them, which is eaxctly why I called that a bug before and above. ;)
just remove your encryption keys, here:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
then renew sp metadata to shibidp. But I can tell you that pySAML2
(xmlsec1) works fine with shibboleth encryption (but not the inverse!).
I haven't seen an 'encryption_keypairs' parameter in the satosa examples:
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/backen…
nor the satosa documentation:
https://github.com/IdentityPython/SATOSA/tree/master/doc#configuration
nor in the pysaml2 docs:
https://github.com/IdentityPython/pysaml2/blob/master/docs/howto/config.rst
but I see it being used satosa/backends/saml2.py.
Anyway, encryption/decryption is not the issue, after all.
Another data
point: When trying to start SAML SSO by accessing the
discovery_response endpoint at <base>/<name>/disco I end up with the
exception raised in disco_response() from satosa/backends/saml2.py
("No IDP chosen for state" / "No IDP chosen")
Probably this resources takes mandatory entityid arguments
3:37 p.m.
Let's see
Il giorno gio 26 mar 2020 alle ore 15:14 Peter Schober <
peter.schober at univie.ac.at> ha scritto:
My fault, just happy to know that pysaml2 decrypt well the assertions from
a ShibIdP
... We should not let our guard down, we are so
close to solving it but ...
Years have passed in the meantime.
> > > Another data point: When trying to start SAML SSO by accessing the
> > > discovery_response endpoint at <base>/<name>/disco I end up
with the
> > > exception raised in disco_response() from satosa/backends/saml2.py
> > > ("No IDP chosen for state" / "No IDP chosen")
> > > Probably this resources takes
mandatory entityid arguments
> Indeed, my mistake. See my other post for
more exceptions once I
> included that.
PySAML2 and Satosa took me a lot of time for debugging, patching, studying
... But once this "tunnel" finishes they works like a charm, wonderfull
performances in production. I use also Shibboleth IdP in a production
environment for IDEM federation, and I have to manage two istances it
behind a HAproxy, because each restart of it (when a reload of a service
could not be done) could take 14 seconds of downtime.
PySAML2 is a wondeerful toy, in general it's just fun!
We should let newcomers to be able to appreciate it ... And comparisons
with shibboleth are necessary to continue growing, and here I am, out of
topic!
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
Thanks for your response (and no apologies needed
about not being a
native speaker of the English language).
Probably even with italian ...
Disabling signed auth requests is the first thing I
did (an
unfortunate default of pysaml2) but that setting has nothing to do
with the SP not supporting encrytpted responses or assertions, AFAIU.
Disable encryption
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
Not sure I follow about Shibboleth conventions
First time I saw that ShibIdP don't require any signature by default on the
authnRequest I though <<Ok, it's the accessibility/security trade-off
!>>.
Then I found a lot of security restrictions in pysaml2 for the certificates
validity and moreover that guided me to read the Shibboleth IdP sources ...
:)
or how encrypted assertions my differ by
implementation, but it seems
satosa can
decrypt everything my Shib IDP sent just fine. So that particular
aside was irrelevant (except for my claim that either form of metadata
generation has a bug by adding the use="signing" restriction).
Sorry for including that particular distraction (I wasn't sure it
mattered, back then).
I hope this problem about encryption will be patched soon, it's something
mess in the arguments used in xmlsec1 to produce the encryption or
something linked to xmlsec. I should have been more time to debug to
purpose a patch, but too many things in the last months ... I'm thinking
about this lack just as a temporary bug.
To avoid
encryption of assertions from a ShibIdP side, if I remember
well,
just remove your encryption keys, here:
No, the Shib IDP by default terminates with an error for any SPs that
doesn't have encryption keys. And the default SAML SP metadata
generated by satosa does not have any keys usable for encryption in
them, which is eaxctly why I called that a bug before and above. ;)
I haven't seen an 'encryption_keypairs'
parameter in the satosa examples:
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/backen…
nor the satosa documentation:
https://github.com/IdentityPython/SATOSA/tree/master/doc#configuration
nor in the pysaml2 docs:
https://github.com/IdentityPython/pysaml2/blob/master/docs/howto/config.rst
but I see it being used satosa/backends/saml2.py.
I thought the same thing ... Found it with pdb, my friend.
https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/backends/sa…
Anyway, encryption/decryption is not the issue, after all.
3:53 p.m.
* Giuseppe De Marco <giuseppe.demarco at unical.it> [2020-03-26 16:38]:
Note that I was talking about the SAML backend (SP) and the above is
about the frontend (IDP). Thanks for the pointer anyway.
The only reason to sign authn requests is if they contain something
extra the SP doesn't want to be removed (in transit) and replaced with
an authn request without it, maybe forceAuthn or authn context class
refs or something like that.
For ordinary authn requests the IDP must already validate the
requested ACS URL (from the SAML spec), which of course is done using
metadata obtailed securely out of band.
So in the common case signing an authn request does not provide any
added security but it does expose the SP to trivial DoS attacks.
(A note to those who thing "signing" makes everything more secure,
forgetting about the availability aspect of IT security.)
Disabling
signed auth requests is the first thing I did (an
unfortunate default of pysaml2) but that setting has nothing to do
with the SP not supporting encrytpted responses or assertions, AFAIU.
Disable encryption
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
Not sure I
follow about Shibboleth conventions
First time I saw that ShibIdP don't require any signature by default on the
authnRequest I though <<Ok, it's the accessibility/security trade-off
!>>. I thought the same thing ... Found it with pdb, my
friend.
Seems I have a lot to learn, when really I should be learning about
the application I need to integrate...
PySAML2 is a wondeerful toy, in general it's just
fun!
We should let newcomers to be able to appreciate it ... And
comparisons with shibboleth are necessary to continue growing, and
here I am, out of topic!
:)
Thanks for sharing.
-peter
4 p.m.
Il giorno gio 26 mar 2020 alle ore 16:53 Peter Schober <
peter.schober at univie.ac.at> ha scritto:
the
Good to know!
I never thought that a signature could be too much computational intensive
but, it could be so.
Not sure I follow about Shibboleth conventions
First time I saw that ShibIdP don't require any signature by default on authnRequest I though <<Ok, it's the
accessibility/security trade-off
!>>.
The only reason to sign authn requests is if they contain something
extra the SP doesn't want to be removed (in transit) and replaced with
an authn request without it, maybe forceAuthn or authn context class
refs or something like that.
For ordinary authn requests the IDP must already validate the
requested ACS URL (from the SAML spec), which of course is done using
metadata obtailed securely out of band.
So in the common case signing an authn request does not provide any
added security but it does expose the SP to trivial DoS attacks.
(A note to those who thing "signing" makes everything more secure,
forgetting about the availability aspect of IT security.)
Seems I have a lot to learn, when really I should be
learning about
the application I need to integrate...
Curiosity works like an engine
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
4:37 p.m.
* Giuseppe De Marco <giuseppe.demarco at unical.it> [2020-03-26 17:00]:
I never thought that a signature could be too much
computational
intensive but, it could be so.
Not a single one, but thousands of "cheap" GET requests to a
protected resource, as easily generated by a single unauthenicated
client on the network, resulting in "expensive" signing operations.
It's this asymmetry in the attacker's favor you'd want to avoid.
-peter
5:09 p.m.
Il giorno gio 26 mar 2020 alle ore 17:37 Peter Schober <
peter.schober at univie.ac.at> ha scritto:
* Giuseppe De Marco <giuseppe.demarco at
unical.it> [2020-03-26 17:00]:
that's interesting Peter,
Probably that kind of abuse should be handled in a SIEM or a next-gen
firewall, or locally on the same server with those ip2ban or better a httpd
firewall, or an anti brute force applicative prevention (many on django, my
favourite framework).
I think that this aspect would be better handled in the domain of the
global security treatment of an IT infrastructure.
My point of view, simply, is the following:
the signature prevents that a fake entity could access to the credential
prompt, this latter is the way to do bruteforce attacks.
Probably a sane LDAP Enterprise deployment have a password policy with a
temporary lockout or whatever, but bruteforce happened. The MFA help in
that, but is a second step once the credentials have been stolen.
I always seen the signature as a good tool for preventing bruteforce
attacks, if some performance goes down the IdP should just scaled up soon
as possible and a good SIEM/httpd_firewall will do the rest helping us
seeing the bads and the uglies.
personal point of view, still in search of the truth ...
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
I never thought that a signature could be too
much computational
intensive but, it could be so.
Not a single one, but thousands of "cheap" GET requests to a
protected resource, as easily generated by a single unauthenicated
client on the network, resulting in "expensive" signing operations.
It's this asymmetry in the attacker's favor you'd want to avoid.
5: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
8:43 p.m.
Il giorno gio 26 mar 2020 alle ore 16:37 Giuseppe De Marco <
giuseppe.demarco at unical.it> ha scritto:
I hope this problem about encryption will be patched soon, it's something
mess in the arguments used in xmlsec1 to produce the encryption or
something linked to xmlsec. I should have been more time to debug to
purpose a patch, but too many things in the last months ... I'm thinking
about this lack just as a temporary bug.
That's the patch we're waiting for
https://github.com/IdentityPython/pysaml2/pull/662#issuecomment-595491256
Still need some test with ShibSP, personally I didn't yet.
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
1:47 p.m.
* Peter Schober <peter.schober at univie.ac.at> [2020-03-26 14:16]:
Another data point: When trying to start SAML SSO by
accessing the
discovery_response endpoint at <base>/<name>/disco I end up with the
exception raised in disco_response() from satosa/backends/saml2.py
("No IDP chosen for state" / "No IDP chosen")
FWIW, adding an IDP's entityID to the disco URL gets me further:
<base>/<name>/disco?entityID=some-idp-entityID
lets me see sent attributes and mapped attributes, e.g.
[2020-03-26 13:36:35,559] [DEBUG] [satosa.attribute_mapping.to_internal] backend attribute
['displayName'] mapped to displayname
[2020-03-26 13:36:35,559] [DEBUG] [satosa.attribute_mapping.to_internal] backend attribute
['mail'] mapped to mail
Though I still end up with an "Unkown error" from a yet another KeyError:
[2020-03-26 13:36:35,559] [ERROR] [satosa.base.run]
[urn:uuid:331aa86e-7f18-4a6f-81b2-f51f21d68c86] Uncaught exception
Traceback (most recent call last):
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
289, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
229, in _run_bound_endpoint
return spec(context)
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/backends/saml2.py",
line 353, in authn_response
return self.auth_callback_func(context, self._translate_response(authn_response,
context.state))
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
186, in _auth_resp_callback_func
internal_response.requester = context.state[STATE_KEY]["requester"]
File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py", line
1025, in __getitem__
raise KeyError(key)
KeyError: 'SATOSA_BASE'
[2020-03-26 13:36:35,561] [ERROR] [satosa.proxy_server.__call__] Unknown error
Traceback (most recent call last):
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
289, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
229, in _run_bound_endpoint
return spec(context)
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/backends/saml2.py",
line 353, in authn_response
return self.auth_callback_func(context, self._translate_response(authn_response,
context.state))
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
186, in _auth_resp_callback_func
internal_response.requester = context.state[STATE_KEY]["requester"]
File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py", line
1025, in __getitem__
raise KeyError(key)
KeyError: 'SATOSA_BASE'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/proxy_server.py",
line 117, in __call__
resp = self.run(context)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line
307, in run
raise SATOSAUnknownError("Unknown error") from err
satosa.exception.SATOSAUnknownError: Unknown error
I'm guessing this key value comes from satosa/base.py's
STATE_KEY="SATOSA_BASE"? Doesn't get me much closer, though.
At least the exception happening in _auth_resp_callback_func() is a
good sign, as this has this docstring to offer:
"This function is called by a backend module when the authorization is
complete."
So dispite all the tracebacks and exceptions I must be getting close. ;)
-peter
4:35 p.m.
* Peter Schober <peter.schober at univie.ac.at> [2020-03-26 14:16]:
Ignoring my failed attempts to deploy this in uwsgi
for now
FWIW, got satosa runing under uwsgi (plus proxying from httpd), so
gunicorn vs. uwsgi is not an issue after all.
I'll be trying to get the to-be-protected application to start an OIDC
flow next, maybe that'll show whether my satosa deployment is actually
broken or whether my testing methods were simply insufficient...
-peter
10:32 p.m.
Il giorno ven 27 mar 2020 alle ore 17:35 Peter Schober <
peter.schober at univie.ac.at> ha scritto:
* Peter Schober <peter.schober at univie.ac.at>
[2020-03-26 14:16]:
Hi Peter,
That's an example about running satosa with uwsgi, you'll find other notes
about nginx
https://github.com/peppelinux/Satosa-saml2saml/tree/master/example/uwsgi_se…
I use uwsgi.ini.debug when I need to get in debugging mode
Ignoring my failed attempts to deploy this in
uwsgi for now
FWIW, got satosa runing under uwsgi (plus proxying from httpd), so
gunicorn vs. uwsgi is not an issue after all.
I'll be trying to get the to-be-protected
application to start an OIDC
flow next, maybe that'll show whether my satosa deployment is actually
broken or whether my testing methods were simply insufficient...
never give up
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
11:31 a.m.
* Peter Schober <peter.schober at univie.ac.at> [2020-03-27 17:35]:
* Peter Schober <peter.schober at univie.ac.at>
[2020-03-26 14:16]:
To close off this thread: As mentioned in another post
https://lists.sunet.se/pipermail/satosa-users/2020-March/000120.html
I'm now pretty sure my SAML backend has been working fine all this
time despite the exceptions I asked about.
The problem seems to have been with my testing method(s), i.e., by
sending the SAML SP an unsolicited response (even if the backend has
allow_unsolicited: True, whatever that's supposed to achieve, then, if
satosa falls over dead when it does recieve one) or starting
SP-initated SSO using the DiscoveryResponse URL (at
/<name>/disco?entityID=someidp) both ended in exceptions, as reported
here earlier.
But involving the frontend (which I'm not further along setting up)
shows the SAML part is fine, after all.
I'll continue my public soliloquy in other threads.
-peter
Ignoring my failed attempts to deploy this in
uwsgi for now
FWIW, got satosa runing under uwsgi (plus proxying from httpd), so
gunicorn vs. uwsgi is not an issue after all.
I'll be trying to get the to-be-protected application to start an OIDC
flow next, maybe that'll show whether my satosa deployment is actually
broken or whether my testing methods were simply insufficient...
1509
days inactive
1514
days old
13 comments
2 participants
participants (2)
-
giuseppe.demarco＠unical.it -
peter.schober＠univie.ac.at