4:02 p.m.
Attendees:
Matthew, Hannah Sebuliba, Ivan, John P, Leif, Roland, Giuseppe
Agenda:
0 - Agenda bash
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP,
JWTConnect-Python-CryptoJWT, etc)
Roland is currently working with SQL Alchemy some of the code base, starting with
CryptoJWT, and will be working his way up the stack. A request has come in to make this
more a general interface that will support more databases. Next problem is around messages
and message instances - according to the spec, you should always expect attributes you
don’t know about and you should accept them. SQL Alchemy requires you know all the
attributes.
What about the device flow? It’s not hard to do; has done the client part, but no the
server part.
b. Satosa - https://github.com/IdentityPython/SATOSA
More on error handling (see Giuseppe’s PRs, mentioned in Slack)
This needs to be more modular and separate from the core code.
What happens is, when Satosa sees a request, it parses and figures out the right thing to
do. When things fail or an exception is raised, then the exception is logged or it is
unhandled and things crash (though we have a global exception handler that should prevent
the latter). Instead of logging and resuming, want to delegate the action to another
function. This function is something that the user needs to provide. We can have a default
behavior, but the user needs to be able to override that.
What Giuseppe has done (and eduTEAMS) is to catch the exception and redirect there. But we
may want to do more than redirect. So we need to have the flexibility to define both a
default and a config option. Could implement the Error Handling WG functionality as an
option and let users pick what they want. We could also use this to communicate to
external services so they can render nice error pages.
What information do we give to this function to convey the right information to the
external service? How do we collect the context and pass it in a unified interface?
Giuseppe suggests just title, message, description.
Otherwise, still need to get to the refactoring of how we handle paths. We have regularly
encountered a problem where pySAML2 converts everything into a friendly name, and this has
impact on Satosa. When an SP has requested attributes in its metadata, they don’t match to
what Satosa has internally (canonical name vs friendly name). This will impact both
internal and external attributes. We’ll eventually make these changes mandatory.
Roland is looking into SQL Alchemy. We’ve gotten away from having state in the proxy, but
we do need state for the OIDC front end. If we need to keep state at some point, we should
probably be doing it through SQL Alchemy. We should look at what happens with MongoDB and
Alchemy to make sure everything is supported. If it isn’t, we need a migration path. Is
the data that you want to store inherently relational? If not we don’t need a relational
database. Would an API be a better approach, implementing a simple state API? Unsure what
would be best as we don’t have the actual use cases at hand.
Ivan and Roland both will consider this further.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Will get to this on our next call.
d. pyFF - https://github.com/IdentityPython/pyFF
pyFF and the accept header (Scott)
Two related issues - if you have a compliant client doing MDQ, then it will send an accept
header of application/SAML metadata + XML. If it is going to be a compliant response, then
you have to get a single entity descriptor as a wrapper. Scott was getting a multiple
entities descriptor, which was rejected. This may just be a configuration problem. Some
updates need to be made to the documentation .
Related: pyFF tries to be helpful in that it wants to be generous in what it accepts, so
when you send in a different header, it wants to do the right thing. In addition, it lets
you append to the entity ID a type, like a .xml to help guide pyFF re: what you want in
return. The problem is, there are a few SAML entities in eduGAIN whose entityID ends in
“.xml” and so pyFF decides to drop the .xml. How will pyFF decide on the content type if
you remove this functionality? This can be part of the pipeline configuration. pyFF is not
just an MDQ service - it’s to handle whatever you want to do with metadata.
It would be nice if the docker file for pyFF could take a build argument, and when it saw
that, what you’d get was a preconfigured docker image that knows how to one thing: be an
eduGAIN MDQ server that’s compliant. Leif will work on that.
WRT the JSON part, we can request a json representation, but it’s not a 1:1 list of what’s
there; there is no json profile for the metadata. This profile was defined only
unofficially twice: in Discojuice and in Thiss.io. Do we want a complete json
representation of the metadata? Is there a use case for it? There is a use case around
defining the UI elements. We still don’t do i18n properly; definitely more to be done
there.
It’s worth considering how to start a discussion about a JSON UX metadata format. Who
should be involved in that?
3 - AOB