Skip to content
Leif Johansson edited this page Apr 1, 2021 · 16 revisions

Key Concepts

  • pyFF is a SAML metadata processor.
  • pyFF can be used to fetch, validate, verify, sign, transform, store, index and search SAML metadata.
  • pyFF does its work by following small programs called pipelines written in yaml syntax consisting of steps/primitives called pipes

Deploying pyFF typically means figuring out what SAML metadata to fetch and from where, how to transform it to suit your metadata consumers expectations and needs and finally publish the metadata. All these steps are encoded in a yaml-file called a pipeline which pyFF executes like a program.

The pyFF execution model

The following diagram illustrates the relationships between the elements that make up the pyFF execution model.

  • a pipeline transforms a state to an object
  • the pyFF metadata store is updated using the load pipe and queried using the select step.

Most pyFF pipelines will contain at least one select statement and one load statement. The latter is used to fetch metadata (either local or remote) and the former is used to populate the active tree which subsequent pipes modify to form the resulting object. The object resulting from a pipeline execution (and indeed from each step in the pipeline) is often called the active tree because it is usually a SAML metadata DOM tree. However since some pipes transform the DOM to another type of object (eg to a JSON representation) the term active tree is discouraged.

The state is actually a dict-like object in the python sense. The state is used to represent things like the context in which the pipeline is executing or the expected form of the output (eg the Accept header when the pipeline is used to execute an MDQ request).

pyFF language primitives

There are two types of pipes built into pyFF:

  1. pipes that act on the active tree
  2. pipes that change the order of execution of the pipeline

The latter type are akin to language primitives in the pyFF programming language. These are all described in the API documentation. Here is a short summary:

  • pipe starts a sub- or child pipeline
  • when branches execution based on the presence and/or value of keys in the state
  • break terminates execution of a pipeline
  • end terminates pyFF
  • fork make a copy of the active object and execute a child pipeline
  • map loop over all entities in the current select set