July 2019 - satosa-users - lists3.sunet.se

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

<resolved>Re: Guidance sought on allowing attributes to pass through with statosa/statosa:latest

by Chris.Phillips＠canarie.ca

Hi. I believe I have resolved my issues and have a functioning SATOSA instance in my pre-prod environment. I hit 5 main items (so far) and hope that capturing can help others have an easier story. I’m interested in helping improve docs and need guidance as to where and how – github wiki? Fork repo then do a pull request? Reflections on using SATOSA in pre-prod use marching toward full production use so far: * Starting from zero to this stage was non-small but any other proxy story would have been more effort IMO. * These items were costly in time to come by and hope that it helps shorten implementations to capture them. * If I had them, SATOSA is a slam dunk on fastest and ‘thinnest’ deployment. Kudos to the work put into SATOSA and for future work on the horizon. Thoughts and questions welcome as always .. my notes and details on how I resolved things are below. C Main challenges and steps taken to have SATOSA operating as expected for attribute passing and assertion handling ======================================================= 1. Sp.xml proved impactful on parsing if it had too much in it thus rendering the filter attributes empty =========== I had ACS entries for required/requested attributes which seem to have bumped my internal_attributes filter sufficiently to zero (empirical observation) My resolution: remove those elements as well as the MD contact info from the sp.xml metadata appeared to have resolved this first step Suggestion: more clarity on this element would help. 1. YAML syntax on how to ingest an aggregate in the ‘backend’ was tough to decipher and documentation is thin or maybe aged out. =========== My resulting format working for my docker image: satosa/satosa:latest for the backend.yaml is: <snip> metadata: remote: - {url: "https://url.to/fed.xml", cert: "/opt/satosa/etc/pki/testfed.crt"} <snip> This does not align with documentation that I’ve encountered for SATOSA. Suggestion: configuration for multi-lateral federation would benefit to be an example. As would version sensitivity of it and more examples to show what would be sufficient to run 1. Internal_attributes.yaml mapping transformed email to mail thus downstream was ‘no email, no access!’ =========== The mapping of email to mail OIDs – YIKES! Who knew that PKCS_9 +1 vs UCL_DIR_PILOT+3 were different? I hated myself on this one * The hurt was in internal_attributes.yaml had * Mail: * Saml: [email, emailAddress, mail] * As such it translated the Shib assertion from ‘mail’ to ‘email’ OID Action taken to resolve: set saml: [mail] for the mail element Suggestion: there’s a lot to talk about here on mapping – this is a place for some good practices and what’s there looks good for just working but the transposition was subtle to detect. Hard to say how to make it easier without more thought. 1. Run SATOSA behind apache to trap errors better was tough to find and used a slightly different way than the WSGI interface =========== The reference to error handling is a bit oblique as there’s more than one way to do it and the WSGI apache proxy was not immediately there for me Here’s the snippet from the apache2 config that allows me to handle the 404’ing of access for a more graceful error page handling: # # proxy SATOSA so we can handle 404's better # don’t forget to a2en proxy; a2en proxy_http in apache2 # ProxyErrorOverride is **CRITICAL** to trap the 404 passed up by gunicorn. Proxypass /Saml2 http://127.0.0.1:8000/Saml2 ProxyPassReverse /Saml2 http://127.0.0.1:8000/Saml2 ProxyErrorOverride On ErrorDocument 404 /errors/404.html Suggestion: This is a strong need for error handling. Templating it for the enhancement listed in the issue tracker not so much as just give me some plain html locations to use or mount in the container rather than punting to a proxy above resulting in a proxy of a proxy. 1. To handle ADFS assertions inbound to SATOSA properly needed the backend.yaml/federation facing settings to want_response_signed=False and not ‘true’ =========== Testing various IdPs like Shibboleth and ADFS revealed that to use ADFS out of the box with a SAML trust to SATOSA I needed want_response_signed=False. * This deploys as ‘true’ for SATOSA recommended (and is a good posture to be fair!) but ADFS won’t play fair with it that I could tell. * This was only uncovered while reading ‘Signature error: Signature missing for respose’ in google and found this: * https://github.com/IdentityPython/pysaml2/issues/490 Suggestion: Again, this is a practitioner configuration. Thankfully the setting is there, now it needs more revelation in documentation and how to use things and consequences of the action like this. From: Chris Phillips <Chris.Phillips at canarie.ca> Date: Friday, July 19, 2019 at 8:50 AM To: "satosa-users at lists.sunet.se" <satosa-users at lists.sunet.se> Subject: Guidance sought on allowing attributes to pass through with statosa/statosa:latest Hi. I’m trying to work through a SATOSA story of SP with only one IdP configured to be proxied to use a federation aggregates’ metadata. Sign on is working and always get Filter: [] and returning attributes {} when I expect attributes to be sent by SATOSA. I’m using the docker image Latest and have also tried v4.4.0 with same result. I don’t think I’m too fancy and am using SATOSA ‘out of the box’ and am looking for guidance/insight/suggestions on what may be wrong, missing, or off by a few columns in YAML 😊 I have had success in the past at TIIME in Feb2019 with Matt E. but that was non-docker and a v3.4.8 install: https://lists.sunet.se/pipermail/satosa-users/2019-February/000067.html I have seen/explored the microservices/ filter_attributes.yaml.example but that is more along suppression rather than permit passage. Must I whitelist everything? Thanks for any insight/guidance on this. I have a gist with front/backends here: https://gist.github.com/canariecaf/2216d3de5e5872ecaa08cf03548ec559 Happy to jump on Slack and chat there too – is there a slack area for satosa/idpy BTW or the edugain.slack.com location have idpy like venues for chats like this? C satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing path: Saml2/acs/post satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Found registered endpoint: module name:'Saml2', endpoint: Saml2/acs/post satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['email', 'emailAdress', 'mail']' mapped to mail satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['postaladdress']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['sn', 'surname']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['displayName']' mapped to displayname satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['givenName']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['eduPersonTargetedID']' mapped to edupersontargetedid satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['cn']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] backend received attributes: satosa_1 | { satosa_1 | "eduPersonPrincipalName": [ satosa_1 | "something at canarie.ca" satosa_1 | ], satosa_1 | "mail": [ satosa_1 | "Chris.Phillips at canarie.ca" satosa_1 | ], satosa_1 | "eduPersonScopedAffiliation": [ satosa_1 | "staff at canarie.ca" satosa_1 | ], satosa_1 | "eduPersonAffiliation": [ satosa_1 | "staff" satosa_1 | ], satosa_1 | "eduPersonTargetedID": [ satosa_1 | "SUPPRESED=" satosa_1 | ], satosa_1 | "displayName": [ satosa_1 | "Chris Phillips" satosa_1 | ] satosa_1 | } satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing to frontend: Saml2IDP satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Filter: [] satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] returning attributes {} satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] signing with algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] using digest algorithm http://www.w3.org/2001/04/xmlenc#sha256 satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Saving state as cookie, secure: True, max-age: 1200, path: /

7 years, 1 month

3
2
0 0

Production deployments of Satosa?

by jbanning＠oreilly.com

Hello satosa users, O'Reilly Media is working to build out a proper multilateral federation SP for our platform. We have deployed Shibboleth SP3 for development but are finding that integrating our existing systems with Shib to be inefficient and rather kludgy. SATOSA looks like a great fit for our python-based AuthN/Z OIDC backend but I have only identified a handful of deployments (E.G. GÉANT and possibly CERN). We would use it as a SAML backend and OIDC frontend with InCommon's MDQ feed and, initially, their discovery service as well. For those who have deployed SATOSA in production, what has your experience been in terms of reliability and maintainability, either generally or as compared to Shib SP3? Also, can you share roughly how much ongoing IT and development time has been needed to maintain a high level of uptime? I welcome additional feedback and suggestions as well. Thank you! -jesse -- Jesse Banning Manager of Platform Integration O'Reilly Media, Inc. <https://oreilly.com> (Boston Office <https://www.google.com/maps/place/O'Reilly>) (617)499-7575 | jbanning at oreilly.com Calendar: https://beta.doodle.com/jbanning

7 years, 2 months

2
1
0 0

Guidance sought on allowing attributes to pass through with statosa/statosa:latest

by Chris.Phillips＠canarie.ca

Hi. I’m trying to work through a SATOSA story of SP with only one IdP configured to be proxied to use a federation aggregates’ metadata. Sign on is working and always get Filter: [] and returning attributes {} when I expect attributes to be sent by SATOSA. I’m using the docker image Latest and have also tried v4.4.0 with same result. I don’t think I’m too fancy and am using SATOSA ‘out of the box’ and am looking for guidance/insight/suggestions on what may be wrong, missing, or off by a few columns in YAML 😊 I have had success in the past at TIIME in Feb2019 with Matt E. but that was non-docker and a v3.4.8 install: https://lists.sunet.se/pipermail/satosa-users/2019-February/000067.html I have seen/explored the microservices/ filter_attributes.yaml.example but that is more along suppression rather than permit passage. Must I whitelist everything? Thanks for any insight/guidance on this. I have a gist with front/backends here: https://gist.github.com/canariecaf/2216d3de5e5872ecaa08cf03548ec559 Happy to jump on Slack and chat there too – is there a slack area for satosa/idpy BTW or the edugain.slack.com location have idpy like venues for chats like this? C satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing path: Saml2/acs/post satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Found registered endpoint: module name:'Saml2', endpoint: Saml2/acs/post satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['email', 'emailAdress', 'mail']' mapped to mail satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['postaladdress']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['sn', 'surname']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['displayName']' mapped to displayname satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['givenName']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['eduPersonTargetedID']' mapped to edupersontargetedid satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['cn']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] backend received attributes: satosa_1 | { satosa_1 | "eduPersonPrincipalName": [ satosa_1 | "something at canarie.ca" satosa_1 | ], satosa_1 | "mail": [ satosa_1 | "Chris.Phillips at canarie.ca" satosa_1 | ], satosa_1 | "eduPersonScopedAffiliation": [ satosa_1 | "staff at canarie.ca" satosa_1 | ], satosa_1 | "eduPersonAffiliation": [ satosa_1 | "staff" satosa_1 | ], satosa_1 | "eduPersonTargetedID": [ satosa_1 | "SUPPRESED=" satosa_1 | ], satosa_1 | "displayName": [ satosa_1 | "Chris Phillips" satosa_1 | ] satosa_1 | } satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing to frontend: Saml2IDP satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Filter: [] satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] returning attributes {} satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] signing with algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] using digest algorithm http://www.w3.org/2001/04/xmlenc#sha256 satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Saving state as cookie, secure: True, max-age: 1200, path: /

7 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

satosa-users July 2019