Hi Leif,
One of the features of pyFF that I am currently leveraging is the
ability to use different pipelines/configurations to offer multiple
discovery service "backends", each with its own set of IdPs.
This is important for a use case where a deployment supports multiple
VOs and each VO needs to have its own set of IdPs that are included in
discovery.
For example, with one VO a particular IdP from a commercial
pharmaceutical company should be included, but not for any other VOs.
Today pyFF supports this but I would like to understand if the upcoming
refactor (splitting off the discovery frontend into a separate project
and refactoring the backend) will change that.
I guess more generally it would be nice to better understand your
roadmap for pyFF development.
Thanks,
Scott K
Hi,
We are facing interesting OIDC challenges regarding sparsely featured OIDC
implementations.
One RP has an oAuth2 based implementation that never accesses the UserInfo
endpoint because (I freely quote the code comment) "They already have
everything they need to know from the id_token". It turns out, Google bloats
their id_token with claims so they reduce (effectively prevent) requests on the
UserInfo endpoint. It seems more and more RP's start to assume the token
endpoint will deliver everything they need or at least enough in the id_token.
We have decided to go along with the Googles of this planet and bend.
Now, pyop doesn't normally enrich the token endpoint id_token, but has a
parameter to consume extra_id_token_claims, just like the authhorizatoin
enpoint. From a satosa endpoint however, I have no access to the interal_resp
from the user to enrich the token endpoint. sastosa handle_authn_response does
set the authz database with the extra claims (consumed by userinfo endpoint I
guess) but I have no way to know the key (userid) to reliably access these
claims on the token endpoint and pyop doesn't have a authz code to userid
converter, as far as I know?
The best way I see, would be to modify pyop to enable internal (Provider
scope) extra_id_token_claims in the token endpoint. But we don't want to
maintain yet another fork in our deployment. This means that I'm allowed to
make a PR, but only if I have IdPy's commitment to merge the changes back
upstream.
Question: did I miss an option in pyop config that already does this? Or has
somebody already started an effort to implement this? If not: is IdPy willing
to merge this enhancement if I created a PR?
Best regards,
Martin
Attending:
Ivan, Heather, Roland, Rainer, Johan L, Scott, Martin
Regrets:
Christos
Notes:
0. Agenda bash
1. Governance update
Board meeting tomorrow, December 12. Main topic = IPR
2. PR review
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
Ivan merged the nameID PR submitted by Scott today. Ivan is also
planning to do some more work on deprecating the internal hashing as
discussed on the last call. Will work on it today, and cut a release
that people can test.
Ivan met with Roland and discussed the new OIDC libraries. Ivan will be
working on a new pyOIDC frontend, which will be based on the OIDC
endpoint library that Roland developed. This should be fairly
straightforward. Will work on the backend at some future date.
Ivan met with Johan and Frederik around how we should evolve pySAML and
how we should integrate the new microservices style into Satosa. Ivan
will work on the plugin loader module, simplify it, and use that as a
custom solution to hook in the micro services. Will try to have this
before the TIIME meeting, and at the TIIME meeting we can package some
of the micro services.
- pySAML (https://github.com/IdentityPython/pysaml2)
Ivan spoke with Frederik and Johan about pySAML, how to refactor. Will
trace the big function calls and see what makes sense, then move the
lower functions into new modules and build up on them. Have functions do
one thing only, do that one thing well, then use them to build more
complex functions. There will be a transition period. Example: XML
signing of objects. (Every XML operation will be in its own module. )
See PR 498.
PR 483 - MDQ verification. Ivan did some small changes today and then
merged it. It may still needs tests; Scott to follow up.
Also fixed: a deprecation warning.
PR 577 - being able to return error codes not listed in the spec; they
should be implementation defined, but we weren’t following the spec.
Next items of work: PR 518 (day/times) and 498 (XML handling)
Next week, Ivan will be in Amsterdam to meet about eduTEAMS.
- pyFF (https://github.com/IdentityPython/pyFF)
Leif still working on this; summary of work is splitting the discovery
service from the persistence service. Is going ahead with the flask
redesign. Also looking at pyramid (another python framework). There will
be an API to talk to the backend persistence service, which can be
hosted separately from the front end discovery service. Will continue to
offer the MDQ service.
Scott is using multiple discovery services and thinks that the discrete
list of possible IdPs should be handled in the backend, not the front
end. Scott and Leif need to talk about this; Scott will send email and
cc the list. Rainer has a similar use case, where certain services have
additional IdPs that need to be shown to a certain number of users.
3. AOB
TIIME meeting - Monday, 11 February 2018 @ 11:00-17:30; will have a room
for 10 people
Next call, 8 January 2019
Hi Ivan,
Can you consider PR 483 for the next round of pysaml2 work?
It has been around for about a year. Without it SATOSA cannot check the
signature of a reply from an MDQ server, and since SATOSA is often
deployed with pyFF for its metadata source this leaves a significant
security hole unless the patch is carried along (which I am doing for a
number of deployments).
I have recently rebased the commit on master so it should not be a lot
of work to merge it.
If you find something you don't like please let me know and I can fix it
up quickly.
Thanks,
Scott K
Notes:
Attending: Heather, Ivan, Roland, Jonas L., Davide
Regrets: Scott, Martin, Christos
0. Agenda bash
1. Governance update
Board has the kick off call today.
2. idpy developers meeting @ TIIME
- agenda building
Handling of micro services (Satosa)
Handling logging, esp. with plugins (Satosa)
Handling of XML (pySAML)
Action: Heather to ask Rainer about having a side meeting
3. PR review
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
Ivan has been working on changing the internal hashing mechanisms; it is
all backward compatible but you will get deprecation warnings (PR 196).
Now have a new micro service called “hasher”.
Also worked on OIDC frontend/backend and using self-signed certificates.
(PR 197)
eduTEAMS now only has one commit difference from main branch. (PR 182)
Ivan will be working on that soon so that eduTEAMS can be using the main
Satosa repository.
A new Satosa version will be released tomorrow; big change log.
- pySAML2 (https://github.com/IdentityPython/pysaml2)
Johan had two PRs regarding Unicode attribute values that needed to be
either encrypted or signed. There may be some refactoring of this in the
future.
Ivan is now working on PR 396, related to having the ability to specify
which signature or digest method you want to use (right now you can only
do that via the configuration file).
Martin has a new PR (556) around the internal attribute conversion
between names and friendly names. Ivan agrees with those changes and
will be merging soon.
Scott has added tests to PR 485. Ivan will be merging this soon and
cutting a release.
Some new issues have been reported. 555 suggests that we put every name
in the root name space, but that doesn’t quite work in real life.
XML and XML operations - Ivan had proposed we use a separate module to
handle XML operations, which would also allow us to switch XML back ends.
- pyFF (https://github.com/IdentityPython/pyFF)
Leif will be working on separating this code into more discrete
components (e.g., discovery will become separate).
- Governance docs (https://github.com/IdentityPython/Governance)
4. AOB
OIDC federations - would like to run pilots soon. There is a python
implementation, but that’s it. Would like to have Satosa be able to
handle OIDC federations. If there is a priority list of what will be
done soon, Roland would like to see OIDC federations high up on that
list. Roland has running flask instances for the RP and OP; it should be
fairly straightforward to do something. Not sure about the interface
between the front end and Satosa itself. Ivan would like to see this
too, though it hasn’t been prioritized yet. Note that Davide is also
interested in this effort. Suggest Roland and Ivan have a separate call
next week to discuss further.
Another project is underway within AARC that will depend on Satosa:
Evaluating assurance. Expect additional PRs related to this effort.
Attendees:
Christos, Johan L, Roland, Heather, Martin, Ivan, Rainer
Notes:
0. Agenda bash
1. Introductions (if needed)
2. Project review
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
Roland still waiting to hear from Ivan on creating a federation aware
front end to satosa; they will discuss at a f2f meeting next week.
Many things are on the list. Ivan has been working on the configuration
options, which have been intermixed with config options for pySAML. The
way we specify how we want to sign an assertion is also messes up with
the other options. Satosa should only dictate what values go to the
configurations and pySAML should handle the encryptions. Ivan will roll
out the small changes separately, then will later start deprecating the
current options in Satosa and only use the pySAML options. Ivan will
discuss this further with Johan.
After the options are sorted out, will work on logging (which will also
impact pySAML - want to use the same logger, using the same format,
throughout the whole stack).
Martin has an issue regarding creating a better, default/common template
for direct user interfacing. This starts again through pySAML and how it
handles exceptions; this needs to surface up to Satosa for
interpretation, otherwise Satosa doesn’t actually know anything about
this. Does Satosa actually need to handle the error, or can it just
present a static error page? Maybe. Rainer points out that SAML has an
error URL in metadata; it shouldn’t be the responsibility for a
transparent proxy to engage in user interactions. Ivan suggests that the
error should be in a JSON format that can be presented to something else
for handling (e.g., display or redirection, etc)
Instrumentation discussion: instrumentation is different than error
handling; it is more like log handling. Ivan will probably define
various stable things during execution (e.g., PID, statistics of system,
request ID) and then provide more context as things are processed. The
logging will (probably) be in JSON format. This is higher priority than
error handling. If we go forward with structured logging, we have more
options for monitoring the service.
- pySAML (https://github.com/IdentityPython/pysaml2)
PR 485 - may be able to do this in a more efficient way, but it works as
is. Ivan will likely refactor in a future release. In particular,
handling redirect binding request with Satosa.
Other small changes around general code quality, and updates on examples
to make them work with Python 3. It is a big question about moving from
Python 2 to Python 3 exclusively. Python 2 will no longer be updated
past 2020 (see https://pythonclock.org) Would like to reach out to
other projects using pySAML; there is something in GitHub
(https://github.com/IdentityPython/pysaml2/network/dependents) that
would help with this, but that list needs to be cleaned up. Can there be
a deprecation warning that appears during pySAML upgrades? Not sure;
Ivan will follow up. Alternatively, put a warning in the install log and
have the install fail, redirecting the user to another package.
PR 556 and PR 548 and Issue 549 - name handling. Ivan will be going
forward with this, but via a transition phase. Some changes will be made
to make warnings surface.
- pyFF (https://github.com/IdentityPython/pyFF)
Martin opened two PRs for pyFF last week. Reloading metadata, and fixing
the command line parser.
Leif is still working on splitting the pyFF code to separate the
discovery component from the metadata handling component.
Still hoping that Leif moves away from CherryPi to flask.
- Governance docs (https://github.com/IdentityPython/Governance)
Had the first governance meetings. No hard decisions yet, but hopefully
by the next meeting we will have decisions re: the CLA and the IPR home.
Notes are in the mailing list archive
(https://lists.sunet.se/pipermail/idpy-board/)
3. AOB
TIIME - Rainer has reserved a room for us.
Hi everyone,
PySAML2 v4.6.4 was just released and includes the long wanted
want_assertions_or_response_signed configuration option. See the
changelog[0] for details on the latest changes and try it out ;)
[0]: https://github.com/IdentityPython/pysaml2/releases/tag/v4.6.4
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
