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
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
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
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)
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
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
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
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.nlwww.openconext.org
