January 2024 - satosa-users

XML decoding failing for an AuthN Request

by Hannah Short

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

1 week, 6 days

3
3
0 0

FW: SATOSA Single Logout Service

by ferdy.mul＠ncr.nstda.or.th

Resend. From: Ferdy Mulyadi <ferdy.mul at ncr.nstda.or.th> Sent: Selasa, 04 Februari 2020 10.15 To: 'satosa-users at lists.sunet.se' <satosa-users at lists.sunet.se> Subject: SATOSA Single Logout Service Hi SATOSA users, Currently, we are working on SSO project which is Zoom SSO service. We use SATOSA proxy in order to connect with our identity federation (one-to-many type), and we have already implemented single sign-on (SSO) service and it's working, however we still require single logout service (SLO). We couldn't find any SATOSA configuration regarding to SLO from SATOSA documentation. Without SLO, although user has already selected and clicked log out from Zoom, the session still there, otherwise user requires to clear the browser cache. Could you explain to us, how to implement SLO in SATOSA? Thank you. ---------------- Best regards, Mr. Ferdy Mulyadi Research Assistant Internet Innovation Research Team (INO - CNWRG) National Electronics and Computer Technology Center (NECTEC) National Science and Technology Department Agency (NSTDA) Thailand Science Park (TSP) - 112 Phaholyothin Rd., Khlong Nueng, Khlong Luang Pathum Thani, THAILAND ________________________________ Disclaimer: This e-mail and any files transmitted with it may contain confidential and proprietary information of the National Science and Technology Development Agency (NSTDA), Thailand. They are intended solely for the use of the addressed individuals or entities. If you are not the intended recipient, you are required to immediately delete this e-mail and its contents from your system. Any disclosure, distribution, or action based upon the contents of this e-mail is strictly prohibited. Any views or opinions presented in this e-mail are solely those of the sender and do not necessarily represent those of NSTDA. NSTDA does not accept any responsibility for the content of this message or the consequences of any actions taken on the basis of the information provided. NSTDA accepts no liability for any damage caused by any virus or malware which may be inserted in this e-mail during transmission.

2 months, 1 week

3
2
0 0

configuration error: unknown system entity

by 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

2 months, 2 weeks

3
3
0 0

SATOSA Quickstart

by xenophon＠irtnog.org

I want to again say "thanks" to Ioannis, Rainer, Scott, and everyone else for their help and instruction during the various IdentityPython and SATOSA meetings at TIIME this week. Chris Phillips and I were able to get a SATOSA 3.4.8 deployment working in Chris's idp-installer test bed. To that end I want to share my notes from the process, at the end of which an interested party could perform a basic, end-to-end test of the current SATOSA release using SAMLtest (https://samltest.id/) 1. I installed Ubuntu Server 18.04.1; run the following commands as root to install the prerequisites: ```sh apt update apt dist-upgrade -y apt install -y git python3-dev build-essential python3-pip libffi-dev libssl-dev xmlsec1 libyaml-dev libxml2-utils pip3 install --upgrade virtualenv virtualenv -p python3 /opt/satosa /opt/satosa/bin/pip install --upgrade pip setuptools /opt/satosa/bin/pip install SATOSA ``` This is essentially the Docker image build process, only it uses the current SATOSA release (etc.) on PyPI. 2. Copy https://github.com/IdentityPython/SATOSA/tree/v3.4.8/docker/attributemap s to /opt/satosa/attributemaps. I'm not sure this is strictly necessary as the built-in pysaml2 attribute maps should be used by default, but it's what the Docker image build process does. 3. Copy https://github.com/IdentityPython/SATOSA/tree/v3.4.8/example to /opt/satosa/etc. 4. SATOSA doesn't have a default configuration, so you must provide it yourself. ```sh cp /opt/satosa/etc/proxy_conf.yaml.example \ /opt/satosa/etc/proxy_conf.yaml cp /opt/satosa/etc/internal_attributes.yaml.example \ /opt/satosa/etc/internal_attributes.yaml cp /opt/satosa/etc/plugins/frontends/saml2_frontend.yaml.example \ /opt/satosa/etc/plugins/frontends/saml2_frontend.yaml cp /opt/satosa/etc/plugins/backends/saml2_backend.yaml.example \ /opt/satosa/etc/plugins/backends/saml2_backend.yaml cp /opt/satosa/etc/plugins/microservices/static_attributes.yaml.example \ /opt/satosa/etc/plugins/microservices/static_attributes.yaml ``` 5. You may change the proxy URL (the value of BASE in /opt/satosa/etc/proxy_conf.yaml), but it _must_ be a method plus hostname without any trailing slash or path components, e.g., `https://proxy.example.com`, not `https://proxy.example.com/` nor `https://proxy.example.com/satosa`. SATOSA must be hosted at the root of your web site. 6. Comment out the `idp_blacklist_file` and `disco_srv` settings in /opt/satosa/etc/plugins/backends/saml2_backend.yaml. 7. Generate IdP, SP, metadata signing, and web site keying material: ```sh for i in frontend backend metadata https; do openssl req -batch -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /opt/satosa/etc/$i.key -out /opt/satosa/etc/$i.crt \ -subj /CN=proxy.example.com done ``` 8. Download the SAMLtest metadata. ```sh curl https://samltest.id/saml/sp > /opt/satosa/etc/sp.xml curl https://samltest.id/saml/idp > /opt/satosa/etc/idp.xml ``` 9. Generate the proxy metadata. (How you do this changes in future releases of SATOSA.) ```sh . /opt/satosa/bin/activate cd /opt/satosa/etc satosa-saml-metadata proxy_conf.yaml metadata.key metadata.crt --split-frontend --split-backend --dir /opt/satosa/etc xmllint --format /opt/satosa/etc/Saml2IDP_0.xml > /opt/satosa/etc/proxy-idp.xml xmllint --format /opt/satosa/etc/Saml2_0.xml > /opt/satosa/etc/proxy-sp.xml ``` 10. Edit the proxy metadata files to remove the `<ns1:Signature>` element, else SAMLtest will be unable to load them due to an invalid signature. 11. Upload the proxy metadata to SAMLtest (https://samltest.id/upload.php) 12. SAMLtest doesn't release the eduPerson Targeted ID attribute, so you'll need to change the last three lines of /opt/satosa/etc/internal_attributes.yaml to the following (and before anyone says anything, NEVER USE AN EMAIL ADDRESS AS AN IDENTIFIER---this is just a quick hack to get SATOSA working): ``` hash: [mail] user_id_from_attrs: [mail] user_id_to_attr: mail ``` 13. Start SATOSA: ```sh . /opt/satosa/bin/activate cd /opt/satosa/etc gunicorn -b0.0.0.0:443 --keyfile https.key --certfile https.crt satosa.wsgi:app ``` 14. At this point you should be able to perform an IdP test (https://samltest.id/start-idp-test/) by specifying the entity ID of the proxy's front end, e.g., https://example.com/Saml2IDP/proxy.xml. The SAMLtest SP will request authentication by your proxy IdP, causing your proxy SP to request authentication by the SAMLtest IdP. If everything works right, you will end up back at the SAMLtest SP: SAMLtest SP ---AuthnRequest---> SATOSA front end (IdP)/back end (SP) ---AuthnRequest---> SAMLtest IdP SAMLtest SP <---AuthnResponse--- SATOSA front end (IdP)/back end (SP) <---AuthnResponse--- SAMLtest IdP I hope this helps other adopters. If you have any questions, please reply on list so everyone can benefit from the discussion. Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

3 months, 1 week

5
5
1 0

Different discovery service for different SPs

by xenophon＠irtnog.org

Dear all, Is it possible to use a different discovery service depending on the SP that sent a SAML AuthnRequest to SATOSA, or do I have to do that in the discovery service's frontend somehow? Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

11 months, 3 weeks

3
3
0 0

oidc client registration

by peter.schober＠univie.ac.at

Not knowing whether my satosa instance is fully working yet (see my other thread) I'm now continuing to try to get the application (eduMEET) to work with satosa's oidc frontend, as per the app's published config example: https://github.com/havfo/multiparty-meeting/blob/master/server/config/confi… So I've made up a client_id and client_secret on the RP side and provided the client with an issuerURL (base URL of satosa), let it request all the scopes in the world and set its own redirect_uri. With those all set I do see requests to satosa's .well-known endpoints from the application in satosa logs, e.g. Found registered endpoint: module name:'oidc', endpoint: .well-known/openid-configuration (And of course accessing the endpoint myself I can see that it works and produces JSON with its config.) Now on the OP side (satosa oidc frontend) I haven't done any setup for the client yet, so I guess the error in the log is to be expected: Error in authn req: Unknown client_id Now what would be the next steps to register that client? The request from the client (according to satosa's logs) has these query parameters (where cid and csec are the correct client_id and client_secret, respectively): client_id=cid&scope=openid+email+profile&response_type=code&redirect_uri=https%3A%2F%2Fexample.org%2Fauth%2Fcallback&state=e30%3D&client_secret=csec My plugins/frontends/openid_connect_frontend.yaml looks like the published example, essentially: module: satosa.frontends.openid_connect.OpenIDConnectFrontend name: oidc config: signing_key_path: /etc/satosa/oidc-provider.key #db_uri: mongodb://db.example.com # optional: only support MongoDB, will default to in-memory storage if not specified client_db_path: /etc/satosa/oidc-clients.json provider: client_registration_supported: True response_types_supported: ['code', 'token', 'id_token'] subject_types_supported: ['public', 'pairwise'] scopes_supported: ['openid', 'email', 'profile'] Only that I tried to enable pretty much everything (all repose and subject types, all scopes, client registration) since I had no idea what the RP side wants, yet. (Seems I can remove all response types except 'code', as per the log shown above.) I don't have MongoDB set up yet since the comment above suggests an in-memory store would be used, which is fine for my current testing. And looking at _create_provider() at frontends/openid_connect.py the code would use the file referenced by client_db_path if db_uri isn't set even before falling back to storing it in a variable. The file referenced in client_db_path exists, is writable by the user satosa runs as, and currently contains only '{}' (without the quotes). So IMO that should be sufficient. Any hints on how to register the application? The documenation is a bit sparse here https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#frontend… only mentioning that *without* dynamic client registration (which I have enabled for now, but maybe the RP doesn't support it) I'd have to manually create the data structures in MongoDB (or the file in client_db_path) for my client, as per the oidc spec for Client Registration Responses. Could someone share a json sample to put into the file referenced by client_db_path (if that's how it's supposed to work)? Cheers, -peter

1 year

2
2
0 0

SAML2-SAML2 proxy connected to federation: Hardcode different IDPs

by Jonas Schwab

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

2 years, 8 months

1
0
0 0

satosa-oidcop and the OIDC Playground

by xenophon＠irtnog.org

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

2 years, 8 months

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

satosa-users January 2024