(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
(Not sure how I missed sending these out; sorry about that!)
Attendees:
Ivan, Matthew, Heather
Notes:
0 - Agenda bash
1 - Administrivia
Note that GÉANT has a tender open for idpy developers. No public link, but if anyone knows anyone that might be interested, a job description has been posted to the #random channel on idpy slack.
2 - Documentation
FAQ vs in-line documentation in the code. The FAQ idea of using responses in issues was very disorganized; Heather spent some time on that and found them not very useful. The in-line doc as they stand today aren't sufficient. The functions aren't documented sufficiently to actually tell someone how to use them. But if we do add the how-to to the doc string, they'll be too long. Ivan sees the separation being "what it is" is in the doc string, but "how to use it" should be in a different place.
Even with the idea that the doc strings being just descriptive, they are falling behind and are not complete.
Matthew points out that he's having to read a lot of source code to figure out how to implement the code. This works well enough for him, but it's hard to teach reverse engineering to new developers. There is good example code out there, but there are places where he doesn't even know he needs to go look at the sample code. What would like to see online is everything: how to use it and the reference material (deep dive on function calls).
We have a short configuration how-to (how to build a small SP or IdP) but it's very basic on readthedocs.io. We could create a list of what we want to display there (e.g., how to create a custom SAML response, how to validate a signature, how to create a SAML request, how to get custom metadata). Part of the answers to those are in the Issues and PRs, and some are in the code itself. We'll need to improve the code (doc strings) at the same time. Let's start with a small list (see examples above).
Ivan is also working on a few small documents: release.md, security.md, developers.md, contributing.md. These answer things like how to create a release, how the code should look, what tools we use, what the doc strings should look like, how to write tests, how to report an incident, where the security policy is located.
See https://docs.github.com/en/repositories/releasing-projects-on-github/automa…
For additional documentation, create a new file here: https://github.com/IdentityPython/pysaml2/tree/master/docs
This will create a new page on readthedocs.io and we can crowdsource answering the questions. Need to use the .rst format. Start by just adding the files to the top level; we can reorganize into folders later.
3 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
b. Satosa - https://github.com/IdentityPython/SATOSA
How should we announce the new docker container? The old repo is still around; should it be removed?
Matthew will draft text for the announcement; aim to post on the website and post in an email. Ivan will point to the official images in the repo.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
d. Any other project (pyFF, djangosaml2, etc)
4 - AOB
Thanks! Heather
Hi,
I'm looking for a way to map the SAML2 NameID to an attribute so that I
can use its value in the response generated by the frontend. In my use
case, different SAML2 IdPs might want to send the user identifier in
different attributes *or* in the NameID, and I want to pass this
information on to my application that is connected to the frontend. I
think I can not do this with the current attribute mapping code, because
it only works on attributes, and the NameID is not an attribute.
What is the best way to achieve this?
(I'm considering to perform the inclusion of the NameID only if the
NameIDFormat is something reasonable to use as a user identifier, but
first I need to get hold of the value on the frontend side.)
Thanks,
Kristof
Hello everyone,
I have a problem with a "idp hinting" feature. I set in SP a SAML
AuthnRequest url, e.g.:
https://proxy.example.com/Saml2/sso/redirect?idphint=https%3A%2F%2Fidp.exam…
I have SATOSA 8.1.0 with a Discovery Service:
https://service.seamlessaccess.org/ds/ and a configuration of idp
hinting:
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/micros…
In satosa saml backend are metadata from eduGAIN. (For this example I
changed domain to "example.com")
After authentication request in SATOSA log is:
[2022-07-26 14:09:40,711] [ERROR] [saml2.request._verify]
https://proxy.example.com/Saml2/sso/redirect?idphint=https%3A%2F%2Fidp.exam…
not in ['https://proxy.example.com/Saml2/sso/redirect']
[2022-07-26 14:09:40,711] [ERROR] [satosa.base.run]
[urn:uuid:1f970493-c436-4d86-83a5-88162a2ca2a1] Uncaught exception
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
240, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
180, in _run_bound_endpoint
return spec(context)
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line
100, in handle_authn_request
return self._handle_authn_request(context, binding_in, self.idp)
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line
195, in _handle_authn_request
req_info = idp.parse_authn_request(context.request["SAMLRequest"],
binding_in)
File "/usr/local/lib/python3.6/site-packages/saml2/server.py", line
244, in parse_authn_request
signature=signature)
File "/usr/local/lib/python3.6/site-packages/saml2/entity.py", line
1080, in _parse_request
_request.verify()
File "/usr/local/lib/python3.6/site-packages/saml2/request.py", line
157, in verify
return self._verify()
File "/usr/local/lib/python3.6/site-packages/saml2/request.py", line
144, in _verify
raise OtherError("Not destined for me!")
saml2.s_utils.OtherError: Not destined for me!
[2022-07-26 14:09:40,712] [ERROR] [satosa.proxy_server.__call__] Unknown
error
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
240, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
180, in _run_bound_endpoint
return spec(context)
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line
100, in handle_authn_request
return self._handle_authn_request(context, binding_in, self.idp)
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line
195, in _handle_authn_request
req_info = idp.parse_authn_request(context.request["SAMLRequest"],
binding_in)
File "/usr/local/lib/python3.6/site-packages/saml2/server.py", line
244, in parse_authn_request
signature=signature)
File "/usr/local/lib/python3.6/site-packages/saml2/entity.py", line
1080, in _parse_request
_request.verify()
File "/usr/local/lib/python3.6/site-packages/saml2/request.py", line
157, in verify
return self._verify()
File "/usr/local/lib/python3.6/site-packages/saml2/request.py", line
144, in _verify
raise OtherError("Not destined for me!")
saml2.s_utils.OtherError: Not destined for me!
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/satosa/proxy_server.py",
line 148, in __call__
resp = self.run(context)
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
258, in run
raise SATOSAUnknownError("Unknown error") from err
satosa.exception.SATOSAUnknownError: Unknown error
Do you know the solution of the problem?
Best Regards,
Marcin Miłek
Hi all,
Is anyone planning to attend TechEx in December? If so, would there be any interest in an idpy workshop?
Thanks! Heather
---------- Forwarded message ----------
Date: Jul 5, 2022, 11:29 AM -0700
To: request(a)internet2.edu
>
> Colleagues,
>
> Please consider this the ‘official call’ for pre- and post-2022 Technology Exchange Tutorials and Workshops, to be held in Denver, December 5-8, at the Sheraton Denver Downtown. Please take a few minutes to read the information below before submitting.
>
> Submission Deadline: Friday, July 15
>
> TERMS: For the purposes of Internet2 Anchor Events, we consider:
>
> • Tutorials: to be any gathering that is instructional in nature and often offers hands-on training (i.e., attendees take knowledge away vs. providing advice or expertise), often
> • Workshops: to be a gathering where the attendees engage in intensive discussion and activity on a particular subject or project to reach a goal (i.e., develop best-practices or recommendations, further knowledge around a grant-funded project, etc.).
>
>
> As such, fees are collected on all Tutorials that cover AV, and refreshments for attendees. Fees for Workshops are collected only at the direction of the Workshop submitter, who agrees to be cross-charged for any AV, and refreshments provided if they exceed the fees collected!
>
> Tutorials and Workshops are different from working meetings (the call for which will go out in mid-July). Registration for all tutorials and workshops will be integrated into the Technology Exchange registration process so please respond by the deadline to ensure we have all the necessary information to set this up prior to going live.
>
> Please submit your requests for:
>
> Tutorials at: meetings.internet2.edu/portal/meetings/2022-technology-exchange/proposals/n…
>
> Workshops at: app.smartsheet.com/b/form/07e229b6efbd49858882b95352e7bb68
>
>
> IMPORTANT NOTE: Before submitting your request(s), please consider the schedule detailed below.
>
>
> • Tutorials, workshops, and co-located meetings begin on MONDAY, December 5; core days for track content and working meetings run from Tuesday, December 6 through Thursday, December 8.
> • NOTE: Advance CAMP content continues until 12 Noon on FRIDAY, December 9
>
>
> Space is allocated on a ‘first come first serve’ basis and is not guaranteed. We have space available on Monday, December 5 and very limited space on Friday, December 9. In order to avoid scheduling on any of the core days for track content, we MAY be able to offer limited space on Sunday afternoon, December 7.
>
> If you aren't planning a workshop yourself but know that a colleague outside of Internet2 is interested, please notify meetings(a)internet2.edu so that we may contact that individual and determine their workshop requirements.
>
> Thanks,
> Kelly
>
>
> Kelly Faro - Manager, Community Events
> Internet2
> 100 Phoenix Drive, Suite 111
> Ann Arbor, MI 48108
> kelly(a)internet2.edu
> (734) 352-7080 Office
Attendees
Johan, Giuseppe, Ivan, Heather, Matthew
Regrets
Scott, Roland
0 - Agenda bash
1 - Administrivia
a. Summer call scheduling - next call 9 August 2022
b. mailing list/website
Ivan fixed the mailing list links, but it highlights that we should think about how the website is organized and consider making it look more like a documentation website along the lines of an FAQ; we can have each question and answer as a PR to the website. Some concern that the answers may be complicated, which won't translate well to a website, but we can try this out and see how it looks. Giuseppe has opened several issues that we can experiment with. Developers would prefer this kind of documentation in documentation files rather than elsewhere, but we don't have a documentation site suitable for this (yet).
2 - Frameworks and Storage
Re: storage - can either treat this as a key/value store--this gives the users the opportunity to choose their own backend storage--or we can require specific storage and then take advantage of their features, thus tying us into specific platforms.
Re: framework - Ivan is leaning towards FastAPI; it is gaining in popularity and is light/flexible. We will use its tutorials on how to connect to a database. There are choices in the ORM space. This would prevent us from using Reddis.
3 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Need to consider having the develop branch as the default branch. Things are being merged to the wrong branch.
Roland is working on the refactoring of the RP code. Likely will see more work on this in September.
There are some PRs open around revocation and client credentials. For the client credentials, it's unusual because there is no user; the PR uses the client ID as the user ID.
b. Satosa - https://github.com/IdentityPython/SATOSA
Some new interest from people Giuseppe introduced at TNC22. Ivan has offered a list of where we need development assistance:
• Integration with some well known framework
• What I'm looking towards is FastAPI. Part of this work will be to redo how routing works.
• Being part of a wider community will automatically allow us to leverage existing tools, plugins and efforts but will also allow developers to work within a more familiar framework.
• improve observability
• Part of this work is to redo logging and introduce metrics. The idea to work on this through OpenTelemetry but parts of the python lib are still experimental.
• Schema for configuration and requests
• At the moment we rely on hand-written documentation which is not always updated. The idea is to introduce a schema for the configuration from which we can also generate documentation, tests, and additionally automatically load the files and derive the expected values with proper errors if something fails.
• Improve documentation
• Describe how the different modules work and how they all tie together.
• Add graphs and flow diagrams to convey the bigger picture but also certain aspects of the internals.
• Storage backend abstraction
• Introduce an API to hide communication with databases, the filesystem and the current storage we have, which is HTTP cookies. Along with that, the state handling should be revisited and maybe redesigned to properly cover the different usages.
AEGID (sp?) in Italy has started using Satosa to act as the proxy between Italian infrastructure and eIDAS.
Satosa image that Matthew created is going to be the default image.
Changes around the cookies have not proceeded yet.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Big changes coming up on formatting (not functionality). Important parts are the make file and config; will be using poetry. Expect to submit the MR in the next week or so.
pySAML2 includes XML templates via manifests. When we switch to poetry, we will need to make sure that these files are properly included.
re: the project to replace xmlsec1, Ivan is still working on that. Needs to write the tests for the new code.
pySAML2 is on the top 1% of packages downloaded from pypy.
d. Any other project (pyFF, djangosaml2, etc)
new djangosaml2 release earlier this month. Now compliant with latest releases of django; dropped some features that are no longer required. (https://github.com/IdentityPython/djangosaml2/releases/tag/v1.5.1)
4 - AOB
OIDF and idpy - is there an opportunity to share something wrt compliance testing around OIDC Federation?
https://github.com/oauthstuff/draft-selective-disclosure-jwt - Guiseppe has started contribute to this draft. Should we consider splitting the code in our documentation from the specification?
SSI work? Ivan still has the task to go through the requirements and consider how we can build a new library in idpy. Remember to review https://ted.europa.eu/udl?uri=TED:NOTICE:309685-2022:TEXT:EN:HTML&src=0 for the requirements of a reference implementation.
Thanks! Heather
