August 2018 - Idpy-discuss - lists3.sunet.se

by hlflanagan＠sphericalcowgroup.com

Hi all, One of the individuals I contacted when I was reaching out about the possibility of a [C]CLA pointed out the following from the GitHub Terms of Service: --- 6. Contributions Under Repository License Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms. If you have a separate agreement to license your contributions under different terms, such as a contributor license agreement, that agreement will supersede. Isn't this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound". We're just making it explicit. (https://help.github.com/articles/github-terms-of-service/) --- I've also reviewed the licenses listed under each of the Identity Python projects: * pySAML2 = Apache 2.0 * SaToSa = Apache 2.0 * pyXMLSecurity = NORDUnet (2 clause BSD) * pyFF = SUNET (2 clause BSD) * pyeleven = SUNET (2 clause BSD) My reading of this suggests that a CLA doesn't actually offer us any assurances we don't already have by a) using GitHub (and therefore agreeing to the ToS) and b) posting the licenses in the repos (which must be inherited by anyone posting in those repos, again thanks to the GitHub ToS). Thoughts or concerns? Heather

5 years, 7 months

5
9
0 0

SATOSA debug cycle

by martin＠surfnet.nl

Hi, I was discussing development of InAcademia with Niels and again had to mention that the debug cycle of SATOSA involves: pip installing, editing the virtual- env code, restarting satosa, check behaviour, port changes to the git tree, commit and push, pip install --upgrade, check. Especially the manual port of the virtualenv changes/hacks back into the git tree are error prone. Am I doing it wrong, or is this really the only way? Best regards, Martin

5 years, 7 months

2
3
0 0

working configuration for SATOSA SAMLMirrorFrontend

by skoranda＠gmail.com

Hello, Does anyone have a configuration for the SATOSA SAMLMirrorFrontend they have working and would be willing to share? I have working configurations for SAMLFrontend (of course), but I want to understand what changes for a working SAMLMirrorFrontend. I am having trouble just understanding it from the code, and I cannot find any documentation that explains it... Thanks for your consideration, Scott K

5 years, 7 months

4
6
0 0

Best practice recommendation for setting up a development environment for SaToSa (with dockers?)

by niels.vandijk＠surfnet.nl

Hi all, For some time I have been wondering what is the best practice for developing on SaToSa. And I have no doubt I lack experience with developing in phyton, so that probably does not help either. I would kindly ask you to share how you set this up. Within my projects I typically have a pool of developers who are onboarded for a project and may go away after it is finished. Developing on satosa alone does not really make sense unless you also have an IDP or OP and an SP or RP depending a bit on what needs to be done. In addition you might need a MDQ and a WAYF service, e.g. based on pyFF. In an effort to minimize the overhead of setting all of that up, I have created a set of dockers that have ready made IdP, SP, RP and pyFF components so this can just be started and it works. Clearly a bit of work needs to go into making sure that all the bits know about each other so client registration and saml metadata needs to be synced between the various components. For SaToSa the container model however does not really work well, as I have set it up currently. Typically I want to use a git repo as the source of my codebase. Deploying this codebase with "pip install" directly pulls it from git into the container and this works well, but now modifying the code is really cumbersome as the code is now buried deep inside the python libraries directory structure, and in addition I can no longer directly commit or push my changes from within the docker container towards git. An alternative model where I deploy the codebase on my local disk, push changes from there into git and then after each change rebuild the container is even more annoying. There must be better ways to deal with this, but I have not figured that out :( Any suggestion of best practices of how to set up a "proper" dev environment for SaToSa, preferably in combination with docker? Many thanks, Niels PS: given that everyone ever wanting to do something with SaToSa would also need IdP, SP, RP and probably MDQ would it make sense to in the neighborhood of SaToSa provide some out of the box components that set that up, e.g. like as dockers? I would be happy to share we I have created for that so far. -- Niels van Dijk Technical Product Manager Trust & Security Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5 SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands www.surfnet.nl www.openconext.org

5 years, 7 months

4
3
0 0

Notes: idpy developers call, 21 August 2018

by hlflanagan＠sphericalcowgroup.com

Attendees: Ivan, Roland, Scott, Rainer, Heather Notes: pySAML2 release * New release is done (yay!) * Some problems with the new packaging software - tools didn’t have a way to specify certain minimum versions. There is a new PEP that can solve this (there is a PR about this - https://github.com/IdentityPython/pysaml2/pull/542) * See the change log for more details ( https://github.com/IdentityPython/pysaml2/releases/tag/v4.6.0) * Expect a minor release soon to fix the packaging stuff Satosa * Ivan has been thinking about how to structure the micro services. Wants to do the same thing with both front end and backend modules. Has written a small part of the proposal on how this should be done and will be sharing that later this week on the list. Expect this to work like a plugin system. * The changes will definitely impact the configuration file, and relies on the use of entry points. * Also interested in introducing asynchronous services, but that’s a bit farther down the road. * Question: how to handle version control when each micro service is its own package? Each micro service will have its own repository and have its own version * Scott is seeing use cases where Satosa needs to make intelligent decisions on which discovery service to use. This may be similar to something Christos needs. Scott will bring up the use case in detail on the next call. * Roland was contacted by Peter Gietz; he has several companies approaching him about proxy services, and he will be using Satosa. He would like to become a member of the idpy community (of course) and will be contributing in the future. * In the GEANT project, where proxying between protocols is common, they are looking at the OIDC front ends being based on the best code and there is are people interested in writing front end code. Roland wrote a flask-based RP and OP, so there is some code that we could use as a POC if we want to be at the front of this. Leif suggested using Blueprints for this, which Roland isn’t familiar with but may be of more general interest. * If you use the SAML front end, you MUST use the SAML back end. Can that assumption be changed at some point, so that you could use an OP? This should be doable. Suggest that Scott open an issue as a placeholder for future discussion. * Some IdPs are not even asserting nameID (see https://github.com/IdentityPython/SATOSA/pull/190) - there is an assumption that there will always be a nameID returned. This PR has a dependency on the pySAML2 code also being updated, and a test won’t be successful unless pySAML2 is updated. Governance * Who is going to maintain the code Roland has been working on? Google is giving that code to the OIDC; Roland has moved that code to OIDC and created a fork in IdentityPython. Maintenance of the Google code: OIDC would assign maintainers of the code and pay them for doing that. Not sure if this is a full or part time thing, or how much they would pay. OIDC is unlikely to hand that money to idpy and ask us to find a person(s). They probably have people in mind for the python and java implementations, but no one at this time for the javascript. * Roland has written an extension to the RP library to cover the OP, and extensions to be able to work in a federation as described by the OpenID federation draft. Would like those extensions to be owned by idpy. * Andreas (Uninett) has developed his own proposal as to how to do an OpenID federation. Roland and Andreas will be discussing if the two proposals (Roland's and Andreas’s) can be merged. Roland to send a link to the list pointing to the two proposals. * The work to get the OIDC federation draft accepted as a draft should be a poster-child for getting people to understand they have to be involved to get standards relevant to them created. * For idpy governance, please review what’s available in https://github.com/IdentityPython/Governance and comment as appropriate.

5 years, 8 months

2
1
0 0

The OIDC federation drafts

by roland＠catalogix.se

The OIDC one: https://github.com/OpenIDC/fedoidc/blob/master/draft/oidcfed.hf.txt (new version coming out soon = within days) Andreas proposal: https://oauth.no/jwtfederations/ -- Roland "Education is the path from cocky ignorance to miserable uncertainty.” - Mark Twain

5 years, 8 months

1
0
0 0

PySaml2 release and next call and items

by ivan.kanak＠gmail.com

Hello everyone, During the last few days I've gone through about 20 pull requests[0] and some related issues and merged most. With more than 100 commits since the last version, it is time for a new release. I will prepare the changelog and bump the version on Monday. Currently, there are only 7 open pull requests. Two of them (#518 #498) are mine, one is very low priority (#326) and the rest (#396 #483 #485 #493) are all useful. The six of them, I plan to include in the next release, which should not be very far (I know people have been waiting for #483 for some time now). After, this pysaml2 release I want to focus more on SATOSA and the proposal on micro-services' (and frontends'/backends') handling based on entry-points[1][2]. We've also had a discussion on configuration[3] and there is some work to be done there too. The next idpy call is scheduled for 7/8 and I already know some people won't be able to make it. There is no set agenda yet; I would propose to talk about the changes that went in pysaml2 and then focus on what items are most important for the next one and for a future SATOSA release. Will people be available for the call? If we skip this call, the next one is on the 21st. There is a small possibility that I won't make it, but that is not yet final. I will be on vacation from 13/8 and I should be back on 20/8. I will let you know earlier so we can schedule the call. I welcome any comments on the above brief, and I am certainly available to talk on those matters on the idpy call on Tue 7/8 at the usual time. Cheers, [0]: https://github.com/IdentityPython/pysaml2/pulls?q=is%3Apr+is%3Aclosed+sort%… [1]: https://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discove… [2]: https://entrypoints.readthedocs.io/en/latest/ [3]: https://github.com/IdentityPython/SATOSA/issues/167 -- Ivan c00kiemon5ter Kanakarakis >:3

5 years, 8 months

4
4
0 0

RSVP please - idpy call Tuesday, 21 August 2018

by hlflanagan＠sphericalcowgroup.com

Hello all you summer time holiday peoples! I'm checking in to see who is available for an idpy call next week. If only Ivan and I are available, we'll go ahead and cancel. Please let me know by CoB on Monday. Thanks! Heather

5 years, 8 months

2
1
0 0

Notes: idpy developers call, 10 July 2018

by hlflanagan＠sphericalcowgroup.com

Attendees: Ivan, Scott, Christos, Heather, Rainer, Johan L. Notes 0. Agenda bash * CLA status (see AOB) 1. Satosa Security review Team in GEANT is offering to do a security review of Satosa and is looking for guidance on where to start. Ivan’s suggestion: “SATOSA only connects frontends to backend (and vice versa), with some intermediate logic that defines the internal representation of the information it has collected, plus the metadata and configuration. The "heavy lifting" is left to the libraries that actually implement the standards. IMHO, the tricky bits are there; in the libs. So, my vote would be yes, but lets start with the shell (SATOSA) and see if we can move towards the core (libs) later.” Note that SATOSA will evolve over time, so some of what gets reviewed will change. Should we hold off on doing this until the code settles a bit? It could help prioritize, and the GN4 project does have extra budget now. Could do a lightweight evaluation now, and more in-depth next year. Ask Niels if this is a one-off thing; if it can be repeated, then go ahead and do it now. There is a rough draft of a security response process (in case they find something); is that ready for more public feedback? Ivan to do another quick review and then we can send it to the list. 2. PR status - Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA) Going through some documents from Christos regarding the step-up service. Somewhat related to PR 182. Will be working on that, probably making this a new microservice. Evaluating flake8 (combines a linter, pyflakes, and a style guide, PEP8). This will also be part of the testing procedures. PR186 - about adding contribution from GEANT (discussed on the mailing list) - Satosa microservices How flake8 handles plugins will impact how we manage microservices. Each microservice will be split into its own package and its own repository; each microservices will be responsible for its own configuration and dependencies. It will be like a plug in system. - pySAML (https://github.com/IdentityPython/pysaml2) Ivan has gone through several issues and PRs, and sent the PR for the day/time module (a big one) out for review. Johan has done a review on that, and a few things will change. Additional reviews always welcome (518). The code is now using aniso8601, but that can easily be swapped out for something else if needed. Ivan has merged some smaller PRs, including one to fix the CI stuff, and planning to add more Python versions to the testing. Also added more coverage reports. This will help us see what is/is not tested. Working on figuring out how to properly package a Python project for release (see ‘flit’ https://flit.readthedocs.io/en/latest/ as a possible packaging source.) For current packages, the license was not included in the package, and other items needed to be fixed/renamed, version identified, etc. Concern that many deployers are using things like salt, puppet, etc, and those tools have modules for the existing packaging tools. If we move too quickly, then we’ll have packages that deployers can’t easily install using existing infrastructure. Scott can help facilitate a discussion around these kinds of requirements. note that something like flit is about creating the package, but it still creates a standard python package for deployers. Another issue where someone removed a dependency from a library, but something else still depended on that - cryptodome replaced with cryptography. Closed some issues that were invalid or outdated (fixed by merges already done). Introduced a documentation file (editorconfig) - a generic description on how an editor should work. See GitHub for full details. - pyFF (https://github.com/IdentityPython/pyFF) 3. AOB CLA status? The group has not come to consensus on what level of risk is acceptable (and who can accept that risk). This needs to be resolved so we can move forward, either by relying on the existing licenses and GitHub TOS, or trying to create a new CLA and get people and/or companies to sign it. Who can make this decision? AARC project is going to start a pilot project for an OIDC federation. Satosa will be part of the software piloted. Is work towards this (working towards OIDC) on Ivan’s roadmap? It was not, but Ivan has started talking to Roland about this and collecting material to read. There is a branch on Satosa that might be of interest that assumes an OIDC front end. Ivan points out that some of this will need to tie into the OIDC libraries Roland has been writing for Google; Ivan will be looking at those libraries first. Roland is the only one that can upload new releases to pypy. Hoping someone (Johan) can upload a new version of Satosa and give Ivan access to that repository? yes, this should be possible. Ivan wants to make more frequent releases, and start a change log. Sent from my iPad

5 years, 8 months

5
12
0 0

Forks of Forks of PyCrypto and PyASN1 in pyXMLSecurity

by klemer＠dfn.de

Hey list, is there a specific reason that pyXMLSecurity maintains forked, crippled down and slightly changed versions of pycrypto (abandoned) and PyASN1 (with security changes in the upstream since forking)? From a quick look it seems that it might be quiet easy to port it over to PyCryptodome(x) which is maintained and itself a fork of pycrypto and would bring back some speed optimized parts in c (that were cut away when forking) as well as ECC that might get relevant in the coming years. My main concern is about the long term security impact of a self-maintained crypto module; speed is just a nice addition ;). pkcs11 wouldn't be impacted by it and has to be kept separately. Would patches/PR be welcome or just a waste of time? Steffen -- DFN-Verein Steffen Klemer Alexanderplatz 1 +49 30 884299 307 10178 Berlin klemer at dfn.de Fax: 030 88 42 99 370 http://www.dfn.de

5 years, 8 months

4
8
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss August 2018