3:59 p.m.
Attending
Ivan, Heather, Roland, Ed, Hannah, Alex, Scott, Christos
Notes:
0. Agenda bash
1. Hackathon planning - https://wiki.refeds.org/pages/viewpage.action?pageId=44959235
<https://wiki.refeds.org/pages/viewpage.action?pageId=44959235>
Currently about 24 people signed up; no sense of distribution.
Maybe have some “how to” stations to help people learn how to connect, how the various
software stacks work.
We do know there will be some people there specifically for thiss.io, some for OIDC
federation, some SimpleSAMLphp
For Satosa, should have a set up with a ready-made Satosa deployed, then look into how to
configure microservices, and develop new microservices. Also do something internal data
for Satosa. On the list, one suggestion was to see that the MFA profile passed from the
front end to the back end. That might be a good project.
Ivan is still planning to work on some machine images this week and other items in prep
for the Hackathon.
If anyone else has specific ideas of things to share or things they plan to prepare,
please let Ivan know.
There may be some work on pySAML2 as part of the integration with Satosa (see in
particularhttps://github.com/IdentityPython/pysaml2/issues/586
<https://github.com/IdentityPython/pysaml2/issues/586>)
For the OIDC Federation, there will be a couple of folks doing some java programming, and
hopefully the SimpleSAMLphp will join. Roland will have a server set up to work against.
Also has a few people interested in writing mobile clients, though they are not going to
be at the hackathon. Roland will also set up a server for them to test against on the web.
Giuseppe de Marco is working on an OIDC IdP implementation based on Django, though he will
not be at the hackathon.
2. GitHub review
a. pySAML2 - https://github.com/IdentityPython/pysaml2
<https://github.com/IdentityPython/pysaml2>
b. Satosa - https://github.com/IdentityPython/SATOSA
<https://github.com/IdentityPython/SATOSA>
https://github.com/IdentityPython/SATOSA/pull/252
<https://github.com/IdentityPython/SATOSA/pull/252> - (Scott’s PR) Doing things with
LDAP. Are just about at the point that this can be merged. Ivan suggests that we need to
normalize the attributes received from LDAP, which means removing the options part from
the attributes names and then map them to other attributes. Scott notes that the attribute
options need to remain; sometimes the attributes options are enumerated, sometimes they
aren’t, and how they are mapped will vary (but they must be mapped). That makes this all
fine, then, and the PR can be merged.
https://github.com/IdentityPython/SATOSA/pull/275
<https://github.com/IdentityPython/SATOSA/pull/275> - (Hannah’s PR) converting
logging to something different, to allow outputting of structured information. Ivan will
be merging changes as they come in. When we’re done, we will look at exactly what we log,
whether they are the right things to capture and if they help us enough in knowing what’s
happening within the service.
While Ivan was on holiday, discussed how to maintain state between back ends and front
ends (use cases, not solutions). Goal is to have access to the configuration of something,
like a microservice. Those values could then be used. This might be best dealt with by
using handles. We have multiple back ends and front ends, and if we say we want to have
access to those, there needs to be specific coupling. We will need to mimic interfaces
within the backend (which they don’t otherwise have). Better to communicate data than to
have functions be passed around, because the data can be served and be agnostic to the
things consuming them. They become the API. Given this data needs to be communicated
between requests, right now that means info has to be pushed into the state cookie.
Worried about the size of that growing over time, Need alternative ways to keep state. If
we use something like the web storage or the index db, then much of what we need to
transfer can be eliminated. If we could have context around configuration that could be
serialized, we could keep the state of that. Every time it is needed, it could be rebuilt
using the serialized state. (This would be a future architecture possibility)
https://github.com/IdentityPython/SATOSA/pull/275
<https://github.com/IdentityPython/SATOSA/pull/275>
https://github.com/IdentityPython/SATOSA/pull/273
<https://github.com/IdentityPython/SATOSA/pull/273> - before merging this, note
there are many common things between the way the OIDC services do things, and perhaps we
should have a base for the services.
c. pyFF - https://github.com/IdentityPython/pyFF
<https://github.com/IdentityPython/pyFF>
i. pyFF metadata downloads
d. …
3. AOB
Neils van Dijk reported a security issue.
The issue is with the handling of the redirect_uri. When a request is received, SatoSa
validates if the redirect_uri is valid semantically and is allowed as defined in a client
database.
If that is not the case, SaToSa shows an error page for example "Something went
wrong: Redirect uri 'foobar' is not registered"
However, in case the parameter contains e.g. javascript like
redirect_uri%3Cscript%3Ealert(%22hi%20SaToSa%22)%3B%3C%2Fscript%3E SaToSa does detect
correctly this is not a correct URI, but then continues to present the javascript on the
error page unmodified, hence executing the javascript.
Any other error in the url paramaters passed between rp and op should normally result in a
response back to the RP without any user screens involved, however as per
https://openid.net/specs/openid-connect-core-1_0.html#AuthError
<https://openid.net/specs/openid-connect-core-1_0.html#AuthError>, an issue with the
redirect_uri is the sole exception :(
I think SaToSa should always escape the html characters in the error message and perhaps
also detect e.g. the presence of a bracket as an illegal character.
Another security issue: Scott and Ivan have discussed that the default for the SAML
backend will consume the attributes without checking the scope. This might best be part of
the core in pySAML2, and keeps with the most conservative defaults as possible.