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
Hello everyone,
My company develops a web application that uses Keycloak to authenticate / manages users.
We would like to accept authentication from Edugain but Edugain is not only one federation: it is an interconnection of many federations.
Therefore, if I want to accept Edugain it means I have to import one by one each Edugain Federation and our end users have to choose the right one in a list.
Example:
- if I have these Edugain federations:
- Federation A
- Federation B
- Federation C
- Federation D
- I have to import / create an identity provider for each one in Keycloak:
- Federation A
- Federation B
- Federation C
- Federation D
- the end user has to choose the Edugain Federation in which he/she has an account: Federation C
This is not a good option in term or ergonomy because there are too many federations...
I discovered Satosa and maybe I'm wrong (as I was not able to implement it yet) but I have the feeling it could help us 🙂
The scheme I try to obtain is: our internal application -> Keycloak -> Satosa -> Edugain
The idea is this one:
- Keycloak should see only one Identity Provider 'Edugain': in reality it is Satosa behind
- and Satosa discovers the Edugain federations
I'm not comfortable with these technologies / these protocols (Keycloak, Satosa, SP, IDP, SAML, etc) and therefore I don't understand how to configure all components...
Is this someone did the same (Keycloak or Gluu + Satosa + Edugain) and could share with me an example of configurations please?
At least the Satosa configuration files (frontend, backend, etc).
Thank you very much :)
Bertrand
