January 2021 - satosa-users

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."

1 month

3
3
0 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."

3 months, 4 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

4 months, 3 weeks

2
2
0 0

Satosa-Saml2Saml example project

by giuseppe.demarco＠unical.it

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

5 years

1
0
0 0

setting up a saml2-to-oidc proxy

by chris.mailing＠gmx.net

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

5 years

2
1
0 0

Potential issue w/ deleted subject-identifiers from MongoDB in v7.x

by david.huebner＠daasi.de

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

5 years

1
0
0 0

SaToSa throughput problems

by JonathanANewell＠hotmail.com

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

5 years

3
2
0 0

Vulnerabilities affecting pySAML2 and forthcoming release

by ivan.kanak＠gmail.com

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

5 years

1
3
0 0

Backend not responding (SAML-to-SAML)

by c.nattero＠fadeout.it

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.

5 years

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

satosa-users January 2021