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
Hi,
I hope you might give some light.
I'm trying to setup saml2saml.
Everything works fine when samlBackend gets metadata with only one IdP.
When there is more then I'm getting error.
backends/saml2_backend.yaml is based saml2_backend.yaml.example
I would be very much appreciated for any help.
############################
jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,978] [DEBUG] [satosa.routing.backend_routing] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] Routing to backend: Saml2
jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,978] [INFO] [satosa.backends.saml2.get_idp_entity_id] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] {'message': 'Selected IdP', 'only_one': False, 'target_entity_id': None, 'force_authn': None, 'memorized_idp': False, 'entity_id': None}
agger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,979] [ERROR] [satosa.base.run] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] Uncaught exception
jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last):
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 240, in run
jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self._run_bound_endpoint(context, spec)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 180, in _run_bound_endpoint
jagger_satosa.1.niwh0x0v4r34 at totoro | return spec(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 100, in handle_authn_request
jagger_satosa.1.niwh0x0v4r34 at totoro | return self._handle_authn_request(context, binding_in, self.idp)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 256, in _handle_authn_request
jagger_satosa.1.niwh0x0v4r34 at totoro | return self.auth_req_callback_func(context, internal_req)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 103, in _auth_req_callback_func
jagger_satosa.1.niwh0x0v4r34 at totoro | return self._auth_req_finish(context, internal_request)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 108, in _auth_req_finish
jagger_satosa.1.niwh0x0v4r34 at totoro | return backend.start_auth(context, internal_request)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 179, in start_auth
jagger_satosa.1.niwh0x0v4r34 at totoro | return self.disco_query(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 211, in disco_query
jagger_satosa.1.niwh0x0v4r34 at totoro | disco_url, self.sp.config.entityid, **args
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/opt/satosa/lib/python3.7/site-packages/saml2/client_base.py", line 936, in create_discovery_service_request
jagger_satosa.1.niwh0x0v4r34 at totoro | if '?' in url:
jagger_satosa.1.niwh0x0v4r34 at totoro | TypeError: argument of type 'NoneType' is not iterable
jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,980] [ERROR] [satosa.proxy_server.__call__] Unknown error
jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last):
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 240, in run
jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self._run_bound_endpoint(context, spec)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 180, in _run_bound_endpoint
jagger_satosa.1.niwh0x0v4r34 at totoro | return spec(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 100, in handle_authn_request
jagger_satosa.1.niwh0x0v4r34 at totoro | return self._handle_authn_request(context, binding_in, self.idp)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 256, in _handle_authn_request
jagger_satosa.1.niwh0x0v4r34 at totoro | return self.auth_req_callback_func(context, internal_req)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 103, in _auth_req_callback_func
jagger_satosa.1.niwh0x0v4r34 at totoro | return self._auth_req_finish(context, internal_request)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 108, in _auth_req_finish
jagger_satosa.1.niwh0x0v4r34 at totoro | return backend.start_auth(context, internal_request)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 179, in start_auth
jagger_satosa.1.niwh0x0v4r34 at totoro | return self.disco_query(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 211, in disco_query
jagger_satosa.1.niwh0x0v4r34 at totoro | disco_url, self.sp.config.entityid, **args
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/opt/satosa/lib/python3.7/site-packages/saml2/client_base.py", line 936, in create_discovery_service_request
jagger_satosa.1.niwh0x0v4r34 at totoro | if '?' in url:
jagger_satosa.1.niwh0x0v4r34 at totoro | TypeError: argument of type 'NoneType' is not iterable
jagger_satosa.1.niwh0x0v4r34 at totoro |
jagger_satosa.1.niwh0x0v4r34 at totoro | The above exception was the direct cause of the following exception:
jagger_satosa.1.niwh0x0v4r34 at totoro |
jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last):
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/proxy_server.py", line 118, in __call__
jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self.run(context)
jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 258, in run
jagger_satosa.1.niwh0x0v4r34 at totoro | raise SATOSAUnknownError("Unknown error") from err
jagger_satosa.1.niwh0x0v4r34 at totoro | satosa.exception.SATOSAUnknownError: Unknown error
############################
