Can I (pre-)select a single/specific IDP to use with a saml2 backend
plugin even if that backend loads multiple IDPs from remote metadata?
The documentation[1] seems to say that I can't avoid IDP Discovery
whenever multiple IDPs are available:
> To allow the user to choose which target provider they want to
> authenticate with, the configuration parameter disco_srv, must be
> specified if the metadata given to the backend module contains more
> than one IdP.
(Why load multiple IDPs from remote metadata then when you want to
avoid IDP Discovery? Because those IDPs may be available in remotely
managed and regularly re-signed metadata. And there's no MDQ service
available to hand out an up-to-date, signed copy of only a single IDP
for Satosa to consume.)
Related to this question: Setting the 'idp' configuration parameter in
service -> sp within the saml2 backend plugin (as shown in the pysaml2
docs[2]) resulted in no observable change for Satosa (running 8.4.0
from the official docker image). Is that to be expected? Other
parameters from pysaml2 are included in Satosa's saml2 backend plugin
at the same level as the 'idp' parameter,
e.g. 'authn_requests_signed'. But maybe I'm imagining a relationship
here between Satosa and pysaml2 config parameters that doesn't exist?
```yaml```
module: satosa.backends.saml2.SAMLBackend
name: sp
config:
sp_config:
service:
sp:
idp: ['https://idp.example.org/entity']
```
Anyway, here's the behaviour I (don't) see:
With exactly one IDP as list member (as in the YAML above and also the
pysaml2 docs[2]) this did not circumvent IDP Discovery as I had
expected and would have been useful: With only a single IDP allowed
there's no point in offering other IDPs to the subject.
(See above for why it may be useful to have multiple IDPs known via
metadata but still circumvent IDP discovery by configuration.)
But also when configuring one IDP (still as per above) and picking
*another* IDP during IDP Discovery access to the configured RP (oidc
frontend) was granted just the same. I.e., I could not determine how
the selected IDP was somehow "not allowed to be used" (as per the
pysaml2 docs, not Satosa's).
So unless I'm Doing Things Wrong™ it seems there's no use being made
of the 'idp' parameter within the SAML SP config (saml2 backend
plugin) within Satosa? If so, could or should there be?
Best,
-peter
[1] https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#use-a-di…
[2] https://pysaml2.readthedocs.io/en/latest/howto/config.html#idp
We have an Incommon Application that is sending a list of three (3) requested attributes. Even though KeyCloak is passing all of the attributes we have configured, once it is filtered out by Satosa it is only passing on the attributes that the actual SP from InCommon requested. Is there a way to override this?
Dear everyone,
I have a working SAML2-SAML2 proxy accessing the DFN-AAI, using the
DFN-AAI WAYF. This works as expected. Now I was wondering if it is
possible to add additional frontends, where each frontend has a DFN-AAI
IDP hardcoded it directly proxies to?
Thank you for your help!
Best regards,
Jonas Schwab
Dear all,
I am currently trying to set up a saml2-saml2 proxy and have come to an
impasse: It seems that I have incorrectly/incompletely set up the
frontend. When trying to log in satosa logs "configuration error:
unknown system entity <entityID of SP>". I thought the entityID would be
set in the frontend plugin configuration through
config.idp_config.metadata.local = <file containing SP metadata>. Do I
have to set the SP entityID somewhere else?
Thank you for your help!
Best regards,
Jonas Schwab
I'm trying to test my SATOSA OIDC OP using the OpenID Connect
Playground, but it looks like the client isn't registering itself with
SATOSA properly. I don't know how to fix this and would be grateful for
any help!
I have installed satosa-oidcop
(https://github.com/UniversitaDellaCalabria/SATOSA-oidcop) and
configured it to use Amazon DocumentDB (MongoDB-compatible).
On https://openidconnect.net/:
- I select the "OpenID Connect + OAuth2" mode (default and only option).
- I click "Configuration".
- I select the "Custom" server template.
- I enter the discovery document URL generated by SATOSA
($BASE_URL/.well-known/openid-configuration), click "Use Discovery
Document", and click "Save".
The configuration tool sets the authorization token endpoint to
$BASE_URL/Saml2/OIDC/authorization, the token endpoint to
$BASE_URL/OIDC/token, and the token keys endpoint to
$BASE_URL/OIDC/jwks. This looks correct.
The configuration tool tells me to set
"https://openidconnect.net/callback" as an allowed callback within my
application, and it shows me its OIDC Client ID, OIDC client secret,
scopes (defaults to "openid profile email phone address"), and optional
audience (blank).
When I click "Start" to begin the OIDC authentication process, I get the
following error:
https://openidconnect.net/callback?error=invalid_request&error_message=Resp…...
SATOSA logs the following at client configuration time:
```
[DEBUG] [satosa.routing.endpoint_routing] [urn:uuid:..1] Routing path:
.well-known/openid-configuration
[DEBUG] [satosa.routing.endpoint_routing] [urn:uuid:..1] Unknown backend
.well-known
[DEBUG] [satosa.routing._find_registered_endpoint_for_module]
[urn:uuid:..1] Found registered endpoint: module name:'OIDC', endpoint:
.well-known/openid-configuration
Then it logs the following when I start the OIDC request process:
```
[ERROR]
[pyop.request_validator.response_type_is_in_registered_response_types]
client metadata is missing response_types
[ERROR] [satosa.frontends.openid_connect._handle_authn_request]
[urn:uuid:..2] Error in authn req: Response type is not registered
```
When I look at DocumentDB, I see the "satosa" database and accompanying
collections, but the clients collection appears to be empty:
```
rs0:PRIMARY> show dbs
sample_database 0.000GB
satosa 0.000GB
rs0:PRIMARY> use satosa
switched to db satosa
rs0:PRIMARY> show collections
access_tokens
authz_codes
clients
refresh_tokens
subject_identifiers
rs0:PRIMARY> db.clients.find()
rs0:PRIMARY>
```
What am I missing?
--
"The reason that ed is the standard editor is to remind you that
things could be worse, and once were." -- Tim Lavoie in comp.lang.lisp
Dear all,
I’m pleased to announce a long overdue update to the Docker Official
Image for SATOSA, which includes several significant changes:
- SATOSA 8.4
- Python 3.12
- Debian 12 “bookworm”
- Alpine Linux 3.19
The updated container image is now available from Docker Hub. For more
information, see https://hub.docker.com/_/satosa.
Happy holidays!
Matthew
--
"The reason that ed is the standard editor is to remind you that
things could be worse, and once were." -- Tim Lavoie in comp.lang.lisp
Hi Satosa users,
I’m having trouble with a SAML request being incorrectly inflated/decoded and then failing with the error “invalid signature” (which I think is misleading). I couldn’t see a known issue about this on GitHub. I’m running Satosa 8.2. Has anyone seen this and has a suggestion?
Both the good and bad AuthN Requests in the logs below validate fine at https://www.samltool.com/decode.php
Example, “bad” encoding from https://sptest.iamshowcase.com/instructions:
[1687184930.586361] [2023-06-19 14:28:50] [DEBUG]: read request data: {'SAMLRequest': 'fVFbb4IwFP4rTd/lUrVCIyRsZhmJZkbYHvZWSh1NoGU9ZdvPH6Jm7sXHk+98t3PWwLu2Z9ngGn2Qn4MEh366VgObgAQPVjPDQQHTvJPAnGBFttsy4gWst8YZYVp8Q7nP4ADSOmU0Rk/GCjn5JvjIW5AYoXyTYB7VhNdRTOpFSGkYrZYhJTSIBa9EFR/JPKLVKpSUYpQDDDLX4Lh2CSYBmc8COgvjMlwwErFl8I7RZmykND95Jrhxrgfm+6ruPSGt9kTjn0IT6H0A4/cGHEbZNeSj0TB00hbSfikhXw/bPwno3ajsKd5BY74FB+kJ0/lcwNhjfznMg9K10h/3b1Kdl4A9l+V+tn8pylEBvUkLU+ZxBafrU0o29bUozbNdcTFd+zdIep7+vzP9BQ=='}
...
[1687184930.589399] [2023-06-19 14:28:50] [DEBUG]: xmlstr: b'}Q[o\x820\x14\xfe+M\xdf\xe5R\xb5B#$lf\x19\x89fF\xd8\x1e\xf6VJ\x1dM\xa0e=e\xdb\xcf\x1f\xa2f\xee\xc5\xc7\x93\xef|\xb7s\xd6\xc0\xbb\xb6g\xd9\xe0\x1a}\x90\x9f\x83\x04\x87~\xbaV\x03\x9b\x80\x04\x0fV3\xc3A\x01\xd3\xbc\x93\xc0\x9c`E\xb6\xdb2\xe2\x05\xac\xb7\xc6\x19aZ|C\xb9\xcf\xe0\x00\xd2:e4FO\xc6\n9\xf9&\xf8\xc8[\x90\x18\xa1|\x93`\x1e\xd5\x84\xd7QL\xeaEHi\x18\xad\x96!%4\x88\x05\xafD\x15\x1f\xc9<\xa2\xd5*\x94\x94b\x94\x03\x0c2\xd7\xe0\xb8v\t&\x01\x99\xcf\x02:\x0b\xe32\\0\x12\xb1e\xf0\x8e\xd1fl\xa44?y&\xb8q\xae\x07\xe6\xfb\xaa\xee=!\xad\xf6D\xe3\x9fB\x13\xe8}\x00\xe3\xf7\x06\x1cF\xd95\xe4\xa3\xd10t\xd2\x16\xd2~)!_\x0f\xdb?\t\xe8\xdd\xa8\xec)\xdeAc\xbe\x05\x07\xe9\t\xd3\xf9\\\xc0\xd8c\x7f9\xcc\x83\xd2\xb5\xd2\x1f\xf7oR\x9d\x97\x80=\x97\xe5~\xb6\x7f)\xcaQ\x01\xbdI\x0bS\xe6q\x05\xa7\xebSJ6\xf5\xb5(\xcd\xb3]q1]\xfb7Hz\x9e\xfe\xbf3\xfd\x05', relay_state: None, sigalg: None, signature: None
Example “good” encoding from https://samltest.id/saml-test/:
[1687184991.342228] [2023-06-19 14:29:51] [DEBUG]: read request data: {'SAMLRequest': 'fZHdT4MwFMX/FdL3UejGJs0gwe3BJVPJQB98MaUUaQIt9hY//nv50DgTs7cmPed37j13C6xtOpr0tlYn8doLsM5H2yig00eEeqOoZiCBKtYKoJbTLLk9UuJ6tDPaaq4b5CQAwlip1U4r6FthMmHeJBcPp2OEams7oBiPRDsEuLLEWS2LQjfC1i6AxiOS4PQ+y5GzHyRSsZH265Vl53JhlMvriUOgw6PRiFIawS1yDvsIPa+qDd+EVyUjgR/6q6AI+bJaE1IUPqlKLxhkAL04KLBM2QgRjywX3nrhh7m/oiSkgf+EnPR7r2upSqleLpdQzCKgN3meLuYVHoWBafxBgOLtODCdgs1ZuZex7KdRFP/X3/jG0G3xGXsO6ujdADvsU91I/ukkTaPfd0YwKyLkIxzPlr8nj78A', 'RelayState': 'ss:mem:a06bd083cf6e2d94f28cccd470c97390dc2ccf20657a3be36e36bce4521e8cdd’}
...
[1687184991.345231] [2023-06-19 14:29:51] [DEBUG]: xmlstr: b'<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://samltest.id/Shibboleth.sso/SAML2/POST" Destination="https://idp.cern.ch/saml2sp/sso/redirect" ID="_4f7c798da2519145b9c3f622bb12fd05" IssueInstant="2023-06-19T14:29:51Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://samltest.id/saml/sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>', relay_state: None, sigalg: None, signature: None
Thanks for any help!
Hannah
Dear satosa users,
I'm running the debian docker of satosa v8.2 and tried setting CUSTOM_PLUGIN_MODULE_PATHS in proxy_conf.yaml in order to load custom modules (microservices). I would like to mount the microservices from the docker host. I tried relative paths and absolute paths within the docker container but satosa raises a ValueError that it cannot find the modules.
I could mount them like this "./modules/custom_service.py:/usr/local/lib/python3.11/site-packages/satosa/micro_services/custom_service.py" but I'd prefer to mount them with the configuration folder /etc/satosa/ or in a similar way
Anyone got a clue how to load custom microservices with the option?
Regards
canni
Since the documentation could not really help me, I now asked by e-mail:
I already have SATOSA running successfully in a pyenv and would now like to run the whole thing in a container on another host. However, I fail already when starting the container. I use Rocky Linux 9 and podman, my configuration is under /home/satosa/application. In addition to the plugin folder, there is also a folder for the metadata and the attribute map. The certificates for the saml2 frontend and backend are in the certs directory.
What do I have to bear in mind when starting the container?
And another question: I am looking for a plugin that denies users access to the application behind the proxy if certain attributes are missing. Is there already something available?
Any help is appreciated.
Regards
Stephan
Stephan Krinetzki
IT Center
Gruppe: Anwendungsbetrieb und Cloud
Abteilung: Systeme & Betrieb
RWTH Aachen University
Seffenter Weg 23
52074 Aachen
Tel: +49 241 80-24866
Fax: +49 241 80-22134
krinetzki(a)itc.rwth-aachen.de
www.itc.rwth-aachen.de
Social Media Kanäle des IT Centers:
https://blog.rwth-aachen.de/itc/https://www.facebook.com/itcenterrwthhttps://www.linkedin.com/company/itcenterrwthhttps://twitter.com/ITCenterRWTHhttps://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ
Since the documentation could not really help me, I now asked by e-mail:
I already have SATOSA running successfully in a pyenv and would now like to run the whole thing in a container on another host. However, I fail already when starting the container. I use Rocky Linux 9 and podman, my configuration is under /home/satosa/application. In addition to the plugin folder, there is also a folder for the metadata and the attribute map. The certificates for the saml2 frontend and backend are in the certs directory.
What do I have to bear in mind when starting the container?
And another question: I am looking for a plugin that denies users access to the application behind the proxy if certain attributes are missing. Is there already something available?
Any help is appreciated.
Regards
Stephan
Stephan Krinetzki
IT Center
Gruppe: Anwendungsbetrieb und Cloud
Abteilung: Systeme & Betrieb
RWTH Aachen University
Seffenter Weg 23
52074 Aachen
Tel: +49 241 80-24866
Fax: +49 241 80-22134
krinetzki(a)itc.rwth-aachen.de
www.itc.rwth-aachen.de
Social Media Kanäle des IT Centers:
https://blog.rwth-aachen.de/itc/https://www.facebook.com/itcenterrwthhttps://www.linkedin.com/company/itcenterrwthhttps://twitter.com/ITCenterRWTHhttps://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ
