SEMDA Vendor Names
The vendor names follow the convention "SEMDA <CMS-name> <country-code>".
SEMDA Vendor Name | Districts |
|---|---|
SEMDA Polaris AT&BIH | Districts: D-1910, D-1920 |
SEMDA Polaris BE&LUX | Districts: D-2130, D-2140, D-2150, D-2160 |
SEMDA Polaris CH&FL | Districts: D-1980, D-1990, D-2000 |
SEMDA Polaris ES | District: D-2202 |
SEMDA Polaris FR | Districts: D-1520, D-1650, D-1680, D-1690, D-1710, D-1740, D-1790 |
SEMDA Polaris IS | District: D-1360 |
SEMDA Polaris SE | Districts: D-2335, D-2355, D2405 |
SEMDA RoCas DE | All Districts: Rotary Germany |
SEMDA Aurora DE | All Districts: Rotaract Germany |
SEMDA Kiosk IT | District: D-2032 |
SEMDA Gero IT | Districts: D-2041, D-2042 |
SEMDA romeo FI | All Districts Finland |
SEMDA LEAD NL | All Districts Netherlands |
SEMDA TRIO KE | District: D-9212 |
For new customers having a new Local CMS using SEMDA, RCS will request RI to create a new vendor.
Vendor configuration at Rotary International
The vendor must be correctly configured for each club at Rotary International. Only the club secretary or executive secretary can do this.
For each club only one vendor with access view-update and several vendors with access view-only can be configured. If SEMDA is used for updating information stored in Rotary International, then view-update access must be set.
Read the instructions how to set vendor in RI
Authorization
The authorization to use the SEMDA systems is issued by the RCS. Respective product contract and SLA must be signed. RCS will then pass the required unique authentication key to the Local CMS. This key must be used for the connection to SEMDA and in all requests. This key represents a confidential information and must not be shared with any other CMS.
Authentication
Each request from Local CMS to SEMDA must contain a unique authentication key which identifies the Local CMS. This authentication key is created by the RCS and passed to the Local CMS after contract and SLA have been signed. Request without valid authentication key are discarded.
Access and encryption
Access to SEMDA is possible only through https protocol.
All data in transfer between Local CMS and SEMDA and between SEMDA and RI is encrypted.
Data security
SEMDA does not have persistent storage like a database. It uses a reliable message broker (RabbitMQ) to temporarily store requests from various Local CMS. The requests are managed in a queue, assigned to each particular Local CMS. The request data is automatically destroyed when a request has been processed. The reliability feature of RabbitMQ ensures that the system survives a power failure or software crash without loss of data.
The access to the request data is possible only through the programmatic components of SEMDA.
There is no interface (GUI) or tool available to show the request data for SEMDA customers.
SEMDA fulfills the highest security requirements because:
No data is persistently stored in SEMDA
No data is exposed to a user interface or an interactive tool.
Data related to a particular Local CMS is separated and isolated from all other connected systems.
The data exchanged between the particular Local CMS and RI is not passed to any other system.