- Idpy-discuss - lists3.sunet.se

by hlflanagan＠sphericalcowgroup.com

FYI - I’ve submitted for a BoF at TNC20 -Heather > Begin forwarded message: > > From: TNC Organisation <tnc at geant.org> > Subject: Proposal Submission confirmation > Date: November 25, 2019 at 6:09:02 AM PST > To: Heather Flanagan <hlf at sphericalcowconsulting.com> > Reply-To: TNC Organisation <tnc at geant.org> > > Dear Heather Flanagan, > > Thank you for your submission of "idpy BoF" (BoF (Birds of a Feather meeting - 2 hours)) for TNC20, which will take place on 8-12 June 2020 in Brighton, UK. > > All submissions will be reviewed and submitters will receive notifications by the beginning of February 2020. > > If you have any questions, please do not hesitate to contact tnc at geant.org. > > We look forward to seeing you in Brighton, UK. > > Kind regards, > TNC20 Event Team > > Hoekenrode 3 > 1102 BR Amsterdam > The Netherlands > T: +31 20 530 44 88 > > Email: tnc at geant.org > Url: http://tnc20.geant.org/ >

6 years, 10 months

1
0
0 0

Idpy Dev call, 12 November 2019

by hlflanagan＠sphericalcowgroup.com

Hola a todos! As many of you will have seen from the Slack channel conversation last week, tomorrow’s call will primarily about the OIDC federation and associated libraries. Ivan is unavailable for the call; Roland will be on point to lead the discussion. BlueJeans link: https://bluejeans.com/489221749 <https://bluejeans.com/489221749> Agenda: 0. Agenda bash 1. Oidc federation 1.0 draft updates (Isn't there something usefull for us? Ignore if not) 2. GitHub review a. Oidc implementations: a.1 oidcendpoint - a.2 jwtconnect-python-oidcrp - b. Satosa - https://github.com/IdentityPython/SATOSA c. pySAML2 - https://github.com/IdentityPython/pysaml2 d. pyFF - https://github.com/IdentityPython/pyFF 3. AOB

6 years, 10 months

1
0
0 0

Rescheduling the call?

by hlflanagan＠sphericalcowgroup.com

Hola a todos! On the call on 29 October, we talked about some changes for the 12 November call. We could either: a) find someone else to run the call (Ivan is not available) b) move the call out one week (so we have a call on 19 November and then back to our usual schedule on 26 November) c) cancel the 12 November call and have our next meeting on 26 November. What are your preferences? Thanks! Heather

6 years, 10 months

4
4
0 0

Releases for pysaml2 and satosa

by ivan.kanak＠gmail.com

Hello everyone, new releases are out for pysaml2 and satosa. Check the respective changelogs: - pysaml2 is now on version v4.9.0 https://github.com/IdentityPython/pysaml2/releases/tag/v4.9.0 - and satosa is on version v4.5.0. https://github.com/IdentityPython/SATOSA/releases/tag/v4.5.0 Next versions of both will assume python 3.7 or greater. This comes in line with the latest stable Debian release - Debian 10 (a.k.a. buster) uses Python 3 "3.7.2" as the python3 executable. (Reference: https://www.debian.org/News/2019/20190706) This also means that we are starting the process to drop support for python2 for pysaml2 (satosa was always python3-only.) More releases will be coming soon for both projects as more pull requests are merged and issues are ironed out. Thanks for your contributions and patience ;-) Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

6 years, 10 months

1
0
0 0

Agenda: idpy developers call, 29 October 2019

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 29 October 2019 Time: 06:00 PT <x-apple-data-detectors://1> | 09:00 ET <x-apple-data-detectors://2> | 13:00 UTC https://bluejeans.com/489221749 <https://bluejeans.com/489221749> Agenda: 0. Agenda bash 1. GitHub review a. pySAML2 - https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2> b. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA> c. pyFF - https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF> d. … 2. AOB Thanks! Heather

6 years, 11 months

2
1
0 0

Agenda: idpy developers call, 15 October 2019

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 15 October 2018 Time: 06:00 PT <x-apple-data-detectors://1> | 09:00 ET <x-apple-data-detectors://2> | 15:00 GMT <x-apple-data-detectors://3> https://bluejeans.com/489221749 <https://bluejeans.com/489221749> Agenda: 0. Agenda bash 1. GitHub review a. pySAML2 - https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2> b. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA> c. pyFF - https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF> d. … 2. AOB Thanks! Heather

6 years, 11 months

1
0
0 0

Agenda: idpy developers call, 1 October 2019

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 1 October 2018 Time: 06:00 PT | 09:00 ET | 15:00 GMT https://bluejeans.com/489221749 Agenda: 0. Agenda bash 1. Hackathon report from NTW2019 a. Hackathon planning - 10-11 December @ Internet2 TechEx (will require TechEx registration) 2. GitHub review a. pySAML2 - https://github.com/IdentityPython/pysaml2 b. Satosa - https://github.com/IdentityPython/SATOSA c. pyFF - https://github.com/IdentityPython/pyFF d. … 3. AOB Thanks! Heather

6 years, 12 months

1
0
0 0

thiss-js Docker discovery service not clickable

by skoranda＠gmail.com

Hi, I have a pyFF deployment answering MDQ/API queries at https://mdq-dev.ligo.org/ I am using the master of today's thiss-js repository at commit 2bca90db03a3110feeaf2773e3a91598bcee1b4e. I did npm intall make docker and it generated the image thiss-js:1.0.1 I then did docker run \ -d \ --name ds \ -e BASE_URL=http://localhost:8080 \ -e COMPONENT_URL=http://localhost:8080/cta \ -e PERSISTENCE_URL=http://localhost:8080/ps \ -e MDQ_URL=https://mdq-dev.ligo.org/entities/ \ -e SEARCH_URL=https://mdq-dev.ligo.org/api/search \ -e LOGLEVEL=debug \ -p 8080:80 \ thiss-js:1.0.1 To simulate an IdP discovery flow I then browsed to http://localhost:8080/ds/index.html?entityID=https%3A%2F%2Fwiki.ligo.org%2F… The discovery page renders and I expect it would and I can type in the text box. I see the API queries going out to the pyFF MDQ service and the IdP I want to use is found and displayed as a choice. When I click on the IdP choice, however, nothing happens. The generated HTML that I am clicking on is <a class="institution identityprovider bts-dynamic-item" tabindex="0" data-href=""> <li><i class="arrow" data-fa-i2svg=""><svg class="svg-inline--fa fa-angle-right fa-w-8" aria-hidden="true" focusable="false" data-prefix="fa" data-icon="angle-right" role="img" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 512" data-fa-i2svg=""><path fill="currentColor" d="M224.3 273l-136 136c-9.4 9.4-24.6 9.4-33.9 0l-22.6-22.6c-9.4-9.4-9.4-24.6 0-33.9l96.4-96.4-96.4-96.4c-9.4-9.4-9.4-24.6 0-33.9L54.3 103c9.4-9.4 24.6-9.4 33.9 0l136 136c9.5 9.4 9.5 24.6.1 34z"></path></svg></i> <div class="d-block institution-text"> <div class="text-truncate label primary">University of Wisconsin-Milwaukee</div> <div class="text-truncate label-url secondary">uwm.edu</div> </div> </li> </a> Is there some configuration I missed for running the Docker image? I have tried both Firefox 69.0.1 and Google Chrome 77.0.3865.90 on Debian 10. Scott K P.S. Note that I reported yesterday an issue with pyFF MDQ not responding correctly when the query is the sha1 hash of an entityID. Does not being able to resolve the metadata for the SP prevent discovery from working?

7 years

2
4
0 0

thiss.io select as alias support

by martin＠surfnet.nl

Hi, I've been experimenting with thiss.io combined with pyff as mdq and tried to use the pyff "select as" construct to narrow down the list of available IdP's in the DS. It doesn't work? Pyff correctly reports a request on the ds, for alias test, but thiss.io returns a 404? pyffd[1318]: 2019-09-24 15:48:21,415 DEBUG [pyff.api:31][MainThread] handling entry=request, alias=test, path=ds I suspect this is caused by the (example) nginx conf, as the /test alias can not be served by thiss.io it is directly forwarded to pyff, bypassing the DS? server { include "mime.types"; listen 0.0.0.0:8081 default_server; location / { root /opt/thiss-js/dist; try_files $uri $uri/index.html $uri.html @mdq; } location @mdq { proxy_pass http://127.0.0.1:8083; } } But then, even if we could solve the nginx conf, thiss.io should be "alias" aware and fire the correct query on pyff. Will it? Best regards, Martin

7 years

3
9
0 0

head of pyFF master broken MDQ via sha1 hash?

by skoranda＠gmail.com

Hi, I am using today's pyFF master head, commit bbdf245ccdb0be8ce45dda8c0cef06a6d33e2755 My pipeline contains - when request: - select: - pipe: - when accept application/xml: - first - finalize: cacheDuration: PT12H validUntil: P10D - sign: key: metadata-signer.key cert: metadata-signer.crt - emit application/xml - break - when accept application/json: - discojson - emit application/json - break This query returns the XML I expect curl 'http://127.0.0.1:8080/entities/https%3A%2F%2Fwiki.ligo.org%2Fshibboleth-sp' proving that pyFF has the metadata for the entityID. But this query returns an empty <EntitiesDescriptor>: curl 'http://127.0.0.1:8080/entities/%7Bsha1%7Dff767393c6b06e8282603e9e4541ac1e87…' Note that $ python3 Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from hashlib import sha1 >>> m = sha1() >>> m.update(b'https://wiki.ligo.org/shibboleth-sp') >>> m.hexdigest() 'ff767393c6b06e8282603e9e4541ac1e878d63aa' This is problematic since thiss-js wants to use sha1 hashes to query MDQ. Is there something special I have to configure to get pyFF to accept the sha1 hash? Thanks, Scott K

7 years

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss