in my setup, SATOSA may listen on multiple interfaces/ports/vhosts, and
not all are accessible to all users. Therefore when sending the
authentication response, the IdPs must redirect the users to the
'correct' AssertionConsumerServiceURL. The problem is that the SAML2
backend always selects the first ACS address in the request
I'd like to select the ACS URL based on the host name of the request
(context["http_headers"]["HTTP_HOST"] specifically). What do you think
about it? Would you consider such a pull request?
I'm still not entirely sure what to do if there's no match. I guess
Shibboleth SP used to specify the ACS URL in the AuthnRequest using
information from HTTP_HOST(?), since I remember seeing error messages on
IdPs when no AssertionConsumerServiceURLs in the metadata matched the
request. Even if I remember right, this might not be the best approach,
because I could think that it'd be more user friendly if SATOSA could
signal the error instead of the IdP, but this might be use case
What is exactly the relationship between the attribute name format and
the mapping within attributemaps?
I couldn't fully understand that part of the code, but empirically it
seems that only the 'last' mapping file is considered, so it's not
possible to have multiple files for the same attrname-format, only one
mapping per name format is allowed. If this is correct, then adfs_v1x.py
and adfs_v20.py being separate files is pretty misleading.
Also, the satosa tree contains a subset (I didn't verify, whether it is
a true subset or not) of the pysaml's default attributemap dir, what is
the purpose of that directory?
In my calendar there is an IdPy meeting today.
Heather said at the last meeting the she would not be able to make the one today, her being at a meeting in Amsterdam.
Unfortunately I will also be unable to make the meeting today.
Roland, Heather, Johan, Scott, Matthew
• session management code: session was defined as one users from one client having one authentication. Based on that and user consent we create a grant. eduTEAMS wanted client authentication with no user involved, so not an OIDC flow but an OAuth flow. They did this by using the client info twice, so Roland has changed session management to grant management, conducting sessions so there can be more clients, no users. Now needs to update the documentation; that's in progress (it's a mess).
• Getting closer to the final OIDC Federation specification. Authors are now meeting weekly to clean up all remaining issues. Roland is now working on implementing the latest version.
• Hannah still working on this. (see notes from last call)
• Are poetry and markdown going to be the standard tools/formats for all idpy?
• note that we may be able to use pandoc to convert documentation where necessary
• Matthew is working on the function documentation. It's not complete, but will submit a PR with what he has