Hello all,
This is a reminder that there is a call about idpy governance tomorrow,
27 March @ 16:00 UTC (9am PT | 12noon ET | 18:00 in Sweden). The goal of
the call is to settle on an IPR home for idpy; once we've done that, I
can start creating the necessary policies and procedures in accordance
with the requirements for $IPRHOME.
A comparison chart of possible IPR homes is available in a Google doc:
https://docs.google.com/spreadsheets/d/1dNR8clA_wKouhwonD8bIiyA5N2wMsorS8Uz…
If you have not received an invitation and want to be on the call,
please reach out to skoranda at sphericalcowgroup.com and he'll get you
added to the BlueJeans meeting invitation.
Thanks!
Hi all,
There was no good time for folks with the first attempt at a call to
discuss finding an IPR home for idpy. I've put together another doodle
poll - hopefully there will be a time that works more easily for mst!
https://doodle.com/poll/33gu594nmn4q7p85
If you would, please fill out the poll by Wednesday, 21 March 2018.
Thanks!
Heather
Hi,
We were experiencing severe pyFF restarting problems since our last
deployment. It turned out lxml was updated to 4.2.0 which introduced
segmentation faults on every metadata refresh. Downgrading to 4.1.1 resolved
our problems.
As for adopting CMService in idPy: Niels will make an official statement about
that.
Best regards,
Martin
Hi all,
The list has been quiet, and people with action items related to the PRs
still have some work to do. Please take the meeting hour to work on your
tests or flesh out your PRs to meet the new templates, and Ivan will do
his magic with regards to reviewing and writing code.
If you have any questions or discussion topics, please post to the list!
-Heather
Attending
Martin, Heather, Scott, Rainer, Ivan
Regrets
Leif, Roland, Jonas, John, Benn
Agenda:
0. Agenda bash
1. XML bug (Ivan)
It is primarily an XML issue. We are not effected because we are using
element three which by default strips comments (though that is
problematic in a different way). This means one of the standards for
signing is not included in the code base. This is still a theoretical
limitation (no one has complained (yet)).
Ivan has found some interesting tools that might be used to help
validate XML. There is a tool in pySAML2 to do this; it works, but it is
not maintained. Ivan is still investigating. Note that this might also
be of interest to pyFF.
2. pySAML2 PRs - https://github.com/IdentityPython/pysaml2/pulls
Scott’s PRs are waiting on him to write tests. No other blockers.
PR 471 is straightforward to merge.
Ivan is still reviewing the other PRs.
PR493 is failing tests but the fix might not be the right solution.
There are many places where pySAML is encoding things, so need to
understand where and how we can generalize this. Need a test.
PR495 is also assigned to Ivan. It seems fine; will probably just accept.
PR499 is new. Not sure what the use case is here. It ties back to Issue
412 from May of last year. It could still use a test; Ivan will write a
comment asking for that.
Action item: update the PR template to be more explicit in asking for
the use case
3. Governance update
Many thanks to the interested parties that filled this out, but alas, I
will need to extend the doodle poll as some of the key people are unable
to be in the same place at the same time. Look for an updated poll in
the next few days.
4. AOB
* Consent manager service (Martin) -
https://github.com/its-dirg/CMservice/blob/master/src/cmservice -
discovered code injection bugs while investigating the SAML bug. Roland
says the code has been abandoned. SURFnet is actively using the
CMservice, so the question is what else is being used in the consent
space in idpy? For the other deployments described on the call, consent
is not part of the workflow (e.g., platform participants are employees
or otherwise have already consented to using the service)
* Should it be included? Consent will become more of a thing in the
future for additional deployments. Scott is supportive. Request for
Martin to ask if SURFnet is willing to provide some resources for
ongoing maintenance. Martin to send a formal request to the list as per
our inclusion guidelines.
(https://github.com/IdentityPython/IdentityPython.github.io/wiki/Adding-and-…)
* SURF fork of the software:
https://github.com/its-dirg/CMservice/compare/master...SURFscz:master
* The its-dirg is a department that has since been disbanded as Umea
University. Need to reach out to Leif and Roland to see if they can
reach out to someone who still has access
* New functionality request that would require a new SAML front end -
The Satosa mirror front end exposes multiple IdPs by mirroring the IdPs
that are available from the back end. If you’re federating with eduGAIN,
it would take those IdPs and expose them at the front end as multiple,
logical IdPs. This bypasses the WAYF. Satosa still looks like a single
SP. For Scott’s use case, rather than having mirrored IdPs that are
based on the downstream authenticating IdPs, the goal is to have
multiple virtual IdPs on the front end of Satosa that correspond to VOs.
The idea is that using a CMP, you would have a VO and would be able to
provision into Satosa a logical IdP that represents that organization.
Example: A set of SPs want to federate with the IdP for the MWA
collaboration. So, when the user looks to the service, they pick their
VO and from their VO, they get a smaller list of associated IdPs. The SP
will still think the user has come from the MWA virtual IdP, not
whatever the actual downstream IdP authenticated was. This is intended
to be something dynamic.
* This seems to be a new use case, and new tool(s) will likely be
required.
* Where should the information be stored? How does it consume the
information over time? Should this be functionality for Satosa as a
whole, or be a separate front end? Scott will pull together an initial
proposal and more specific questions for the group.
Next call:
March 20 - Note that Heather is unavailable, but group will still have a
discussion if needed
Hi !
I’ve been asked what’s happening with CMService (https://github.com/its-dirg/CMservice <https://github.com/its-dirg/CMservice>)
and if there is any interest from this group to included it among our work items.
This was a project Rebecka/Samuel worked on back in 2016 and nothing has been
done with it since then.
Myself, I have no interest in the project.
— Roland
I've been looking at how/if
https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-impl…
affects pyFF or pyXMLSecurity.
First some basic facts/observations:
- pyFF deals with SAML metadata and not SAML messages so
the vuln described by the DUO team doesn't apply to pyFF.
- its easy to imagine SAML-metadata based attacks that
would be similar to this (if perhaps more difficult in
practice).
- pyXMLSecurity is is the default choice in pyFF but
not the default choice in pySAML2 for xml signature and
verification.
Ever since the wrapping attacks that came out a few years
ago pyXMLSecurity has taken the position that the library
should only return a /processed/ reference from validation.
The xmlsec.verfied function does precisely this and I
have done some initial unit-tests that seem to indicate
that it does so correctly - i.e the references returned
by xmlsec.verified do not contain in-text comments unless
#WithComment c14 method is used. However these are early
results and I'll need to do more poking around to be sure.
There are of course ways to shoot yourself in the foot
anyway. For instance if your code does
xml = parse_xml(some_text)
if xmlsec.verify(xml):
use_bits_from(xml)
Then you're up the creek without a paddle. Instead you
need to do
xml = parse_xml(some_text)
verified_xml = xmlsec.verified(xml)
if verified_xml:
use_bits_from(verified_xml)
Thats it for now... more later.
Cheers Leif
Cheers Leif
