Attendees:
Johan, Ivan, Heather, John, Leif, Christos, Scott
Notes:
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Some activity between Jakob and Roland on the
b. Satosa - https://github.com/IdentityPython/SATOSA
Ivan has been creating a login helper for Satosa, getting rid of boiler plate around the logging, and have an internal logger that will do things more sensibly Most of this is ready, but he’s also looking at another library which might be more useful for internal logging. Stay tuned!
Scott made an improvement to the LDAP attribute store microservice. He was previously filtering for specific SP configuration, but has switched that to filter for any kind of entity. This is already something most other microservices also do. Ivan is considering whether the core Satosa should do this as well .
Scott also added a new merge request. (See email to the dev list). Proxy has many different entry points. One of the entry points is the response from the discovery service. We can actually send a response from the discovery service directly to the proxy without requesting authentication. This won’t work unless someone makes some special changes. Scott proposed a change that would enable the to be turned on or off. Ivan thinks we perhaps shouldn’t allow this behavior at all; there must be a target SP and if there isn’t one, we stop the process.
Next on Ivan’s list is redoing the way we handle paths. Right now, we have a base (a domain) and we mandate that all backends/frontends operate below that base URI. We cannot have a domain that also contains a path. The changes will allow this to happen (paths in the base URI), which will in turn allow us to do things like integrate the new OIDC front end while still running the old OIDC front end and differentiating between the two.
Will also be introducing the new config for the metadata end point.
eduTEAMS: how exceptions are handled - there is a global exception catcher, but it can raise an “unknown error”. Want to have an error URL; if that’s defined, we should redirect the user to that error page. That error page will show an informational message. This could work well with the outputs of the REFEDS Error Handling WG (note that the community consultation process for that doc is expected to start later today).
c. pySAML2 - https://github.com/IdentityPython/pysaml2
On a previous call, we talked about the GCM encryption family. Is still looking into that. Some discussion about supporting libxml, though we would need some wrapping for it. This looks like a good direction, but the transition will not be fast. Will want to split the network operations from other components.
Getting the algorithms in metadata an d prohibiting specific algorithms is of higher priority.
We want to verify that a signed request has been signed with a cert we know about; Roland has said this kind of verification is an experiment. It shouldn’t be part of the library.
d. pyFF - https://github.com/IdentityPython/pyFF
Focused more on the Thiss.io library. What’s on the roadmap right now is figuring out what to do with Scott’s PR around path naming. Also still working on moving to 2.0 and excising all the front end bits. Trying to figure out how to package of pyFF, or at least a frontend script, that will allow you to start components the way pyFF is put together today.
eduTEAMS is using the latest code where front end is split from the back end, and what they found was they needed a guide that offered the order of what they needed to do to set the pieces up. Need more documentation, and this is probably more important than backwards compatibility.
3 - AOB
Also in eduTEAMS, we have a proxy that talks to OIDC and SAML entities. Internally, we need a representation fo the metadata of those entities. If we have an MDQ, then the metadata is already there - we can get them from the file system or cached. For OIDC entities, though, that doesn’t exist. Would like to have a way to find out the metadata of OIDC entities and represent them in a common way in the proxies so they can be displayed somewhere (e.g., consent service). If you don’t need any of the cryptobits, then you can extract the metadata and turn it into Discojuice-formated JSON and dump it into a discovery service. pyFF is a SAML only thing; in SeamlessAccess, pyFF is used to aggregate and format metadata into JSON and dump it into a central MDQ. Sounds like they need multiple processors that will dump into a common repository.
This will become important when we have OIDC federations, though it depends on how OIDC federations will finally look like. But whether pyFF will fit that model is still an open question.
Attendees:
Christos, Heather, Johan, Scott, Ivan, Roland, John P, Hannah
Agenda:
0 - Agenda bash
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
General maintenance of code, otherwise pretty stable.
Suggest basing the API on https://www.sqlalchemy.org/ which should make connecting to a database much easier.
b. Satosa - https://github.com/IdentityPython/SATOSA and pySAML2 - https://github.com/IdentityPython/pysaml2
Giuseppe’s lxc container.
We are now creating multiple docker images when we create things in the docker repository. If there is a new version, we tag it, and if it’s the master branch, we tag it. But we always know what triggered building the image. If people want their own microservices in docker images, they need to build their own images. Ivan will build an image that contains all the microservices we have in the repository, but anything past that people will need to build their own.
Why build docker images at all? It helps deployers, and may bootstrap production. We could also create a dev-type image. Suggest we talk to the folks at Internet2 (Chris Hubing, Paul Caskey) about the TIER/Trusted Access Platform. See https://github.com/Internet2/comanage-registry-docker/blob/master/docs/simp… as an example.
Ivan has merged the PR for new SAML syntax.
d. pyFF - https://github.com/IdentityPython/pyFF
See roadmap in the repository
3 - AOB
• Possible memory leak with the LDAP attribute store - Scott has a few containers running (simple Satosa Proxies) that after running for 4 months that grew to 1Gb in memory. Restarting the worker process brought them back to normal. Christos is running a very old version of the LDAP attribute store and not seeing the same behavior. Ivan’s guess is that this is about how it’s handling connections.
Thanks! Heather
Hola a todos!
With the cancellation of the eduGAIN Town Hall, it seems best to go ahead and also cancel the T&I Hackathon on 23 March 2020. We will be trying for another one in the future, though the date and location are (obviously) TBD.
You are always welcome to code and submit PRs in the comfort of your own home, and the projects you’re interested in would most certainly appreciate it.
Thanks! Heather
Attendees:
John P., Giuseppe, Hannah, Roland, Scott, Ivan, Alex, Johan, Christos, Heather
Notes:
0 - Agenda bash
1 - Discussion
a. <NameIDPolicy> and <NameID> Format attribute
See discussions on slack.
There is a policy setting; you may want to request a specific NameID format from an IdP, and if you don’t define the config option, what happens? We can request a NameID format in an authN request, and we can advertise in metadata what NameID we support.
One thought (Ivan) is that it would be better not to advertise a NameID format, and only when you want a specific format to request it.
Alternatively (Christos), do not request anything during the AuthN request, and to list in metadata in preference order the NameID format you will support.
[Discussion] Should we leave this config option out, thus not setting the NameID policy at all? We should be able to set the NameID policy; there are use cases where we have to force this. Separating the two config options is a good thing to do. We need to set a NameID policy without a NameID. The string “none” is a hack. We can set some defaults, and if we need more complexity, it should probably be in a microservice. Christos points out that a microservice can’t do this because it’s at the wrong place in the workflow. The microservice architecture would need to be refactored.
Satosa defines an internal representation fo the data, and the microservices act on that. When something is defined we need to make sure it can be defined into something for the outgoing protocol; for NameID, at the point the microservices are requested, they don’t have access to the backend or its metadata. We would need to make a change that would allow some or all microservices to run at a different point.
If anyone has specific requirements here, please let Ivan know.
b. Custom syntax in YAML - https://github.com/IdentityPython/SATOSA/pull/316
A new tag that would allow us to specify an environment variable.
Use case: a deployment via docker swarm or kubernetes, and it is convenient to inject secrets via environment variables into the containers. Was handled via entry point scripts. The YAML config files are in an open Git repository. This gets cumbersome. Scott implemented a first draft, and Ivan improved it.
Could we use py files instead of YAML files? This would work for pySAML2, but not for Satosa.
Ivan will think about this a bit more, and then either merge the code or figure out another way to do this.
Action item: Scott will improve the documentation (more examples would help)
Action item: Ivan to consider this further; code is fine if we go with the current syntax.
c. Shibboleth encryption algorithms
Use case: the Shib project has announced that as of v4 of the IdP, default will be GCM encryption. This can be changed either globally or per RP. There are many Satosa SPs that will need to be able to consume that default.
This is handled correctly for Satosa, but pySAML2 has two backends for encryption, and one uses xmlsec1, and the other on a python security library. With the xmlsec1, we generate the commands and run them from the xmlsec1 binary. Whether we can read/decrypt the GCM based payloads depends on what xmlsec1 supports. If your openSSL supports the GCM encryption, then xmlsec1 will support it as well, and everything should work correctly.
We do need to add the different algorithms to pySAML2.
Action item: Scott to open an issue against pySAML2 to help track this
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Will discuss at a future meeting (hopefully at the hackathon).
Roland will release new versions tomorrow.
b. Satosa - https://github.com/IdentityPython/SATOSA
i. New release (v6.1.0) - https://github.com/IdentityPython/SATOSA/releases/tag/v6.1.0
Contains a new middleware dependency that takes care of the SameSite cookie issue. It sets the SameSite attribute to none. Note only Python 3.8 and newer are the only ones that know about the SameSite attribute. There is also a new dependency that takes that cookie, duplicates it, and removes the SameSite attribute; that means it sends two cookies, one with it set, one without. Clients that do not know what the SameSite attribute are about will drop it, and ones that do will have it. Satosa only cares about the cookie it sets itself.
Deployer will need to define the configuration that takes the cookie name and the holdback name.
See example: https://github.com/IdentityPython/SATOSA/blob/master/example/proxy_conf.yam…
SameSite attribute is set here: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/state.py#L50
Monkey patch: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/cookies.py#…
Release also includes a fix for sessionID. This comes out of some of the updates to logging. The sessionID is now part of the state, not part of where the logs happen.
Now set pySAML2 to v5 or newer, in response to a security vulnerability that was patched in v5
c. pySAML2 - https://github.com/IdentityPython/pysaml2
d. pyFF - https://github.com/IdentityPython/pyFF
3 - AOB
Thanks! Heather
