On Tue, 29 May 2018 at 16:50, Heather Flanagan
<hlflanagan at sphericalcowgroup.com> wrote:
Attendees:
Heather, Ivan, Scott, Roland, Martin
Notes
0. Administrivia
* governance status
* side meeting during TNC2018? No.
I will be at TNC18. If enough people are there, maybe we can schedule a meeting.
* Ivan now has a contract. Yay!
* Heather to take the action to respond to Niels question re: IPR
* June 12 call cancelled; next call will be June 26
1. Satosa
-
https://github.com/IdentityPython/SATOSA/pulls
Not much progress on things. Note that Ivan will work with pySAML2 first
in order to get some functionality in, then will work on Satosa.
Regarding existing pull requests, we have discussed most of them.
* 182 is related to what eduTEAMS wants to do, introducing sessions into
I think it is part of the LS-AAI pilot.
Satosa. This changes the role of Satosa a bit, so
would like to have
more discussions around that. Note that this will imply also adding some
form of UX that allows the user to indicate whether they are ok with
their information being stored (that they want SSO).
* PR from Martin in the micro services repository
(discussed last call)
has been merged. This will break some functionality until other
components are updated
The consent microservice has been updated in both places ;) Users of
the consent microservice should update both satosa_microservices and
the consent service itself.
This relates to the last subject - handling of the microservices
repository. We should provide a way to make such changes be part of
the same upgrade process.
Ivan does not consider Satosa stable; there will be
breaking changes.
Perhaps it would be worthwhile that we have a tag that snapshots the
state right before the breaking change so reverting to unbroken code can
be fast. Will also be using semantic versioning.
I think that we will need to break things. This will come in different
forms - changing the logging, refactoring pysaml2 and its
configuration, etc. Ofcourse, breaking changes will be discussed,
marked, announced and releases will be provided before each breaking
change.
Satosa is also going to be critical for upcoming
OIDCre pilot
federations. Need to consider that when planning breaking changes.
Ideally, breaking changes will happen sooner rather than later. Use of
Satosa will increase. OIDC front end of Satosa will have to be redone;
Roland has code.
That is right. I am not going to break everything right now; but it
will happen eventually. We are also not going to do that in a single
release - it will come gradually.
In Satosa, we have a metadata key that signs the
metadata. Not sure why
we use a different signing key for that than we would use for signing an
authN request? Should we sign the metadata by default? By itself, it is
not a security measure, but it is one more thing we can do.
Signing the metadata has value when one relies on the public key alone
being the dominant source of trust. If all the other party has and
trusts is your public key, then signing the metadata makes sense as it
allows the trust chain to progress into trusting the endpoints that
are advertised, and so on.
I noticed this when working with the demo eIDAS implementation from
the EU. It is a requirement to have signed metadata, but the signature
is checked against the key that has previously been exchanged and is
the same key that is used for other verifications (ie Authentication
Request signature verification) - it cannot be a different key.
SATOSA allows one to define a different key for signing metadata,
which is used to sign the metadata for both the backend(s) and the
frontend(s). This does not seem very helpful. We should provide a
configuration to indicate whether the metadata needs to be signed, and
that should be configured separately by each (front/back-end) module -
iow, it will be part of the pysaml2 configuration.
3. pyFF
-
https://github.com/IdentityPython/pyFF/pulls
Need Leif here for this.
Martin has long standing PR with cherry pie (
https://github.com/cherrypy/cherrypy/pull/1692) and that isn’t getting
any attention. It really breaks pyFF if you don’t fix this. Suggests
people on this call add a comment to that issue and ask the maintainers
to fix it. May end up switching to flask, but work on that has been
postponed as Leif works on RA21.
So, I looked into this cherrypy issue. From what I understand, what we
would like to happen is [...]
CherryPy conflates the logic that assembles the body of a request and
the logic that stores that request in the cache.
4. Other repositories (depending on who's on the
call)
* Microservices as a separate project? This is fairly complicated.
Perhaps a separate repository for every micro service? Example: a
breaking change in one micro service may not break all micro services,
so versioning a single micro service project becomes challenging.
Alternative: split a micro service into its own repository, and then the
file in the micro services repository will just be a glue file. No
decisions made yet.
We have had discussions about this before:
https://lists.sunet.se/pipermail/satosa-dev/2017-November/000128.html
https://github.com/IdentityPython/satosa_microservices/issues/10
As I said, I am in favour of a proper plugin system, and splitting
each plugin to its own repository. This needs some planning and
experimenting.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3