September 2020 - Idpy-discuss

Agenda: idpy Developers call, 16 May 2019

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 16 May 2018 Time: 06:00 PT | 09:00 ET | 15:00 GMT https://bluejeans.com/163562895 Agenda: 0. Agenda bash 1. Governance update a. Commons Conservancy b. Note Well and licensing by repository vs license in each file 2. Code releases - speed vs stability? a. Resources (do we have enough if we use them well? If not, what are we asking the idpy Board for?) 3. GitHub review a. pySAML2 - https://github.com/IdentityPython/pysaml2 b. Satosa - https://github.com/IdentityPython/SATOSA c. pyFF - https://github.com/IdentityPython/pyFF d. ... 4. AOB Thanks! Heather

2 weeks, 2 days

7
9
0 0

Project licensing within IdentityPython

by ivan.kanak＠gmail.com

Hi all, being part of Commons Conservancy brought up yet another subject, which is whether we should add a header with license information in every file in the projects under idpy. This is not something done in an abstract way, there is a specific format modelling this information (see https://spdx.org/ and https://reuse.software/ - more specifically https://reuse.software/practices/2.0/) Still, I find it problematic. We want to open up the question to the wider community and consider their thoughts on this. The forwarded message below is discussing this subject. You can see the question we posed, the answer we got and my comments. Feel free to tell us what you think on this. ---------- Forwarded message --------- Date: Thu, 16 May 2019 at 09:56 > ---------- Forwarded message ---------- > Date: May 8, 2019, 8:15 AM -0700 > > > Why does CC think having a single license file per project is > > insufficient? Our thought is that if we can avoid adding a header to > > every single file, that would be nice, esp. given we already have this > > info in the license file and we have the Note Well. > > > this is not just our opinion, but something that is an industry and > community standard for legal compliance these days. When companies like > Siemens, Samsung or Honeywell use some code in one of the hundreds or > thousands of devices and systems in their product line, they need to be > able to provide the correct license and a download of the exact version. > This means machine readability too. > I've actually observed the opposite of that. Communities abandon the "license in every file" model, and just use a single LICENSE file in the root of the project. The LICENSE file contains license information, that is, it is not a single license but it has exception sections and so on. > To quote from https://reuse.software/practices/2.0/ : > > Scroll to the section "2. Include a copyright notice and license in each > file"... > > "Source code files are often reused across multiple projects, taken from > their origin and repurposed, or otherwise end up in repositories where > they are separate from its origin. You should therefore ensure that all > files in your project have a comment header that convey that file’s > copyright and license information: Who are the copyright holders and > under which license(s) do they release the file? > Continuing from above, the standardization of package-management formats and tools has helped exactly with that: to avoid distribution of single files, and instead provide packages and modules. It is bad practice and considered a hack to copy files. Nobody liked that model and everyone is moving away; it is unstructured, it becomes unmanageable and it will cause problems. > It is highly recommended that you keep the format of these headers > consistent across your files. It is important, however, that you do not > remove any information from headers in files of which you are not the > sole author. > > You must convey the license information of your source code file in a > standardised way, so that computers can interpret it. You can do this > with an SPDX-License-Identifier tag followed by an SPDX expression > defined by the SPDX specifications." > > (the text goes on for a while after this, to clarify the point but this > is the basic gist of it) > > There is a nice Python tool to check: > > https://github.com/fsfe/reuse-tool > > I hope this makes sense > Well, it does not make complete sense. We're talking about licensing a project. A project is not just code; there are data files (html, xml, yaml, json files), binary files (archives/zip, images, audio, video, etc), text files (configs, ini-files, etc) all "not-code". How do you mark those files? Does the LICENSE file need a license-header? The json format does not define comments, how do you add a header there? If a binary file does not get a license header, why should a file with code get one? I would expect there to be a way to have the needed information unified. If the files themselves cannot provide this information it has to be external; thus the LICENSE file. If someone is worried about somebody else re-using single files that do not have license information (a python file, a png image, etc) there is really nothing you can do (the DRM industry has been trying to solve for a long time; and still your best bet is "social DRM"). Since, we're developing on open source with a permissive license, even if someone does that, should we be happy that someone is actually using what we built or sad that the files they copied did not have a license header? And if they include the license information of that copied file in their project's LICENSE file, is this solved? Having pointed these contradictions, I am thinking that the "license in every file" model seems to be a step backwards. It is introducing overhead and does not really solve the problem, while at the same time it enables a culture of bad practice (copying files around). Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

2 months, 2 weeks

5
4
0 0

PySaml2 v5.0.0 - Security release

by ivan.kanak＠gmail.com

Hello everyone, there has been a report on incident-response at idpy.org about a security issue in PySaml2. Alexey Sintsov and Yuri Goltsev from HERE Technologies reached out and reported a XML Signature Wrapping (XSW) vulnerability. The issue affects responses with signed assertions. PySaml2 can be tricked to think that an assertion had been signed and use the assertion information, when in reality the Signature points to another part of the xml document that is controlled by another party. The issue was assigned CVE-2020-5390 and is now fixed in the latest pysaml2 release. The relevant code commit that fixes is the issue: https://github.com/IdentityPython/pysaml2/commit/5e9d5acbcd8ae45c4e736ac521… Release v5.0.0 contains more changes, including: - Add freshness period feature for MetaDataMDX - Fix ipv6 validation to accommodate for addresses with brackets - Fix xmlsec temporary files deletions - Add method to get supported algorithms from metadata - Add mdstore method to extract assurance certifications - Add mdstore method to extract contact_person data - Start dropping python2 support Pointers to the release with changelog and more information, below: - the relevant release commit: https://github.com/IdentityPython/pysaml2/commit/f27c7e7a7010f83380566a219f… - the github release: https://github.com/IdentityPython/pysaml2/releases/tag/v5.0.0 - the pypi package: https://pypi.org/project/pysaml2/5.0.0/ + + + + + + + + In more detail, regarding the XSW vulnerability: libxml2 follows the xmldsig-core specification. The xmldsig specification is way too general. saml-core reuses the xmldsig specification, but constrains it to use of specific facilities. The implementation of the SAML specification is responsible to enforce those constraints. libxml2/xmlsec1 are not aware of those constraints and thus process the document based on the full/general xmldsig rules. What is happening is the following: - xmldsig-core allows the signature-information and the data that was signed to be in different places. This works by setting the URI attribute of the Reference element. The URI attribute contains an optional identifier of the object being signed. (see "4.4.3 The Reference Element" -- https://www.w3.org/TR/xmldsig-core1/#sec-Reference) This identifier is actually a pointer that can be defined in many different ways; from XPath expressions that need to be executed(!), to a full URL that should be fetched(!) in order to recalculate the signature. - saml-core section "5.4 XML Signature Profile" defines constrains on the xmldsig-core facilities. It explicitly dictates that enveloped signatures are the only signatures allowed. This mean that: * Assertion/RequestType/ResponseType elements must have an ID attribute * signatures must have a single Reference element * the Reference element must have a URI attribute * the URI attribute contains an anchor * the anchor points to the enclosing element's ID attribute xmlsec1 does the right thing - it follows the reference URI pointer and validates the assertion. But, the pointer points to an assertion in another part of the document; not the assertion in which the signature is embedded/enveloped. SAML processing thinks that the signature is fine (that's what xmlsec1 said), and gets the assertion data from the assertion that contains the signature - but that assertion was never validated. The issue is that pysaml2 does not enforce the constrains on the signature validation facilities of xmldsig-core, that the saml-core spec defines. The solution is simple; all we need is to make sure that assertions with signatures (1) contain one reference element that (2) has a URI attribute (3) that is an anchor that (4) points to the assertion in which the signature is embedded. If those conditions are met then we're good, otherwise we should fail the verification. -- Ivan c00kiemon5ter Kanakarakis >:3

2 months, 2 weeks

2
1
0 0

pyFF: Pipes for additional output formats

by rainer＠hoerbe.at

Hi Leif, I added 2 pipes to buildin.py: - publish_html creates static HTML views of IDPs and SPs, using XSLT based on Peter Schober’s alternative to MET; - publish_split: similar to store, but added validUntil and creates signed XML-file per EntityDescriptor. This can be consumed dynamically by ADFS in an IDP role. I put it directly into buildin.py because it shares some code with the sign pipe. Is this viable from your PoV - if yes, I would make an PR. Cheers, Rainer

6 months, 4 weeks

3
2
0 0

Notes: idpy dev call, 29 September 2020

by hlflanagan＠sphericalcowgroup.com

Attendees: Ivan, Matthew, Heather, Hannah, John P, Giuseppe Regrets: Scott 1 - Status of documentation Hannah Sebulibah will be meeting with Ivan to figure out where to start on documentation. Will likely start from the current configuration, which will help with cleaning up existing options and fixing the defaults. The API will also need help, but that’s a much bigger project and Ivan needs to do some work first. Scott has also started creating issues with where he wants to work on items. pySAML2 has a readthedocs connection, and we need to reorganize the top-level headers. What’s there is mostly about the configuration options, and it is missing material. We could also use the minimal working example of an IdP; Matthew has a gist about this. Satosa does not have a readthedocs connection; nothing generates documentation. Readthedocs can use markdown, which will be less work on our side. Ivan will also be updating the architecture docs, esp. around the middleware. Hasn’t gotten to that yet. 2 - GitHub review a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Recent focus in GitHub has been on oidcendpoint. The people involved in the OIDC project are debating frequent small releases vs larger, more complete releases with more thorough testing approx. once a month. When something is decided here, we should likely have the same policies across all the projects. We can also focus on pre-releases. A goal is to have automated testing and release with each tag. Suggest we focus on following the change log format guidelines as here: https://keepachangelog.com/ Roland is working on a new session back-end. There is some concern that this may result in a breaking change. b. Satosa - https://github.com/IdentityPython/SATOSA Memory leak still a mystery. Should probably have its own key manager that is shared between its front ends and back ends. We have some merge requests, mainly around documentation, with a bit about the plop front end. c. pySAML2 - https://github.com/IdentityPython/pysaml2 Will be working on automated pre-releases. Have been updating based on current issue list and some PRs. See: • https://github.com/IdentityPython/pysaml2/issues/720#issuecomment-700694146 • https://github.com/IdentityPython/pysaml2/pull/727 - logout response location • https://github.com/IdentityPython/pysaml2/pull/728 - logout response location • https://github.com/IdentityPython/pysaml2/pull/704 - default name format • https://github.com/IdentityPython/pysaml2/pull/721 - Increase key size in demo key generation (note this is probably still too small; proper fix is to switch algorithms • See also: https://github.com/IdentityPython/pysaml2/issues/712 to support switching algorithms • https://github.com/IdentityPython/pysaml2/pull/597 - needs to be expanded to include enforcement • Using a key manager would make handling keys easier, but it is not a priority Priority list: • Make algorithms configurable, enforcing the policies • Getting away from xmlsec1 and instead working in memory. Expect we will switch to lxml. Thanks! Heather

5 years, 1 month

1
0
0 0

djangosaml2

by giuseppe.demarco＠unical.it

Hello everybody, As you may have guessed from the subject of this email, I have the pleasure of presenting here djangosaml2, in anticipation of its migration to Identity Python. In CC Jozef Knaperek, former contributor of pysaml2 and person who from 2016 to date has maintained the fork of this project, now hosted in the personal github, which today has a fair audience and satisfaction within the Django community. Here is: https://github.com/knaperek/djangosaml2 As is evident, djangosaml2 is an application designed for Django Framework, written above pysaml2 that presents closely related goals to this. This is why we believe that bringing djangosaml2 to idpy can be quite natural, and if we want it also advantageous, for the possibility of increasing its community. Currently the project is published on Pypi and the version release policy, and acceptance of contributions, depends on validating the code by running unit tests (Tox over Github actions). The coverage of djangosaml2 is currently less than 80% in the v0.40.1 but higher than 90% for the v1.0.0 version (see branch of the same name). The latter is in the process of being released and it might be a good opportunity to release it directly within idpy. The versions from v0.19.0 to v1.0.0 were made possible by a great enthusiasm, which arose within its community, manifested following the first interactions for the requalification of the project, as regards the feedback offered both in the issues and in the PR pending. Having given so much trust activated several contributors in a relatively short time makes us optimistic about the general resilience of the project, such as to think about the good health of its community and not least the possibility that this project could hopefully continue to live on external contributions only. In any case, the people that are glad to present here djangosaml2, for whom we undertake the commitment of a management over time, are Me and Knaperek. I know that we have not written everything but rather we fear we have written too much. We are available to answer in this thread on further organizational and managerial aspects of the project. Sure of your kind reply, we greet you -- ____________________ Dott. Giuseppe De Marco CENTRO ICT DI ATENEO University of Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco at unical.it -- ------------------------------------------------------------------------------------------------------------------ Il banner è generato automaticamente dal servizio di posta elettronica dell'Università della Calabria <https://www.unical.it/portale/portaltemplates/view/view.cfm?100061>

5 years, 1 month

3
2
0 0

NOtes: idpy dev call, 15 September 2020

by hlflanagan＠sphericalcowgroup.com

Attending: Heather, Ivan, Hannah Sebuliba, Scott, Roland, Matthew, John P, Giuseppe Notes 1 - Status of architecture documentation Ivan promises to write more down. Heather will continue to nag him until he does. Has continue thinking about the middleware, and is planning on some restructuring and clarification of the Satosa docs. We had collected use cases in the wiki (https://github.com/IdentityPython/SATOSA/wiki) and we also spoke about setting up docker containers to demonstrate those use cases. This is something others could do; if interested, please reach out to Ivan. Also on the list, better documentation for the API which will serve as groundwork for future changes. We are using readthedocs for pySAML2 (see https://pysaml2.readthedocs.io/) but it focuses on the configuration options; needs more. Team is encouraged to add a GitHub issue for sections of the documentation they are working on so we can keep track of what’s being created. Scott will take a first cut at the pySAML2 top level documentation, and will then write docs on how to spin up a minimal working example of IdP. Matthew will submit his manual install of Satosa documentation: https://gist.github.com/xenophonf/22d0ec836005040a9f7c7bb80b183eda. There is also a strong argument for shifting where we can to a Document Driven Development model, writing the documentation first, share it with others, then write the code. 2 - Potential new project for idpy - status? a. https://github.com/knaperek/djangosaml2 - Giuseppe has sent an email to the list; Roland has indicated support. Heather will take this to the Board. This is linked to pySAML2. Having a project that directly uses pySAML2 that allow people to quickly set up an IdP is a good way to help direct usability improvements for pySAML2. 3 - GitHub review a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Roland is preparing an issue around session management with the oidcendpoint. He is writing docs on how it should work, and then will work on the code. Ivan is working on CryptoJWK and will add a new CLI for the ‘use’ flag. b. Satosa - https://github.com/IdentityPython/SATOSA Memory leak is still a mystery. This may actually be a problem with gunicorn. c. pySAML2 - https://github.com/IdentityPython/pysaml2 Giuseppe went through the open issues, closing several and making notes on others. New merges: documentation; changed the default re: signatures; removed all the assertion calls. Looking at replacing the calls to xmlsec1 and doing the same action in memory. Ivan has not yet pu shed the changes for the default algorithms. Will switch to SHA-512. Thanks! Heather

5 years, 1 month

2
2
0 0

Looking for volunteers: documentation

by hlflanagan＠sphericalcowgroup.com

Hola a todos! I want to highlight something from our meeting notes today: the need for more documentation. Everyone is encouraged to add a GitHub issue for sections of the documentation they are working on so we can keep track of what’s being created. Scott will take a first cut at the pySAML2 top level documentation, and will then write docs on how to spin up a minimal working example of IdP. Matthew will submit his manual install of Satosa documentation: https://gist.github.com/xenophonf/22d0ec836005040a9f7c7bb80b183eda. Ivan will be working on improving the documentation for the APIs, but that can certain use some assistance. If you are willing to spend a bit of time on this, the work would be most gratefully received! Thanks! Heather

5 years, 1 month

1
0
0 0

Notes: idpy dev call, 1 September 2020

by hlflanagan＠sphericalcowgroup.com

Attending: Johan, Heather, Ivan, Hannah Sebuliba, Scott, John, Christos Regrets: Giuseppe Notes 1 - Status of architecture documentation No update since the last call. For architecture in general, Ivan will be adding some patches for the middleware idea. The configuration will be part of the middleware; this will not be a breaking change. Also has some additional ideas to wrap parts of the applications (e.g., what we do with the micro services). This would allow easier to extend the micro services. 2 - Potential new project for idpy - status? a. https://github.com/knaperek/djangosaml2 Notes from Giuseppe: djangosaml2 Jozef Knaperek (the current repository owner) expressed a favorable opinion for the migration to idpy. I lost him during the holidays but it's probably right that it was! Watching djangosaml2's contributors we can see how many guys contributed in it and also in pysaml2. I think that this migration would be quite natural for many aspects, one of these is the opportunity to extend its community, abandoning the position of "mantainance fork" moving into a more proper and authoritative space. For those who do not know djangosaml2 this is the integration of pysaml2 in Django Framework, it help us creating a SAML2 SP in the full respect of pysaml2 approach. I am sure you have already given it a look. The latter commits have handled a SameSite cookie workaround, similar to which already seen in SATOSA and we are getting ready for a major release (v1.0.0) with a general code refactor (ClassView) and a better code coverage (>89%). v1.0.0 would be a LTS release and probably we'll have a RC for some months before do that. v1.0.0 would have also pysaml2 >=v6.1.0 as dependencies and we're facing pysaml2's breaking changes regarding this. Finally, I'm only a repository admin that are driving djangosaml2 best I can and, at last but not least, a real stakeholder, because I largely use it in my production contexts. 3 - GitHub review a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Notes from Giuseppe: I didn't still produced a debate in #oidc channel, but if I were did it I'd ask about the default policy that oidcendpoint have, regarding the requested scope against the supported or availables, for each RP. In that issue I tried to describe my (usually coloured) experience: https://github.com/IdentityPython/oidcendpoint/issues/73 The goal of this debate would be the possibility to configure the default behaviour (policy) in oidcsession, through oidcendpoint global configuration, that will let each platform administrator decide how to handle the release of unavailable or unallowed scopes. That's a reference for this: https://github.com/IdentityPython/JWTConnect-Python-OidcService/blob/51df9e… Notes from Ivan: There has been a bug in one of the underlying libraries for ECC crypto in the OIDC endpoints. It is not handling exceptions well. It is fixed, but there is not a release yet. When there is a release, need to force the use of the patch. b. Satosa - https://github.com/IdentityPython/SATOSA Ivan is reviewing current issues to come back up to speed. Mostly working on middleware to add flexibility to what we do. Ivan is considering the issue of multiple key descriptors - how can we define and coordinate keys? Currently the configuration is messy. • See also: https://github.com/IdentityPython/SATOSA/issues/334 Merge requests under consideration: • https://github.com/IdentityPython/SATOSA/pull/332 - dynamic requested attributes. Will be incorporated soon. • https://github.com/IdentityPython/SATOSA/pull/231 - unsolicited front end work Will just merge changes as long as they are not breaking changes. All breaking changes will be held and done in one release. c. pySAML2 - https://github.com/IdentityPython/pysaml2 Potential memory leak. Ivan has been using a function trace library to find this (https://functiontrace.com/) It could not follow the forks or threads that were created, but there is a new release of the software that should be able to do that now. eduTeams has a test environment that has a test environment that Ivan will use to continue to track this issue down. Several pending merge requests: • https://github.com/IdentityPython/pysaml2/pull/711 - request signing. Very simple, should go through • https://github.com/IdentityPython/pysaml2/pull/704 - Assumed name format for different attribute elements. The spec dictates that, by default if no format is set, it should be unspecified, which is not what we’re doing. This is a both a breaking change and a fix. This PR also points to https://github.com/IdentityPython/pysaml2/issues/601. • https://github.com/IdentityPython/pysaml2/pull/665 - how temp files work on Windows. Named temp files don’t work correctly on Windows. We need to wrap this in our own class/structure and detect when we’re using Windows and do things on our own on that system. We can either fix this or not use these files at all (doing these operations in memory), but the library that provides the bindings only has bindings for signing not encryption. • https://github.com/IdentityPython/pysaml2/pull/660 - allows multiple certificate files. Ivan will be making some changes to the code. • https://github.com/IdentityPython/pysaml2/pull/645 and https://github.com/IdentityPython/pysaml2/pull/628 - need to change the default algorithms and make them configurable. Will not support MD5 at all. It is easy to display what we support but harder to do internally. These are still a work in progress. • See also: https://github.com/IdentityPython/pysaml2/issues/712 - the user is using ECC keys for the signing, but internally we assume RSA keys d. pyFF - https://github.com/IdentityPython/pyFF 4 - AOB Next call: 15 September 2020 Thanks! Heather

5 years, 2 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss September 2020