4:01 p.m.
(And now for today’s notes)
Attendees:
Johan, Heather, Ivan, Matthew
Regrets:
Scott, Roland
Agenda:
0 - Agenda bash
1 - Architecture
We talked about starting to look forward to the SSI stuff. This needs prep work to gather
the specs, setting out what projects we want to build, what projects we want to get from
others, and assemble the base layer so we can do things like evolve Satosa. This will
start to get into shape after the NORDUnet conference in mid-September.
2 - Documentation
(From Roland)
Could we at least agree on a layout, a set of chapters and in what order.
Maybe we could begin with deciding on who we are writing for.
Surely we will have readers that comes to us with different backgrounds/needs :
- An architect, who wants a birds eyes view over what the system can or can’t do
- A service provider, who wants a set of steps that will get a server running.
- An apps implementer who wants to know how to interface with the client API and use
Google/Github/.. as the OP.
- A developer that wants to add another endpoint/service to the system.
Matthew suggests we start with implementers, people who are trying to deploy apps that
need federated login help. The examples in the repo aren't sufficient to get there. We
need to make it easier for them to come in and user our tools. There's no obvious way
to make an IdP object. It's not clear how to use the classes and methods correctly.
Example: authentication context in an IdP response. Not obvious that he needed to provide
it in the first place, nor how to structure it (until he looked the source code itself; it
wasn't in the in-line help). What would be most immediately helpful would be adding
more detail to method doc-string. If we could do this, more people could increment the
immediate needs of documentation.
Ivan suggests our tools are low level enough that the current audience is people who
understand them, and that would be implementers. But if we build packages that integrate
with known framework, then that should shortcut a lot of documentation. They would use the
tools through the layer of the framework. The adapter is trimming the API space to a more
constrained set of default behavior. The rest of the things that can be done are not
there; to use those, you have to have a more in-depth understanding of the libraries, and
then we need the more low-level, developer-oriented documentation.
Johan agrees with Matthew that the smaller efforts will get immediate wins. Using the new
OIDC code is documented like the old code, which means it's wrong for the new
libraries. If we can focus on the functions, it'll be the easiest way to get something
done now.
Ivan - agree, we can start here then move into restructuring thing. One limit of focusing
on method doc-strings: We can tell what the function is doing, but it misses out on the
context of why the function is doing it. We need both types of documentation.
Let's focus on requesting doc strings updates and creating documentation for the
following questions:
• how to create a custom SAML response,
• how to validate a signature,
• how to create a SAML request,
• how to get custom metadata.
Matthew will work on documentation for the functions he's been working on most
recently (stuff he touched for the test IdP), create a small PR, and we can see how that
works.
Ivan: we could work on adding typing information. That will be complicated in pySAML2;
would need to be added in the code not the doc string. This is something Ivan is working
on, but it's slow going.
3 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP,
JWTConnect-Python-CryptoJWT, etc)
No update
b. Satosa - https://github.com/IdentityPython/SATOSA
• SLO - Hannah is working on this; has it working from the perspective from an SP. If an
SP requests a logout, that request will go to Satosa and back down to all the other SPs
someone is logged into, then back up to the originating IdP. There were some problems
getting the logout requests to all the downline SPs that support it, but those seem to be
addressed. Now working on the IdP-originated logout and cleaning up the code to submit a
PR. Will hopefully have a presentation about this ready next month (after NORDUnet
conference).
Architecture ideas for Satosa: we'd talked about switching to a more well-known
framework. That's probably going to be FastAPI. Along with that big change, we could
also take a few other decisions. Ivan is leaning towards using lxml exclusively (not the
built-in python xml parsers). We have long-standing questions about name prefixes. The
python built-in parsers rewrite whatever is in the xml document and put in their own
prefix. With lxml we can keep our own namespaces and treat them correctly. This helps
properly validating signatures. The schema validator we use is lxml-schema, and we also
use an underlying library called element-path. They are well made and useful and support
lxml, but they can fall back to the python built-in parsers. For other things we use, we
were looking to other python projects and how they choose their dependencies. There are
two communities providing useful tools:
• https://github.com/encode
• https://github.com/MagicStack
They are using encode/httpx library, which will let us use the async code (we don't
need it now, but will with FastAPI).
Ivan is working on a release for Satosa which will include a makefile. There are some
other MRs there, but the focus will be
on https://github.com/IdentityPython/SATOSA/issues/404 and https://github.com/IdentityPython/SATOSA/pull/405.
The way Satosa is built now does not support a path within the base domain you set; the
MRs associated with these issues should resolve that.
Another MR involves the ORCID IdP. That MR is making some things optional; Ivan is
investigating.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
The changes we talked about will impact pySAML2 somewhat, though users won't see much
of a difference.
Ivan released a new version (7.2.0)
- https://github.com/IdentityPython/pysaml2/releases/tag/v7.2.0 - no major changes. Mostly
fixes, additional schemas (e.g., for eIDAS). There is a new option for a timeout for
requests (see request module). Using cryptography to log certificates, which will allow us
to support chains of certs.
Working on switching to poetry. This mostly works, but still investigating how to include
schema files that are not python files. Also not sure how to update changelog notes
automatically. Maybe make this a requirement of PRs?
d. Any other project (pyFF, djangosaml2, etc)
4 - AOB
Have added documentation on how to submit new files to different repos on how to submit
code, security issues, etc. Also writing rules in the makefiles.
Thanks! Heather