(This message has been automatically imported from the retired mailing list)
this is something that was preliminary discussed off-list but we’ve
moved it here so others can perhaps get involved.
The idea is to add more in the area of XML security. In particular, what
I would personally like to see is a simple means to encrypt, decrypt,
verify and sign incoming/outgoing messages.
Unfortunately, it is my sad experience that working with xmlsec bindings
in Python is a frustrating process. Last time I tried it I ended up
invking xmlsec1 in a subprocess
which was OK in that given situation because that particular SAML2
Identity Provider needed so much time to complete all the operations
that a fraction of second worth of overhead I introduced was something
In Zato though I’d rather not take this approach and would like to add
full support with GUI, enmasse, docs, examples and a clean API.
Ultimately, as with other security-related stuff a service would need to
be concerned with whatever way it was secured on a given channel. So if
someone creates a SOAP/XML channel, pick a ‘needs decryption, key name =
foobar’ flag, the service will simply receive the payload and everything
will be taken care of by Zato itself.
For people who need to access raw requests, API along the lines of what
is here would be provided
Can you please suggest what libraries to use?
These are the ones I’m aware of
Tried it Sep 2012, could not get it work but I can see there were new
releases since then
Never used it but I know the author is a sharp fellow
Never used it but I know the author is subscribed to this list
If someone was willing to contribute these 4 standalone functions
(if it’s better not use strings but some other objects, like BIO, feel
free to suggest it)
I’d be very happy to plug them into Zato - I’d add key aliases so you
can update keys from browser/CLI/API, GUI to assign security to
channels/outconns and generally, would make Zato take care of how to use
I just wouldn’t discourage any potential contributors by saying the full
stack must be updated, I can happily do it myself.
A thing to keep in mind is that everything must support
Ubuntu/Debian/Mind/Fedora, OS X. Also RHEL/SLES. And Windows with time.
In other words, this should need as little SWIG magic as possible,
preferably should be as self-contained as possible.
About RHEL/SLES/Windows -> these systems will have fat installers
anyway, all pre-compiled dependencies will be bundled along but whatever
library/libraries will be used, they must work on Linux, OS X and Windows.
What do you think?