[Idpy-discuss] maintaining pyFF server ability to serve multiple feeds for discovery

Rainer Hoerbe rainer at hoerbe.at
Wed Dec 12 05:27:14 UTC 2018

My current approach to secure the metadata signing key is to put pyff on a non-internet facing server, and have pyffd consume the signed aggregate from the public feed. MDQ is not being used, but that configuration would support MDQ with presigned entities. Besides the central list-all IDP-ds we have local customized lists. These select IDPs based on white-listing and add intranet-only IDPs.

IMU the planned split shall separate pyffd into a kind of business- and presentation layer, but the aggregator will remain, right? Therefore the aggregator's capability to consume other sources that an MDQ-service remains. It should be good enough to deploy another aggregator along with the IDP-ds to have the functionality of the pipelines to do filtering, validation and aggregation. This grouping of pyff with pyffd should solve both Scott’s and my requirements.

- Rainer

> Am 2018-12-11 um 15:58 schrieb Leif Johansson <leifj at sunet.se>:
> On 2018-12-11 15:36, Scott Koranda wrote:
>> 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.
> Yeah this is a requirement from multiple stake-holders so it is
> definitely going to be supported. You will point the central
> persistence service to multiple MDQ server backends basically
> but there are other options for achieving the same result too.
>> I guess more generally it would be nice to better understand your
>> roadmap for pyFF development.
> Right now I am starting work on a major "API-focused" refactor
> of pyff that will do away with all of the frontend code, including
> creating a separate "MDQ browser" application somwhere that could
> be used with other MDQ servers besides pyFF.
> I'm playing around in a separate fork right now and my current
> thinking is to create a parallell "pyff-api" server that will
> in time replace pyffd based on the pyramid framework. One of
> the side-effects is to move more of the config from cmdline
> to configuration files and/or environment variables over time.
> The new fork may retain the current frontend "bits" but depending
> on how well this is received they will either go away fast or
> more slowly (or not at all if I screw up). In any case pyffd
> will remain stable until we are comforable with "pyff-api"
> I'll also probably make it easier to run multiple versions of
> pyff in backend/frontend configurations (eg aggregating to a
> redis instance in a backend and serving dynamically signed
> objects from a frontend) each with separate pipelines
> 	Cheers Leif
> _______________________________________________
> Idpy-discuss mailing list
> Idpy-discuss at lists.sunet.se <mailto:Idpy-discuss at lists.sunet.se>
> https://lists.sunet.se/listinfo/idpy-discuss <https://lists.sunet.se/listinfo/idpy-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sunet.se/pipermail/idpy-discuss/attachments/20181212/eb608df0/attachment-0001.html>

More information about the Idpy-discuss mailing list