January 2019 - Idpy-discuss

Notes: idpy Developers call, 29 January 2019

by hlflanagan＠sphericalcowgroup.com

Attendees: Heather, Scott, Johan, Paul (I2), Ivan, Martin Regrets: Rainer, Roland 1. Project review - Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA>) Expect a new release when the pySAML2 security bugs are fixed - pySAML2 (https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2>) Security fixes added by Ivan have broken some peoples installation. Ivan will be working on resolving that today. Issues and changes discussed today: https://github.com/IdentityPython/pysaml2/issues/578 <https://github.com/IdentityPython/pysaml2/issues/578> - Don't hide xmlsec1 execution errors https://github.com/IdentityPython/pysaml2/pull/583 <https://github.com/IdentityPython/pysaml2/pull/583> - Check the xmlsec returncode https://github.com/IdentityPython/pysaml2/pull/581 <https://github.com/IdentityPython/pysaml2/pull/581> - Allow tests to pass after 2020 https://github.com/IdentityPython/pysaml2/issues/579 <https://github.com/IdentityPython/pysaml2/issues/579> - Wrong signed AuthnRequest with redirect binding https://github.com/IdentityPython/pysaml2/issues/586 <https://github.com/IdentityPython/pysaml2/issues/586> - Please don't cache MDQ responses (note - in the long term, Scott would like to see pySAML support a sophisticated metadata client, rather than having to rely on an external component. This would allow to use a python stack with as few pieces as possible. This may also mean not removing but instead fixing the cache.) (Martin) Hashing of the sub and the bloat of the id token - should the OIDC library enable putting claims in the id token (which would be difficult) or should we stick to the specs and not put claims in the id token and instead query the end point? Most OIDC libraries out there put claims in the token, since that’s what Google does. Remember we’re replacing the pyOP libraries with new ones written by Roland (possibly not in all cases, though). - pyFF (https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF>) See email from Leif 2 TIIME planning https://github.com/IdentityPython/Meetings/blob/master/TIIME-20190211 <https://github.com/IdentityPython/Meetings/blob/master/TIIME-20190211> - may end dev meeting early to have a board meeting Ivan will be adding a few agenda items How to add new members to the group (this will be both dev and board discussion)

5 years, 10 months

2
1
0 0

Agenda: idpy developers call, 8 January 2019

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 8 January 2019 Time: 14:00 UTC https://bluejeans.com/655841213 Agenda: 0. Agenda bash 1. Project review - Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA) - pySAML (https://github.com/IdentityPython/pysaml2) - pyFF (https://github.com/IdentityPython/pyFF) - Governance docs (https://github.com/IdentityPython/Governance) 2. TIIME planning - https://github.com/IdentityPython/Meetings/blob/master/TIIME-20190211 3. AOB

5 years, 10 months

4
6
0 0

python 3 compatibility and other rapid movement ahead

by leifj＠sunet.se

Folks, After standing still for a while a lot of things are starting to happen in pyFF world. I have merged a major PR (from myself) introducing python3 compatibility to pyFF. This is in large part thanks to the work that @lundberg and others did over the last few weeks to fix pyXMLSecurity. At the same time I have removed all version pins and the preferred build environment is now python3. I have updated the docker repo at github.com/SUNET/docker-pyff to reflect this. Please refer to this repo for current instructions on how to build and deploy pyFF (hint: its a lot simpler than it used to be). Over the next couple of days/week I will focus on excising the discovery code into the github.com/TheIdentitySelector/thiss-js.git repo and also merging https://github.com/IdentityPython/pyFF/pull/159 which contains the future "REST-like" API for pyFF. Cheers Leif

5 years, 10 months

2
1
0 0

mixing protocols

by skoranda＠gmail.com

Hi, My apologies because I think I have asked this before... Is this a true statement? Today with the head of the master branch for SATOSA one cannot mix protocols and have an OIDC backend and a SAML2 frontend to create an OIDC-to-SAML gateway using SATOSA. Thanks, Scott

5 years, 11 months

1
1
0 0

Unavailable

by ivan.kanak＠gmail.com

Hello everyone, I will be offline between Friday 18/1 and Tuesday 22/1. On Tuesday is our regular bi-weekly call. I am not 100% sure that I can make it on time. Would you like to have this call or should we reschedule? Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

5 years, 11 months

3
4
0 0

pyop unhashed sub

by martin＠surfnet.nl

Hi, Today I finshed an OIDC/SAML broker based on Satosa that I needed to patch for [1] but also for not hashing the OIDC sub. It turned out the OIDC RP expected the sub to map to pre-provisioned users, known by their SAML ePPN. I even suspect it expected [2] but in absence of a configured claim in id_token resorted to using the available sub. The (hardcoded) fix is easy: just configure sub public and return value in internal_data.py UserIdHasher::hash_data. Would there be any interrest in a PR to make this an option in oidc frontend conf? Then, I have two outstanding questions for IdPy. One is a formal answer to the problem outlined in [1] and the second is [2]. We would really appreciate an answer to both questions. [1] https://lists.sunet.se/pipermail/idpy-discuss/2019-January/000339.html [2] https://lists.sunet.se/pipermail/idpy-discuss/2018-December/000329.html Best regards, Martin

5 years, 11 months

1
0
0 0

Signed authnRequests on Redirect binding in pysaml/SATOSA

by martin＠surfnet.nl

Hi, Today I noticed a very strange behaviour of SATOSA SAML backend and was curious if anyone on the list could shed a light on my findings? For SURFnet's SecureID (2factor auth) service an SP needs to send a signed authnRequest on the Redirect binding of the SSO endpoint. The only setting I could find for SATOSA backend conf was authn_requests_signed: true This, however generates an enveloped signed xml messages that is dropped on the Redirect endpoint, which is against the SAML standards, which explicitly mandates the signature element to be removed and a URL request parameter Signature to be added to the request: 3.4.4.1 DEFLATE Encoding 1. Any signature on the SAML protocol message, including the <ds:Signature> XML element itself, MUST be removed 4. The signature value MUST be [...] included as a query string parameter named Signature. source: SAML-bindings-2.0-os Did I miss something in the config to enable this behaviour or is pysaml2 blatantly ignoring the standard? Best regards, Martin van Es

5 years, 11 months

1
1
0 0

Notes: idpy developers call 8 January 2018

by hlflanagan＠sphericalcowgroup.com

Attending: Heather, Scott, Christos, Ivan, Roland, Johan Regrets: Rainer Notes: 0. Agenda bash Heather will send out a new invitation with updated BlueJeans information later today. 1. Project review - Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA) Not a lot happened over the holidays. Ivan was working on items related to eduTEAMS (common internal representations for back and front ends). He also fixed some tests; we can now use the latest pytest. Ivan archived the Satosa microservices repository; will move the issues to the main Satosa repository. We will split out the microservices into their own repositories (one for each microservice). This will allow for a package per microservice, each with its own dependency. Ivan will send email how core API should work with the microservices. Ivan will go ahead and cut a release now that the microservices are set, and then will work on the PR related to eduTEAMS. One PR in particular relating to a discovery service; not quite sure what to do about this one. Roland would still like to see an OIDC front and back end. That is on the list; Ivan will reach out to Roland when that work is started. Christos asks, regarding the consent service, do we know who is using it and are there alternatives? When we discussed this in the past, there weren’t many users of this service. The only ones actually using it were SURFnet; they proposed to make a fork and maintain what they need. Main repository has been abandoned. It would be good to find out if anyone else is using it. eduTEAMS uses this for an information sharing service since they base their access on Legitimate Interest, not a consent capturing service. - pySAML2 (https://github.com/IdentityPython/pysaml2) A new pySAML2 will be coming out soon; this is related to a security issue - see https://github.com/IdentityPython/pysaml2/issues/578 The issue is with how XMLsec does not check its data. When an error is encountered with XMLsec, we need to add an exception in how that’s handled. Ivan has made a few changes and created a test that shows some errors we were missing when XMLsec threw an error. Ivan has not pushed a final fix yet, but there are instructions on how to work around this. Will push a small fix for now, and then we’ll consider further changes to the code. Johan has read the analysis and agrees this isn’t exploitable; that it isn’t exploitable is only by luck. Issue 579 relates to something reported out of eduTEAMS. This relates to yet another issue - hw we define the digest and signing algorithm we use. We need to make the default signing algorithm something other than SHA1 and make that a choice in configuration. - pyFF (https://github.com/IdentityPython/pyFF) Leif is still working on refactoring the code. Need to get an update from him out to the list. How much will this refactoring change how the code is deployed today? How will is relate to Satosa? The architecture is changing significantly, but from the perspective of Satosa, nothing changes. There will be an MDQ service available to get the metadata, and from a discovery standpoint there will be a backend responding to requests and you can run whatever front end you want (there will be a default available). - Governance docs (https://github.com/IdentityPython/Governance) Board is meeting tomorrow; we hope to make more progress on deciding about whether a CLA is required and the IPR home. 2. TIIME planning - https://github.com/IdentityPython/Meetings/blob/master/TIIME-20190211 Note that Ivan will arrive about 11:30am (meeting officially starts at 11:00). Current attendees: Ivan, Johan, Scott. Christos is tentative. 3. AOB

5 years, 11 months

2
1
0 0

Calendar invitation sent for the idpy Developers call

by hlflanagan＠sphericalcowgroup.com

Hola a todos! I've sent out the calendar invite to the usual suspects for the idpy developers call. If you did not receive an invitation and want one, please let me know. -Heather

5 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss January 2019