Security for the feed
Dec
1
The project team have been considering some of the aspects of security for this project. Unlike other web services we produce, the XCRI-CAP feed will not require authentication. Most of our standard web services require consumers to authenticate and are only available from on campus. When considering security risks such as denial of service attacks, one of the best approaches is that of separation.
It would have been very easy to point the system directly at our central DB, however even with caching, this could still pose a potential security threat. For this reason, quite early on it was decided to separate the XCRI-CAP database from the main central database. This would mean we could still produce a dynamic feed (made queryable via REST) and remove the possibility of a denial of service attack impacting on the central database.
For reasons of maintainability, it was decided to keep the XCRI-CAP database on the same server as the central database. Although the risk of an attack effecting the central database was now reduced, the fact that the XCRI-CAP database was now only separated from the central database at schema level meant further consideration for security was required.
The option of producing a flat file of the feed each night (at the same time as the XCRI-CAP db refresh) meant that calls to the main feed would not hit the database. However, we still wanted the feed to be dynamically searchable. Our solution to this was to query the flat XML file when making REST calls meaning that no calls to the XCRI-CAP feed would ever need to connect to the database making the system safer from denial of service attacks.