The mailing list for listmasters using Sympa

["Goltz, Immo [Extern]" <address@concealed>]

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

 

 

Von: address@concealed [mailto:address@concealed] Im Auftrag von Steve Shipway
Gesendet: Mittwoch, 29. Oktober 2014 05:08
An: address@concealed
Betreff: [sympa-users] Restricting SOAP access for application users (patch)

 

I have a problem with the current level of access control for trusted applications in SOAP.

 

When you use SOAP access with a trusted_application user, you can specify proxy_for_variables to define which variables the application can set.  If one of these is USER_EMAIL (which it has to be to do anything useful), then you have effectively given the application full listmaster privileges, as it can then impersonate any user it cares to.  The other option is to use a normal account, which is fully restricted, but this requires you to have local authentication enabled – plus, you have to create multiple of these accounts for multiple applications, and grant them all privileges.  In addition, you lose the ability to use [remote_application_name] to control access in scenari, and setting passwords for an invalid email address is difficult.

 

My suggestion is to enhance the trusted_application stanza with a set_variables definition.

 

This allows you to have “set_variables address@concealed” to force a given application user to be treated as equivalent to that user for access rights (you can also force-set other variables in the future if you wish).  The application user now has rights equivalent to address@concealed; however further application_name tests can be done in scenari if necessary.  You can also have multiple trusted_application stanzas (with different passwords) that link to the same user account in Sympa, allowing you to more easily maintain access to multiple lists.

 

Use case –

-          We want to have multiple applications with SOAP access, on separate passwords

-          They need to be able to maintain subscribers for specified lists

-          They must not be able to create or delete lists

-          We must be able to easily add or remove application accounts or change their passwords

-          They must not be able to modify other lists

By having multiple trusted_application definitions, and linking them to the same dummy account (e.g. address@concealed) we can control the access rights.  A special include.create_list.header scenario adds a test to deny this account creation privileges (though other users have them).  The dummy account is granted moderation rights to the lists we want it to maintain; if a new application is added, we only need to link it to the same account.

 

The attached patch allows you to add a line of the format

   set_variables  VAR1=value,VAR2=value,VAR3=value…

to the trusted_application stanza.  Any VAR=value pairs in the set_variables line will be used to explicitly set variables when authenticating the defined application user;  thus, you can use

  set_variables address@concealed

to enforce this application to only use the specified email address’ access rights (and this user can then be added as a concealed, nomail moderator for lists to allow management of their subscriber lists).

 

Hopefully, this patch can allow a more finely-grained control over trusted_application access rights, by using the existing list admin privileges method while still allowing checks in scenari.

 

Feedback welcome…

 

Steve

 

 

Steve Shipway

University of Auckland

UNIX Systems Design Team Lead

address@concealed

+64 (9) 3737 599 ext 86487