March 2020 - Idpy-discuss - lists3.sunet.se

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

5 months, 1 week

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

7 months, 1 week

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

7 months, 1 week

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

11 months, 2 weeks

3
2
0 0

Notes: idpy Developers call, 31 March 2020

by hlflanagan＠sphericalcowgroup.com

Attendees: Christos, Heather, Johan, Scott, Ivan, Roland, John P, Hannah Agenda: 0 - Agenda bash 1 - GitHub review a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) General maintenance of code, otherwise pretty stable. Suggest basing the API on https://www.sqlalchemy.org/ which should make connecting to a database much easier. b. Satosa - https://github.com/IdentityPython/SATOSA and pySAML2 - https://github.com/IdentityPython/pysaml2 Giuseppe’s lxc container. We are now creating multiple docker images when we create things in the docker repository. If there is a new version, we tag it, and if it’s the master branch, we tag it. But we always know what triggered building the image. If people want their own microservices in docker images, they need to build their own images. Ivan will build an image that contains all the microservices we have in the repository, but anything past that people will need to build their own. Why build docker images at all? It helps deployers, and may bootstrap production. We could also create a dev-type image. Suggest we talk to the folks at Internet2 (Chris Hubing, Paul Caskey) about the TIER/Trusted Access Platform. See https://github.com/Internet2/comanage-registry-docker/blob/master/docs/simp… as an example. Ivan has merged the PR for new SAML syntax. d. pyFF - https://github.com/IdentityPython/pyFF See roadmap in the repository 3 - AOB • Possible memory leak with the LDAP attribute store - Scott has a few containers running (simple Satosa Proxies) that after running for 4 months that grew to 1Gb in memory. Restarting the worker process brought them back to normal. Christos is running a very old version of the LDAP attribute store and not seeing the same behavior. Ivan’s guess is that this is about how it’s handling connections. Thanks! Heather

6 years

1
0
0 0

Reminder: idpy dev call, 31 March 2020

by hlflanagan＠sphericalcowgroup.com

And finally, the two-week DST mismatch between Europe and the US has finished! The call should be back to its normal time on your calendars. BlueJeans: https://bluejeans.com/567481057 Agenda: 0 - Agenda bash 1 - 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 - AOB Thanks! Heather

6 years

1
0
0 0

Notes: idpy dev call, 17 March 2020

by hlflanagan＠sphericalcowgroup.com

(Call should be back to the regular time by March 31st) Attendees Ivan, Heather, Scott K, John P, Hannah Sebuliba 0 - Agenda bash 1 - GitHub review a. Satosa - https://github.com/IdentityPython/SATOSA Ivan has made some commits on Satosa. Some of them are breaking changes (removing deprecated option). The next release will be a breaking release. Have also added some things around logging. See example files, the proxy.conf has new options around logging ( https://github.com/IdentityPython/SATOSA/blob/master/example/proxy_conf.yam…) Recommendation, though, is to leave as is and set the log level, and define at the service level where the log should be. Also can now query Satosa during run time to find out what version is running. In the core Satosa, there were references to the consent and account linking services that have been removed. There should not be any dependency on microservices in the core. Next up: looking at how state is being handled, and introducing high-level functions to better manage state. Also looking at some of the other PRs: • https://github.com/IdentityPython/SATOSA/pull/316 • https://github.com/IdentityPython/SATOSA/pull/314 • https://github.com/IdentityPython/SATOSA/pull/279 • https://github.com/IdentityPython/SATOSA/pull/280 Also looking at the issue Scott K has filed (checking the scope on attributes, and filtering out attributes based on that scope). ( https://github.com/IdentityPython/SATOSA/issues/297) b. pySAML2 - https://github.com/IdentityPython/pysaml2 Not many changes. Made some changes to the version module. Next up: review issues that have come up, including nameID format/policy and how those should be different configuration options. Also, of higher priority, configuration around which algorithms we use and how we advertise them. There are also issues around certificates, signing and encryption/decryption. Later will look into the problem with the redirect binding and the signed response which caused a failure. Also, trust and certificates (https://github.com/IdentityPython/pysaml2/issues/594) See: • https://github.com/IdentityPython/pysaml2/pull/662 • https://github.com/IdentityPython/pysaml2/pull/660 • https://github.com/IdentityPython/pysaml2/pull/645 • https://github.com/IdentityPython/pysaml2/pull/628 • https://github.com/IdentityPython/pysaml2/pull/625 • https://github.com/IdentityPython/pysaml2/issues/669 • https://github.com/IdentityPython/pysaml2/issues/659 d. pyFF - https://github.com/IdentityPython/pyFF Heather has asked Leif to send an update. d. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Roland is actively working on items in the repository now. 3 - AOB Creating new microservices - new documentation available: https://github.com/IdentityPython/SATOSA/wiki/Anatomy-of-a-response-micro-s… Ivan is thinking making this part of Satosa so microservices won’t need their own helper. You can use this directly with your own services, or you can import it from Satosa. There is also a new test case available to test the new logging helper. Will move this into core soon so it will be easier for existing microservices to take advantage of it. Thanks! Heather

6 years

1
0
0 0

Reminder: idpy dev call, 17 March 2020

by hlflanagan＠sphericalcowgroup.com

BlueJeans: https://bluejeans.com/567481057 Agenda: 0 - Agenda bash 1 - 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 - AOB Thanks! Heather

6 years

1
0
0 0

T&I Hackathon - canceled

by hlflanagan＠sphericalcowgroup.com

Hola a todos! With the cancellation of the eduGAIN Town Hall, it seems best to go ahead and also cancel the T&I Hackathon on 23 March 2020. We will be trying for another one in the future, though the date and location are (obviously) TBD. You are always welcome to code and submit PRs in the comfort of your own home, and the projects you’re interested in would most certainly appreciate it. Thanks! Heather

6 years

1
0
0 0

Notes: idpy dev call, 3 March 2020

by hlflanagan＠sphericalcowgroup.com

Attendees: John P., Giuseppe, Hannah, Roland, Scott, Ivan, Alex, Johan, Christos, Heather Notes: 0 - Agenda bash 1 - Discussion a. <NameIDPolicy> and <NameID> Format attribute See discussions on slack. There is a policy setting; you may want to request a specific NameID format from an IdP, and if you don’t define the config option, what happens? We can request a NameID format in an authN request, and we can advertise in metadata what NameID we support. One thought (Ivan) is that it would be better not to advertise a NameID format, and only when you want a specific format to request it. Alternatively (Christos), do not request anything during the AuthN request, and to list in metadata in preference order the NameID format you will support. [Discussion] Should we leave this config option out, thus not setting the NameID policy at all? We should be able to set the NameID policy; there are use cases where we have to force this. Separating the two config options is a good thing to do. We need to set a NameID policy without a NameID. The string “none” is a hack. We can set some defaults, and if we need more complexity, it should probably be in a microservice. Christos points out that a microservice can’t do this because it’s at the wrong place in the workflow. The microservice architecture would need to be refactored. Satosa defines an internal representation fo the data, and the microservices act on that. When something is defined we need to make sure it can be defined into something for the outgoing protocol; for NameID, at the point the microservices are requested, they don’t have access to the backend or its metadata. We would need to make a change that would allow some or all microservices to run at a different point. If anyone has specific requirements here, please let Ivan know. b. Custom syntax in YAML - https://github.com/IdentityPython/SATOSA/pull/316 A new tag that would allow us to specify an environment variable. Use case: a deployment via docker swarm or kubernetes, and it is convenient to inject secrets via environment variables into the containers. Was handled via entry point scripts. The YAML config files are in an open Git repository. This gets cumbersome. Scott implemented a first draft, and Ivan improved it. Could we use py files instead of YAML files? This would work for pySAML2, but not for Satosa. Ivan will think about this a bit more, and then either merge the code or figure out another way to do this. Action item: Scott will improve the documentation (more examples would help) Action item: Ivan to consider this further; code is fine if we go with the current syntax. c. Shibboleth encryption algorithms Use case: the Shib project has announced that as of v4 of the IdP, default will be GCM encryption. This can be changed either globally or per RP. There are many Satosa SPs that will need to be able to consume that default. This is handled correctly for Satosa, but pySAML2 has two backends for encryption, and one uses xmlsec1, and the other on a python security library. With the xmlsec1, we generate the commands and run them from the xmlsec1 binary. Whether we can read/decrypt the GCM based payloads depends on what xmlsec1 supports. If your openSSL supports the GCM encryption, then xmlsec1 will support it as well, and everything should work correctly. We do need to add the different algorithms to pySAML2. Action item: Scott to open an issue against pySAML2 to help track this 2 - GitHub review a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Will discuss at a future meeting (hopefully at the hackathon). Roland will release new versions tomorrow. b. Satosa - https://github.com/IdentityPython/SATOSA i. New release (v6.1.0) - https://github.com/IdentityPython/SATOSA/releases/tag/v6.1.0 Contains a new middleware dependency that takes care of the SameSite cookie issue. It sets the SameSite attribute to none. Note only Python 3.8 and newer are the only ones that know about the SameSite attribute. There is also a new dependency that takes that cookie, duplicates it, and removes the SameSite attribute; that means it sends two cookies, one with it set, one without. Clients that do not know what the SameSite attribute are about will drop it, and ones that do will have it. Satosa only cares about the cookie it sets itself. Deployer will need to define the configuration that takes the cookie name and the holdback name. See example: https://github.com/IdentityPython/SATOSA/blob/master/example/proxy_conf.yam… SameSite attribute is set here: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/state.py#L50 Monkey patch: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/cookies.py#… Release also includes a fix for sessionID. This comes out of some of the updates to logging. The sessionID is now part of the state, not part of where the logs happen. Now set pySAML2 to v5 or newer, in response to a security vulnerability that was patched in v5 c. pySAML2 - https://github.com/IdentityPython/pysaml2 d. pyFF - https://github.com/IdentityPython/pyFF 3 - AOB Thanks! Heather

6 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss March 2020