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
Hello SaToSa list!
We are experiencing unexpected poor performance with SaToSa. (1K requests/minute) . We are seeing very high resource use with XMLSEC binary (default option) and using pyXMLSecurity (crypto_backend configuration) with encryption disabled.
Here is our setup:
Load Balancer=>EC2=>NGINX=>Gunicorn. (NGINX=>Gunicorn is on the UDS, not network stack)
EC2 instance size information: (OS is AWS linux)
Model vCPU Memory (GiB) Instance Storage (GiB) Network Bandwidth (Gbps)
EBS Bandwidth (Mbps)
c5n.2xlarge 8 21 EBS-Only Up to 25 Up to 4,750
Gunicorn is set to the "thread" model:
import multiprocessing
workers = multiprocessing.cpu_count() * 2 + 1
threads = multiprocessing.cpu_count() * 2 + 1
We have 8 core boxes.
Any suggestion on things we may try ?
TIA
-Jonathan
Dear users of IdentityPython,
this is a heads-up about two vulnerabilities affecting pySAML2.
Software that uses pySAML2 is indirectly affected, too (ie, SATOSA).
The issues were reported to the IdentityPython incident-response
mailing list and we have been working on a mitigation. A new version
of pySAML2 that includes the fixes will be released on Wednesday
20th of January between 13:00 CET and 17:00 CET. We urge
everyone to be prepared to update their setup to the latest version.
Kind regards,
Ivan Kanakarakis on behalf of the incident-response team
satosa-users at lists.sunet.se
Hi all,
we're trying to set up a proxy SAML-SAML between our service provider
(keycloak) and an IdP federation, following this guide
<https://github.com/IdentityPython/SATOSA/blob/master/doc/one-to-many.md> (and
a variant <https://github.com/daserzw/satosa-oidc-to-saml>).
It looks like the backend side is unreachable or, at least, the metadata
are: if we HTTP GET <base_url>/<name>/proxy_saml2_backend.xml (as specified
in the backend yaml config file) the server replies:
404 The Service or Identity Provider you requested could not be found.
Whereas if we try to HTTP GET the frontend, we can retrieve the
corresponding xml.
Any ideas why this is happening and how to fix it, or how to further
investigate it?
Thanks for your support.
Cristiano
--
Cristiano Nattero, PhD
FadeOut Software srl
http://fadeout.it/
--
Privacy - Reg. UE 679/2016 (GDPR) - Questo messaggio, ed ogni eventuale
allegato, è riservato e confidenziale e indirizzato esclusivamente ai
destinatari indicati. La segretezza della corrispondenza elettronica è
tutelata dalle leggi in vigore, pertanto l’intercettazione, la lettura o la
riproduzione di questo messaggio da parte di persone a cui non è destinato,
è espressamente vietata.
Privacy - Reg. UE 679/2016 (GDPR) - This
message, with any attachments, is intended only for use of the individual
or entity to which it is addressed and contains confidential information
that may also be privileged. Secrecy of electronic mail is protected by law
in force. If you are not the intended recipient of this message, you are
hereby notified that interception, distribution or copying of this
communication is strictly prohibited.
Dear. satosa-developers
Recently, I studying OpenID Connect and SAML using Satosa (oidc-to-saml)
I have a question.
I'd like to know 1. satosa-oidc-to-saml flow that includes micro_service
2. when the micro_services works when I set up
the micro service.
3. Can I add new attributes to OIDC Provider
without hard coding and mapping them between oidc and saml attributes?
(oidc-to-saml)
Could you tell me the answer to the above and about Satosa?
Hello
I'm having a strange error with my Satosa (oidc-to-saml) frontend
[satosa.frontends.openid_connect]: invalid client authentication at token
endpoint
Traceback (most recent call last):
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/openid_connect.py",
line 362, in token_endpoint
response =
self.provider.handle_token_request(urlencode(context.request), headers)
File "/usr/local/lib/python3.6/site-packages/pyop/provider.py", line
319, in handle_token_request
token_request = self._verify_client_authentication(request_body,
http_headers)
File "/usr/local/lib/python3.6/site-packages/pyop/provider.py", line
425, in _verify_client_authentication
token_request['client_id'] =
verify_client_authentication(self.clients, token_request,
http_headers.get('Authorization'))
File
"/usr/local/lib/python3.6/site-packages/pyop/client_authentication.py",
line 57, in verify_client_authentication
raise InvalidClientAuthentication(client_secret)
pyop.exceptions.InvalidClientAuthentication: None
The above error repeats over and over again. I'm not sure if it's problem
with client_id registration, tokenEndpoint, or Satosa internal settings.
Could you tell me how to solve this problem?
Hello,
(Apologies, cross posting from Slack)
I’m having a strange error with my Satosa frontend that seems to be
stripping out attributes incorrectly from the SAML response before it is
sent, based on required attributes from SP metadata.
It receives the correct values from an upstream IdP:
returning attributes {"eduPersonUniqueId": ["... at cern.ch"], "displayName":
["Hannah Short"], "givenName": ["Hannah"], "mail": ["hannah.short at cern.ch"],
"cn": ["Hannah Short"], "sn": ["Short"], "eduPersonScopedAffiliation": ["
member at cern.ch"], "eduPersonAffiliation": ["member"],
"eduPersonPrincipalName": ["hshort at cern.ch"], "eduPersonAssurance": ["
https://refeds.org/assurance/ID/unique", "
https://refeds.org/assurance/ATP/ePA-1m", "
https://refeds.org/assurance/IAP/low"], "schacHomeOrganization": ["cern.ch"],
"schacHomeOrganizationType": ["urn:schac:homeOrganizationType:ch:others"],
"swissEduPersonHomeOrganization": ["cern.ch"],
"swissEduPersonHomeOrganizationType": ["others"], "swissEduPersonUniqueID":
["... at cern.ch"], "eduPersonTargetedID": ["..."]}
However, it then checks the “required” attributes from the target SP and
decides to strip out the swiss* ones (despite them being required in the
SP’s metadata and I can also see that they are required in the debug
statement).
My swiss* attributes are defined in an attribute map, and I’m running
satosa 6.0.0.
I’m really stuck here, I just rolled out this IdP and will have to roll
back if I can’t fix this quickly :( Can I ignore “required” attributes as a
workaround? When none are required the token gets sent as expected
Thanks in advance for any help,
Hannah
Hi
I´m trying to setup SAMLVirtualCoFrontend with three entityIDs, but got a problem that I hope someone knows about.
It seems as all three entityIDs are get up by SATOSA as I can see this in the log:
Created URL regex (^Saml2)/(Org1|Org2|Org3)/sso/post
Adding mapping ('(^Saml2)/(Org1|Org2|Org3)/sso/post'
Created URL regex (^Saml2)/(Org1|Org2|Org3)/sso/redirect
Adding mapping ('(^Saml2)/(Org1|Org2|Org3)/sso/redirect'
But the metadata frontend.xml only contains entityID for the last entry, in this case "Org3".
The log shows that metadata is written three times to the same file, see log entry below.
Writing metadata to '/cfg/metadata/frontend.xml'
Writing metadata to '/cfg/metadata/frontend.xml'
Writing metadata to '/cfg/metadata/frontend.xml'
Writing metadata to '/cfg/metadata/backend.xml'
Is there anything I can do to get correct frontend metadata for all three COs ?
A configuration item to get separate filenames or something?
I´m using latest Docker image satosa/satosa as of yesterday
/Ulrik Å
Hello SatoSa list!
This is my first post as I am just getting started with SatoSa. Thanks to all for making it possible. I love it so far, the code and semantics are very clean!
Question: It seems that I can configure SAMLFrontend and SAMLVirtualCoFrontend to both operate correctly in my topology ( 1 or many SP => 1 IdP. OR 1 SP=> many IdP ) as such I am uncertain of which module would be best to use.
Can someone in the community tell me why I would want to use one module over the other? I think I must be missing some functional capabilities afforded by one but not the other.
TIA
-Jonathan
+++
Hi,
I'm having few issues and hopefully you might provide some light
saml to saml scenario.
I wanted to add custom attribute:
I added that attribute to saml_uri.py
'fro': { 'urn:mace:heanet.ie:custom:tenantid': 'customtenantid', ... },
'to': { 'customtenantid': 'urn:mace:heanet.ie:custom:tenantid', ... }
then internal_attributes.yaml :
added:
customtenantid:
saml: [customtenantid, urn:mace:heanet.ie:custom:tenantid]
in saml2_frontend.yaml policy is set to allow release everything:
policy:
default:
attribute_restrictions: null
however: logs say:
///////////////
xx | [2020-07-20 20:59:47,604] [DEBUG] [satosa.frontends.saml2._get_approved_attributes] [urn:uuid:244a93be-a61e-4e5f-8508-c293a24f832d] Filter: ['name', 'schacHomeOrganization', 'edupersontargetedid', 'givenname', 'eppn', 'organizationName', 'mail', 'displayname', 'surname']
//////////////
where does that filter come from if I have set not restriction .
Is it only way to add a custom atribute ?
thanks in advance,
Janusz
