2:11 p.m.
Hi folks,
this topic probably needs further investigation. I'll share my findings
and welcome any ideas on how to further debug this. Maybe someone else
has encountered the same problem?
We're using Satosa as the basis for various of our deployments. This
issue occurs in any v7 version of Satosa and is not limited to only the
most recent 7.0.3. The pySAML2 security vulnerability only was the
trigger for me to finally upgrade from 6.1.0 which we have been using
until now. This upgrade also includes raising the pyop dependency from
3.0.1 to 3.1.0 for what it's worth. I removed as much of our custom
config and code as possible, notably switching back to the vanilla OIDC
frontend without any modifications.
Basically, MongoDB entries for subject-identifier are being deleted
whenever another access token is generated (i.e. another user logs in).
This leads to all previous access tokens being unusable for accessing
userinfo etc.:
[Wed Jan 27 13:00:49 2021] [wsgi] [ERROR] [satosa.base]
[/usr/local/lib/python3.6/site-packages/satosa/base.py - line 257]:
[urn:uuid:652c74dc-bab6-46a4-8be8-d83fa215a281] Uncaught exception
...
[Wed Jan 27 13:00:49 2021] [wsgi] File
"/usr/local/lib/python3.6/site-packages/pyop/authz_state.py", line 315,
in get_user_id_for_subject_identifier
[Wed Jan 27 13:00:49 2021] [wsgi] raise InvalidSubjectIdentifier('{}
unknown'.format(subject_identifier))
[Wed Jan 27 13:00:49 2021] [wsgi]
pyop.exceptions.InvalidSubjectIdentifier:
00000000-0000-0000-0000-000000000002 unknown
Consider the following example:
1) Login with Account 1 (sub=00000000-0000-0000-0000-000000000002)
2) Login with Account 2 in another browser
(sub=ddd3a947-b5e1-4f59-a757-eab8231aa687)
With 6.1.0 MongoDB would now look like this:
{
_id: ObjectId('60115fab8486770baffef551'),
lookup_key: 'superadmin',
data: {
'public': '00000000-0000-0000-0000-000000000002'
},
modified_ts: 1611751339.31406
}
{
_id: ObjectId('60115fe08486770baffef5f5'),
lookup_key: 'a at b.de',
data: {
'public': 'ddd3a947-b5e1-4f59-a757-eab8231aa687'
},
modified_ts: 1611751392.2613952
}
With 7.x MongoDB contains *only* the following entry instead:
{
_id: ObjectId('60115fe08486770baffef5f5'),
lookup_key: 'a at b.de',
data: {
'public': 'ddd3a947-b5e1-4f59-a757-eab8231aa687'
},
modified_ts: 1611751392.2613952
}
If that makes any difference, we're only using public sub claims:
fe_id:
openid: [sub]
which are generated from LDAP attributes:
search_return_attributes:
didmosUUID: fe_id
I have not yet tested with pairwise claims.
Any ideas are much appreciated :)
Cheers,
David
--
David Hübner, Solutions Engineer
DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany
phone: +49 7071 407109-0
fax: +49 7071 407109-9
email: david.huebner at daasi.de
web: www.daasi.de
Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz