Attendees
Roland, Ivan, Heather, Johan, John, Scott, Christos
Notes:
1 - GitHub review
a. OIDC -
https://github.com/IdentityPython (JWTConnect-Python-OidcRP,
JWTConnect-Python-CryptoJWT, etc)
Libraries are progressing. Last time, we talked about the abstract storage interface.
Working on getting the whole stack to use that. The goal being to start two OPs at the
same time, sharing the data (and the workload). Roland has heard no comments on the
design, and so is moving ahead. Ivan’s thoughts are that he might have chosen a simpler
API himself, but overall this works.
After this, we can get into scopes per RP.
b. Satosa -
https://github.com/IdentityPython/SATOSA
Still needs to work on writing down his thoughts on the overall architecture for idpy, as
well as for the specific projects like Satosa.
Currently looking at working with the WSGI interface. When a network request comes in,
before it gets to the apps, it must go through different middleware layers. The goal is to
make this a first-class concept in Satosa, with a new config option about what tools will
run those layers.
Logging: Looking to use the bind interface, so when we switch to stratlog, we will be
compatible with that interface. The middleware will create or get the sessionID and that
will be used throughout Satosa, and will bind it to the logger. We want to have a single
logger or dictionary that will be added to the logger output every time the logger is
invoked. That data needs to be available through the flow, and then needs to be cleaned
when it leaves the proxy. That will be done through a middleware as well.
Scott offers a rough use case where there might be a need for a change in the format of
the sessionID. It might be helpful if this can be reconfigured on the fly. If the
middleware objects are exposed such that they can be accessed by other objects or
components, that might be helpful. Ivan suggests always run the default one, and have
code in the middleware (not the microservice) that says if certain conditions are met, to
overwrite the sessionID. Ivan will consider this further.
Ivan is also looking at doing some more error handling, and redirecting to different
pages. If we have the concept of middlwares, we can have the global handler that handles
all the exceptions, fills up a WYSGI parameter, and then uses appropriate middleware to
handle. This way, the user can decide how the error needs to be handled. This will improve
the levels of flexibility for how the whole system behaves.
There are also some merge requests that Ivan still needs to look at.
c. pySAML2 -
https://github.com/IdentityPython/pysaml2
Merged the fix for the ID attribute names (decrypt, encrypt, sign, or verify). This has
been a merge request for a while. We can probably iterate on this idea some more, like how
to find the node that holds all the signing or encryption information.
Also planning to accept the merge request on giving the namespace prefixes proper names.
(
https://github.com/IdentityPython/pysaml2/pull/625)
Ivan will be looking into refactoring how we select algorithms, and how we can select
default ones. Right now, SHA-1 is hardcoded, after the next release.
Issue about the scopes on the attributes: this was filed on the Satosa repo, but it is
probably a pySAML2 that will be doing this for Satosa.
(
https://github.com/IdentityPython/SATOSA/issues/297)
d. pyFF -
https://github.com/IdentityPython/pyFF
n/a
2 - AOB
Note that work will be starting on the eIDAS front end code.
Thanks! Heather