Skip to Content.
Sympa Menu

en - RE: [sympa-users] Restricting SOAP access for application users (patch)

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Steve Shipway <address@concealed>
  • To: "Goltz, Immo [Extern]" <address@concealed>, "address@concealed" <address@concealed>
  • Subject: RE: [sympa-users] Restricting SOAP access for application users (patch)
  • Date: Wed, 29 Oct 2014 21:28:01 +0000

I think that the existing Sympa SOAP also allows connecting using a real user account, as well as using an Application account; as well as creating an authenticated session key to use in future calls.  The main difference is that with an Application account, you can allow it to specify which user email it uses to authorise the actions.  An application authentication is useful for automated systems that need to maintain several lists and manage membership when an External Datasource is not an option.

 

There are a few function missing from the Sympa SOAP; such as being able to modify list configurations, modify user settings and passwords, resynch external data sources, delete all list members, bulk load of subscribers, and custom functions.  Which new functions did you add to your interface?

 

Steve

 

Steve Shipway

address@concealed

 

From: Goltz, Immo [Extern] [mailto:address@concealed]
Sent: Wednesday, 29 October 2014 10:42 p.m.
To: Steve Shipway; address@concealed
Subject: AW: Restricting SOAP access for application users (patch)

 

Hello Steve, hello SOAP users.

 

In our environment we use Lyris Listmanager via SOAP. We want to migrate to Sympa, but it's SOAP interface does not match our needs.

After some investigations I decided to write a new one. It uses the excellent XML-Compile-* modules, thus I was able to follow a contract first approach with standards confirm xsd/wsdl. The Sympa logic is based on Sympas SOAP module and added many functions from Web-GUI.

Mayor difference is, authentication is based on WSS using a real user. Authorization is done for this user via the check_list_authz, is_listmaster etc. calls. So we have no trusted application approach but a interface which could be used by any user like the other interfaces.

Maybe this is a special use case and only useful in our simple environment or I missed some vital (security) points. But I think it is compatible with Steve's use cases. Our tests run well so far and I am happy to share this alternative SOAP interface after some needed clean up.

 

Immo

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.19+.

Top of Page