Hi all,
I've set up Satosa as a proxy between a SAML 2.0 backend and an OpenID
Connect frontend (OP). This works fine for the basic flow, but the RP
indicates they're missing the introspect endpoint. I was looking though
the docs but could not find information about support for it. Am I
overlooking something or does Satosa not support introspection?
Kind regards,
Thijs Kinkhorst
SURF
Hello,
we've been setting up SATOSA as a proxy that uses the SAML 2.0 backend
to authenticate against a SAML federation, and provides authentication
via the OpenID Connect frontend.
We've successfully managed to map attributes from the SAML side to
scopes on the OIDC side.
However, to qualify these attributes, it seems sensible to also check
the SAML entity ID of the IdP that made the assertions.
How can we expose the entity ID of the IdP asserting the identity of the
user on the OIDC side?
All Best,
Chris
--
Christian Franke
reelport GmbH
Karl-Heine-Str. 93
04229 Leipzig
Germany
Email: christian.franke at picturepipe.com
GPG-KeyID: 0xB657CF42AE512BEE
Phone: +49-157-34575984
Web: http://www.picturepipe.com/
CEO Tilman Scheel
Amtsgericht Duisburg, HRB 17622
USt-IdNr.: DE814323473
Hello everyone,
I have pulled up an example project which exemplifies a SATOSA saml2saml
proxy demo.
Specifically, I use my pySAML2 and SATOSA forks for interoperability with
SPID (Italian Digital Identity System) but all this is not necessary for
those who do not have the same problems I have!
I share as it is, here
https://github.com/peppelinux/Satosa-Saml2Spid
probably the only convincing innovation for those who already deal with
SATOSA, excluding the animated gif in the readme (!), is that my Dockerfile
adopts alpine linux, consuming less than half the storage space normally
required by Debian and overall I also register a performance gain, but I
haven't certain numbers at the moment, only "Human sensations" :')
best regards
Giuseppe
____________________
Giuseppe De Marco
Centro ICT d'Ateneo
Università della Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
Hello,
I'm currently trying to setup SATOSA as a proxy with a SAML2 backend and an OIDC frontend as I have a few apps that only support OIDC connect, but not SAML.
Following the doc https://github.com/IdentityPython/SATOSA/blob/master/doc/saml2-to-oidc.md I created the necessary config files, but I can't make much sense out of the configuration parameters as https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#proxy_co… only describes a few of them and only on a very high level.
Most importantly:
- are <base_url> and <name> actual (auto-populated?) variables or do I have to replace them? base_url may be obvious (BASE from proxy_conf.yaml?) but what is "name"?
- am I really supposed to generate the metadata manually using https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#saml_met… or is that achieved automatically by "entityid_endpoint: true" already? if not where does the resulting file need to be put an referenced?
- with "entityid_endpoint: true" and "entityid: '<base_url>/<name>/metadata'" configured shouldn't I be able to download the SP metadata from this very URL? This doesn't seem to work for me (but may be related to Q1) as I'm only getting "The Service or Identity Provider you requested could not be found." (with various variations of name being "app" or "sp")
- which backend endpoints are actually needed for a simple saml2-to-oidc use case?
Reading through the mailing list I have only seen some known issues when connecting to Shibboleth as IdP. Are there also known issues or recommended configuration parameters when connecting to a SimpleSAMLphp IdP?
Thanks for any pointers!
Chris
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?
