Attendees
Heather, Ivan, JohnP, Hannah Sebuliba, Johan
Regrets:
Scott, Roland
0 - Agenda bash
New Incubator - GEANT has a program where they sponsor a team to do a project that will serve as the basis to do something bigger. Niels suggested that we use the incubator program to set up a matrix of idpy projects to determine if the communication is working properly between all the different services. Ivan will send the suggestion about this to the list. The trick will be that it's often the configuration, not the software itself, that causes the problems. The matrix would need to be more about common configurations rather than just a default deployment, but it's an open question as to how what configurations we would choose. Ivan will follow up with initial meetings to see if this can be applied to us, but this won't be a high priority and someone else may want to eventually take point.
What if we started limiting support to specific profiles of configuration? The challenge with that is we don't really know all the ways that idpy apps and libraries are used. If we do go down this path, we'll need to document carefully because it will impact what we test for, what issues are valid, etc.
1 - Governance policy updates
Board has approved the updated policies, with a few minor changes (specifying ideal test coverage at 80%, requesting that the common incident handling policy is followed)
https://github.com/IdentityPython/Governance
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
No update
b. Satosa - https://github.com/IdentityPython/SATOSA
New release expected soon. We have a new contributor to the code base.
• https://github.com/IdentityPython/SATOSA/pull/354 - will be a breaking change for OIDC plugins; see documentation
• will be some other updates to various microservices
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Has just about finished the code that will let us update to new algorithms. Ivan will merge the PR (https://github.com/IdentityPython/pysaml2/pull/778) soon, set up some new GitHub actions (first time we'll be using these) and cut a new release.
Several people are working in the same part of the code, so we need to come to some conclusion on the crypto pieces. Ivan will be reviewing the different PRs and figuring out what and how to merge the ideas if not the exact code.
• https://github.com/IdentityPython/pysaml2/pull/781
• https://github.com/IdentityPython/pysaml2/pull/660
• https://github.com/IdentityPython/pysaml2/pull/787
Test Suite under development by Giuseppe: https://github.com/peppelinux/spid-sp-test. This could serve as a way to start doing integration tests. The tests make certain assumptions, which feeds the conversation about having specific support profiles (see Agenda Bash - New Incubator discussion).
Next up for pySAML2:
1. More work around signing and encryption to add lists of allowed/disallowed algorithms
2. Creating a python-based signing/encryption library (replacing xmlsec1)
3. Changing the base of pySAML2 using a proper parser and possibly using types (idea introduced by Davide Brunato)
d. pyFF - https://github.com/IdentityPython/pyFF
No update
Thanks! Heather
Attendees:
Ivan, Giuseppe, Heather, Hannah Sebuliba, John P, Roland
Regrets:
Scott
0 - Agenda bash
1 - Governance policy updates
• Joseph has transferred the djangosaml2 to the GitHub repository page
• idpy Board meeting next Thursday
2 - GitHub review
b. Satosa - https://github.com/IdentityPython/SATOSA
Merged a few things, but nothing major. We have a new person contributing to the code based, contributing new microservices and working with the OIDC backend.
• https://github.com/IdentityPython/SATOSA/pull/355 - feat: add support for the Scoping element and RequesterID in SAML2 backend
Question re: does SATOSA have support for SLO on the roadmap? Not right now, though Ivan recognizes we need to look at this. See also https://github.com/IdentityPython/SATOSA/issues/211. There are different types and methods to initiate logout, but it all comes down to a best-effort activity for the user.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Ivan has been looking at the PRs for both pySAML2 and Satosa and have merged some.
• https://github.com/IdentityPython/pysaml2/pull/757 - Handle all types of ACS endpoint specifications
• https://github.com/IdentityPython/pysaml2/pull/779 - Raise SAMLError on failure to parse a metadata file
• https://github.com/IdentityPython/pysaml2/pull/763 - Invalid Destination URL Exception Handling
• https://github.com/IdentityPython/pysaml2/pull/766 - InvalidAssertion Exception
• https://github.com/IdentityPython/pysaml2/pull/772 - Response with unvalued AudienceRestriction (Condition) Handling
• https://github.com/IdentityPython/pysaml2/pull/762 - Minor bug fix to metadata function in example IdP
Changes still under discussion:
• https://github.com/IdentityPython/pysaml2/pull/778 - [Strengthen Encryption] PySAML2 Encrypted Assertions now works with Shibboleth SP 3 - note that we will not be using RSA, but instead using RSA OAEP as generally recommended. Switching to RSA OAEP is a breaking change.
The main thing we need to work on more are the encryption pieces. More work needs to be done around signing, and how we configure metadata and internal processing about which algorithms we accept. This is close to being wrapped up, and then Ivan will focus on how to encrypt the payloads. Right now we depend on xmlsec1, writing files, etc. Given our recent security issues were a result of how xmlsec1 behaves, this whole set of functionality must change. We have all the pieces we need to do this ourselves, without relying on a library like xmlsec1. We can focus purely on something that meets the need and requirements of SAML.
eIDAS requires specific algorithms be supported, and those algorithms are not supported by xmlsec1. This is another issue for us. This will be a new security backend for pySAML2, and xmlsec1 will be kept as an option.
What about pyXMLsecurity (https://github.com/IdentityPython/pyXMLSecurity)? This is a side project. It was initially planned to be used by pySAML2 but it was never extended to include all the operations expected. It support signing and verification, but there is no encryption/decryption support, and even the signing needs more work. The code is messy. Some of Ivan's new ideas, though, will be taken from here (e.g., low level processes). We don't know if this code is being used by anyone in production.
d. pyFF - https://github.com/IdentityPython/pyFF
No update
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Roland is waiting for Nikos to sign off on the OIDC endpoint. When Nikos signs off, the project will start using that new code and Roland will need to update the documentation.
The OIDF has raised the fee for doing certification. They continue to discuss whether open source implementations should be able to go through certification, the challenge being how to define "open source". OIDF is willing to waive the fee for Identity Python. Roland will not try to certify for FAPI (Finance) unless we hear of a financial institution that uses our code that would require it.
The OIDC Federation spec is an implementer's draft right now. Roland is working with Mike Jones to edit some pieces, but it is largely stable. Hoping to get the vote kicked off to bring it up to a standard level soon (next month or so).
3 - AOB
Reminder: Daylight Saving Time clock skew about to start. Our next call will be March 23 @ 13:00 UTC.
Thanks! Heather
Attendees:
Ivan, Giuseppe, Roland, Scott, Heather, JohnP
1 - Governance policy updates
• no comment on the PR; next step to send these to the Board for approval
• djangosaml2 status - need to make sure the maintainers are good with the revised governance policies
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Roland and team are still working on the session management system. Particular thanks to Nikos for the hours he's put into this.
Roland is looking at dpop (https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/) which is a way to bind tokens to clients so a resource server can check that the token came from the client that received the token. It uses http headers and puts a signed json web token in it. The source code can't do much with http headers, so some additional functionality is required. Will there be a signature on the header? It's using Proof of Possession. The json web token has as the payload a representation fo the public key that the token was signed with.
b. Satosa - https://github.com/IdentityPython/SATOSA
Travis-ci (https://www.travis-ci.com/, a hosted service used during integration testing) is still not working properly. Ivan has reached out to the platform maintainers, but has not heard back.
Doing work in eduTEAMS, including different errors for users. Goal is to catch the errors (since we know about them) and exposing new exception types so we can handle the errors better. Will introduce a handler for the errors (a module that the admins can write to make explicit what they want to have happen with a given defined error). This will also result in better logging.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
See discussions on idpy #saml slack channel.
Ivan is working on the encryption and signature parts. This is the priority for pySAML2 for now.
d. pyFF - https://github.com/IdentityPython/pyFF
3 - AOB
• Python version support - Roland received a PR from a developer of cryptJWT, and in that included deprecating Python 3.6 because there is an EOL on 3.6 coming up at the end of this year. When we know of an official EOL for any components in our project, when should we deprecate it out of our projects? Before it reaches EOL, or shortly after?
• Scott suggests we try to wait on the timeline to transition of 3.6 until 4Q 2021; some active platforms (NIAID/NIH) out there depend heavily on Centos7, and they can get python 3.6 from that associated repository. Getting python 3.7, however, is harder. They are in process to transitioning to a docker-based architecture, but it will take them several months to get there.
• Why do we need to deprecate 3.6? Are we blocked on functionality in the language? Deprecating means we're not going to test it or patch against that version. We've also talked about basing our code on what's in Debian stable, and that Debian comes with python 3.7. We should have a plan on the transition and be prepared to notify users (announcing on Slack and the mailing list).
• Next steps: we will start the communications process in September/October to let people know this is going to happen, announce in a couple of releases, then make it official
Thanks! Heather
Attendees:
Ivan, Giuseppe, Johan, John, Scott, Heather, Davide Brunato
Agenda:
0 - Agenda bash
idpy funding - how are we funded? entirely in-kind work. It's a big lift to start a fundraising project, and to find people who can write the quality of code we need are hard to find. We would need something like two FTE for a couple of years.
• Sunet will be hiring a new person, and there will be some more dedicated time from that person
1 - Governance policy updates
a. https://github.com/IdentityPython/Governance/pull/7
Added clarity to what we're expecting with regards to adding and supporting projects within idpy, as discussed on previous calls (e.g., semver, change logs, etc). Group is encouraged to review these
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
A big merge request is coming re: session management, which will effect the whole library.
b. Satosa - https://github.com/IdentityPython/SATOSA
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Hannah is working on the readthedocs for pySAML2. Expect to see a pull request soon.
Had discussions on slack on how to restructure the core of pySAML2; see thread starting 30 January 2021. Ivan suggests working on this in two phase: change how we consume XML docs, and how we produce XML docs.
• for the consuming side, changing this is fairly easy, and some of this was done with the security changes via xmlschema.
• for the producing side, the latest version of xmlschema has some ability to help us here. We also can consider xsdata that reads schema and creates classes.
• xsdata + pydantic would be a great combination of features to support the necessary validation for the objects we build.
• Ivan will post on slack example use cases for what would be most useful.
• There is some concern whether not using bindings will reduce the flexibility of the objects and the way we can work with them.
• Can xmlschema work alongside xsdata classes? We would be able to use xsdata as a converter. Uncertain; need to test.
i. https://xsdata.readthedocs.io
d. pyFF - https://github.com/IdentityPython/pyFF
3 - AOB
Thanks! Heather
Attendees:
Stephen Schwichtenberg, Ivan, Christos, John P, Heather, Johan, Scott
Regrets:
Roland
Notes:
0 - Agenda bash
1 - Security Vulnerability - review
looking for feedback on how we handled the announcements.
Ivan made a private incident-response team to review the patches, but not sure that many people tested. eduTeams did some testing after about a week and found a few issues coming from the new patches. The new code had test cases, but they can't account for everything. We need better community testing.
We made the CVEs public on Jan 20, created a new release for pySAML2, and sent out an announcement. Also updated Satosa, including a new docker image. We also have a new web page: https://idpy.org/security/.
Feedback
• We announced the new release would be available before we actually had the release. That put some time strain on things that rushed the testing and development. We underestimated the complexity, so suggest we needed to have the testing done first, before we make an announcement. There were also requests for early access; how do we answer questions like that? Who gets early access, and who doesn't? Giving a heads' up to the ops people is good, but better to have the patches ready first.
• The clients who had been keeping themselves up to date had the least issues in handling the update. The ones that are still on old versions had quite a few more challenges (custom microservices no longer worked, configs had to change, etc). Standard devops best practice makes responding to this kind of issue much easier.
• In terms of curating a list of early testers, the people who show up and contribute to the community are the ones that should get premium access.
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Tuesday, 26 January 2021, 14:00 UTC
BlueJeans: https://bluejeans.com/444837426?src=join_info
Regrets:
Roland
Agenda:
0 - Agenda bash
1 - Security Vulnerability - review
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
b. Satosa - https://github.com/IdentityPython/SATOSA
c. pySAML2 - https://github.com/IdentityPython/pysaml2
d. pyFF - https://github.com/IdentityPython/pyFF
3 - Normalizing idpy projects (see email from Ivan, "Subject: [idpy-discuss] Normalizing across all projects”, 10 November 2020)
a. Extending the invitation to djangosaml2 - status?
4 - AOB
Thanks! Heather
