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`. Control flow is
returned to the `base` module where `used_id` is hashed 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. Finally, the appropriate frontend module (saml,
openid) 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 .
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 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' . 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.
Ivan c00kiemon5ter Kanakarakis >:3
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
* regular board member for 24 months = Leif
Please let me know if you have any questions!
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
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.
I've also reviewed the licenses listed under each of the Identity Python
* 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
Thoughts or concerns?
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
2. refactor crypto to along the lines of what Steffen and others have
3. add support for explicit parametrized padding mechanisms
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?