December 2018 - Idpy-discuss

maintaining pyFF server ability to serve multiple feeds for discovery

by skoranda＠gmail.com

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

6 years, 2 months

3
3
0 0

pyop id_token enrichment

by martin＠surfnet.nl

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

6 years, 2 months

1
0
0 0

Notes: idpy developers meeting, 11 December 2018

by hlflanagan＠sphericalcowgroup.com

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

6 years, 2 months

1
0
0 0

Agenda: idpy developers call, 11 December 2018

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 11 December 2018 Time: 14:00 UTC https://bluejeans.com/655841213 Agenda: 0. Agenda bash 1. Governance update 2. PR review - Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA) - pySAML (https://github.com/IdentityPython/pysaml2) ** PR 483 - pyFF (https://github.com/IdentityPython/pyFF) - Governance docs (https://github.com/IdentityPython/Governance) 3. AOB

6 years, 2 months

2
1
0 0

pysaml2 PR 483 for signature checking on MDQ

by skoranda＠gmail.com

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

6 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss December 2018