Hey,
Sorry for the crosspost...
After a few weeks of spending all of my available development bits on
the various parts of RA21 (cf github.com/TheIdentitySelector, yes its
all nodejs!) I'm back to working on pyFF for a bit.
Here is what I have planned for in the quite near term:
1. merge the api-refactory branch which includes a pyramids-based API
2. merge documentation PR from Hannah Sebuliba (thx!)
3. tag and release the last monolothic version of pyFF
4. in HEAD which becomes the new 1.0.0 release:
- remove all frontend bits (old discovery, management web app)
- pyffd will now start pyramids-based API server
- wsgi will be available/recommended
- create a new "frontend app" as a separate webpack+nodejs project
- create docker-compose.yaml that starts pyffd (API) + frontend app
5. tag and release 1.0.0 thereby moving pyFF over to semantic versioning
After 4 it makes sense to talk about things like...
- new redis/#nosql backends
- work on reducing memory footprint
- pubsub for notifications between MDQ servers
- more instrumentation & monitoring
- adaptive aggregation for large-scale deployments
- elastic search
- management APIs for integrated editing of local metadata
- OIDC
- generating offline MDQ directory structures (cf scripts/mirror-mdq.sh)
Thoughts etc are as usual welcome.
Cheers Leif
Hi,
I would like to hear opinions about (rejected) Satosa PR #237. Can we put this on the agenda?
Today I can talk only the first 20 minutes and will switch to listening only afterwards.
Cheers, Rainer
> Anfang der weitergeleiteten Nachricht:
>
> Von: Rainer Hoerbe <rainer at hoerbe.at>
> Betreff: Granular Logging control
> Datum: 14. Juli 2019 um 22:04:55 MESZ
> An: satosa-dev at lists.sunet.se
> Kopie: Ivan Kanakarakis <ivan.kanak at gmail.com>
>
> If would like to discuss a logging feature that I would like to see in Satosa. I proposed with PR 237 to add a log filter that would enhance satosa's logging capabilities. Ivan rejected it for the (in general good) reason that the proxy should log everything and log processing should be external.
>
> I agree in general, but there are bits where I still think that they would be useful in satosa. These are:
>
> 1. In production environments it is unlikely to push the full set of debug information to a logging service. However, it might be useful to get debug level data on certain selections. Usually that would be based in IP addresses, which should not be too complicated to implement.
> 2. In a dev environment one is easily inundated with debug data. Shibboleth has a nice feature providing logging levels for certain aspects, such as XML tooling, SAMl message de-/encoding. I find this capability quite useful, because in my dev environment I do not have an elaborate log processor. Attribute configuration in satosa could be helped by selected messages.
>
>
> If done properly, this change has following impact on all modules that instantiate a logger:
> 1. refactor the satosa_logger wrapper back to the native logger with similar signature
> 2. add a log filter after each get_logger()
>
> The logfilter (logging.Filter) is orthogonal to structured logging, or may even help to improve it.
>
> see: https://github.com/IdentityPython/SATOSA/pull/237 <https://github.com/IdentityPython/SATOSA/pull/237>
>
> Cheers, Rainer
Hola a todos!
We have a call on the calendar for tomorrow, 9 July 2019. This will likely be a fairly informal call.
I will be unable to attend, but I strongly encourage those of you who can make it to talk about Satosa/pySAML2 items, and to talk about what to do at the upcoming Hackathon (https://wiki.refeds.org/x/AwauAg)
Thanks! Heather
Hi everybody,
I'm happy to announce the first release candidate of a new OpenSource
Identity Provider called uniAuth, built on top of pySAML2 and Django
Framework.
https://github.com/UniversitaDellaCalabria/uniAuthhttps://uniauth.readthedocs.io/en/latest/index.html
First of all I want to thanks Identity Python initiative, for giving us the
tools to build something useful, with adequate adherence to standards.
I had a lot of fun in developing it, now it's time to share and to fill up
curiosity topics about any usage or implementation questions if they come,
thanks a lot and hear you back soon
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496945
e-mail: giuseppe.demarco at unical.it
--
------------------------------------------------------------------------------------------------------------------
Il banner è generato automaticamente dal servizio di posta elettronica
dell'Università della Calabria
<http://www.unical.it/5x1000>
