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
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.
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
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
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
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
Hey everyone,
At some earlier point we had a discussion about creating labels for
the github repositories so that we (and users) can put an order in the
issues and pull requests.
So, I went around some big and some small-but-trending repos on github
and using the github-api and a shell script I got two files: one has
the labels by repo, the other is a list of all labels sorted and
unique'd. The latter is the interesting one, and from a quick look,
the labels with a prefix (area, component, kind, needs, priority,
scope, topic, type) seem to be the interesting ones.
Do you think those are useful? Would someone like to pick some,
propose a list and then help labelling the existing open issues?
PS: On another note, the cpython labels include "CLA signed" and "CLA
not signed". Maybe we can use those if we go forward with that.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
On Wed, 4 Apr 2018 at 11:42, Niels van Dijk <niels.vandijk at surfnet.nl> wrote:
>
> Hi all,
>
> I would like to find out what the licenses of *all* components and
> dependencies that make up SaToSa. Any suggestion to how to do that in an
> automated fashion?
>
> I could walk down the libraries manually in
> virtualenv/lib/python3.5/site-packages, but that is rather tedious and
> error prone. I also found some scripts to do this for me, however these
> seem to just report what is in use at the os/system level, not
> specifically for our virtualenv.
>
> Any suggestions, or a solution you may have used previously?
>
Also, related to:
[Idpy-discuss] SaToSa (and dependencies) licenses and copyright
https://lists.sunet.se/pipermail/idpy-discuss/2018-May/000161.html
I have been looking for ways to automate dependency tracking and
license compliance. Bellow is a list of tools that do that. If anyone
has tried any of the tools, feedback would be appreciated.
- FOSSA
https://fossa.io/
Managed dependency tracking and license compliance as a (paid)
service. From the FAQ:
> Do you offer discounts for non-commerical projects?
> If you are a non-profit, educational institution or based in open source, we offer special plans for your budget.
- Fossology
https://www.fossology.orghttps://github.com/fossology/fossology
Self-hosted; PHP/C; Free and Open Source; Supported by the Linux Foundation.
- scancode-toolkit
https://github.com/nexB/scancode-toolkit/wikihttps://github.com/nexB/scancode-toolkit/
Self-hosted; Python; Free and Open Source
- Licensee
http://ben.balter.com/licensee/https://github.com/benbalter/licensee
Self-hosted; Ruby; Free and Open Source
- Ninka
http://ninka.turingmachine.org/https://github.com/dmgerman/ninka
Self-hosted; Perl; Free and Open Source
( compares to a big list of predefined licenses:
https://github.com/dmgerman/ninka/tree/master/t/data/licenses )
- Speedy LIcense Checker
https://github.com/gerv/slic
Self-hosted; C; Free and Open Source
And on a side note, dependency vulnerability checkers:
- snyk
https://snyk.io/
Managed vulnerability checker as a (paid) service.
> Unlimited tests on open source projects
- Dependency Track
https://dependencytrack.org/https://github.com/DependencyTrack/dependency-trackhttps://www.owasp.org/index.php/OWASP_Dependency_Track_Project
Self-hosted; Java; Free and Open Source; Supported by OWASP
Hopefully, these will prove helpful to the community,
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
