September 2018 - Idpy-discuss

by ivan.kanak＠gmail.com

Hi everyone, I proposed to discuss this at the bi-weekly idpy call (Tue 18/9 at 13:00 UTC). This is a bit complex, so I thought I'd do a writeup for anyone that would like to discuss this. I will try to describe how SATOSA handles the NameID value, and by this I mean how the text value of the NameID node is transformed, after it is received by the saml-backend (from an IdP), and before it is passed over to the appropriate (saml or openid) frontend. Omitting some details the flow is as follows: Once an authn-response is received, the backend parses the response and extracts the NameID node as `name_id` and its text value as `user_id`[0]. Control flow is returned to the `base` module where `used_id` is hashed[1] before it is passed to the response-microservices. Once microservices are done doing their job, control is back in `base` module and the `user_id` is hashed again[2]. Finally, the appropriate frontend module (saml[3], openid[4]) is invoked and `user_id` is used as the basis for the attribute that is needed. What stands out here is the hashing of `user_id` (that happens twice). This is something that has come up multiple times in different forms (pull-requests #137 #160 #193 work around it). I decided to figure out what's going on: How is that decision formed? Why does that take place? Does it provide any value? Hashing of `user_id` was introduced by commit b54006f [5]. Unfortunately, the accompanying commit message does not offer an explanation or any hints on why this was needed. Looking at the evolution of the code, nothing shows me why that was needed or what value it added. A hint is that it is closely coupled to the `UserIdHashType` enumeration[6] from `internal_data` module. Unfortunately, the evolution of that part of the code also doesn't help to reveal the need for both the enumeration and the hash. In the hope that maybe a test that I did not see at the time could reveal a reason for this behaviour, I went ahead and removed the relevant code. You can see the changeset on my personal fork on the branch named 'refactor-remove-user-id-hash' [7]. And nothing really broke! At this point I do not see any value keeping the UserIdHashType enumeration and hashing of `user_id`. If someone has an insight on why hashing `user_id` was introduced and what its purpose was, I would be interested to know. If we do not come up with a valid use case, I would propose to move forward by removing that part of the code. [0]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/backends/s… [1]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/base.py#L1… [2]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/base.py#L1… [3]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/frontends/… [4]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/frontends/… [5]: https://github.com/IdentityPython/SATOSA/commit/b54006f [6]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/internal_d… [7]: https://github.com/c00kiemon5ter/SATOSA/compare/d861e87...refactor-remove-u… Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

6 years, 2 months

4
4
0 0

idpy governance and nominations for first Board of Directors

by hlflanagan＠sphericalcowgroup.com

Hola a todos! We've been talking for a while about how to structure idpy into a project that has clear IPR guidelines, security policies, and governance. You've had a chance to see the proposed governance statutes (https://github.com/IdentityPython/Governance) Having heard no changes, I'd like to propose the following: First, that the statues and incident response policies be considered "good enough" to get us started. Second, that we establish a Board of Directors as described in the statues. I have a list of candidates that have agreed to be nominated as the initial board seats. If you would like to be added to the list, or have any comments on the proposed candidates, please drop me a direct message. Nominations will be closed on 30 September 2018, and we will either go to a vote of idpy participants if there is contention for one or more seats, or we will have a board slate ready to go. The initial list of nominees are: * idpy chair for 12 months = Ivan * at-large for 12 months = Roland * at-large for 24 months = Heather * regular board member for 12 months = Mike Jones (as a link to the OpenID Foundation) * regular board member for 24 months = Leif Please let me know if you have any questions! Heather

6 years, 2 months

1
1
0 0

reviewing the need for CLAs

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

6 years, 3 months

5
9
0 0

Agenda: idpy developers meeting, 18 September 2018

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 18 September 2018 Time: 13:00 UTC https://bluejeans.com/655841213 Agenda: 0. Agenda bash 1. Governance and nominations: what does that mean / how we move forward (e.g., with CLA and other CommonsConservancy) / etc - See email from 11 September 2018 (Subject: [idpy-discuss] idpy governance and nominations for first Board of Directors) for initial set of candidates 2. New bugfix/minor pysaml2 release v4.6.2 3. pyXMLSecurity refactor (see email from 14 September 2018 (Subject: Re: [Idpy-discuss] getting beyond RSA and PKCS1 v1.5 for pyXMLSecurity) 4. SATOSA: Hashing the user-id - is this necessary? 5. AOB --- For reference: - 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)

6 years, 3 months

1
1
0 0

getting beyond RSA and PKCS1 v1.5 for pyXMLSecurity

by leifj＠sunet.se

https://github.com/IdentityPython/pyXMLSecurity/pull/49 This PR refactors how padders and hashers are created for the cryptography backend and adds a test validating an ecdsa-sha512 signature My plan after this is sorta like this: 1. remove the do_padding/do_hashing boolean and move the outside-the-pkcs11-token hashing and padding into sign/verify of XMLSecCryptoP11 2. refactor crypto to along the lines of what Steffen and others have suggested. 3. add support for explicit parametrized padding mechanisms Thoughts? Cheers Leif

6 years, 3 months

4
4
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

6 years, 3 months

2
3
0 0

Agenda: idpy developers meeting, 4 September 2018

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 4 September 2018 Time: 06:00 PT | 09:00 ET | 15:00 GMT https://bluejeans.com/655841213 Agenda: 0. Agenda bash 1. Giving attribution in idpy projects 2. Development with docker 3. Satosa - SaToSa PR#191 - Cleaning up the special logic of the SAMLMirrorFrontend from the saml-backend 4. pySAML2 - New minor pysaml2 release - v4.6.1 5. pyXMLSecurity developments 6. AOB --- For reference: - Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA) - pySAML (https://github.com/IdentityPython/pysaml2) - pyFF (https://github.com/IdentityPython/pyFF)

6 years, 3 months

4
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss September 2018