Soliciting SAMLtest Logging Ideas
Nate Klingenstein
ndk at signet.id
Mon Mar 18 12:01:08 EDT 2019
As the usage of SAMLtest has grown, so too have the logs and the number of use cases that people want to be able to address. This growth has been both faster and more wild than I had anticipated, with everything from traditional initial provider setup validation through signature implementation and AuthnRequest via Artifact.
In order to accommodate all the needs of those testers, the logs had been and current are cranked up to 7. Now that so many providers are using it, I'm growing concerned that, right now, the logs are too verbose to scroll through to find your own test.
You are the users and thus the arbiters of what you need to see, so if you have a moment to mail me on- or off-list about your logging opinions, I'm eager for your feedback. The options I'm currently considering:
1) Squelching more categories that detail entirely internal processes to SAMLtest
2) Turning everything up to INFO, possibly losing valuable background information on errors in the process
3) Adding a separate appender and log with a "I <3 base64" button that logs everything on DEBUG or even TRACE and also captures logs for things like Santuario for the few testers working on their own signature and encryption.
4) Your creative solution here
UItimately, if we get up to too many providers, I'm going to have a shared mounted volume for metadata storage and multiple nodes for the front-end with very high session affinity, effectively sharding the providers and logs out to multiple servers to decrease the visible clutter to any particular user while maintaining a single repository of metadata.
Thanks for your help,
Nate.
More information about the users
mailing list