stoney core: ETag Mapping (REST - LDAP)
From stoney cloud
Overview
The idea of the ETag is that one can edit/update resources without overwriting the changes made by somebody else.
Since the REST API may not be the only client to the LDAP server and the REST API can't protect itself from concurrent writes to the LDAP on the same objects (due to the PHP principles of request-based execution), the LDAP must therefore most likely be part of the solution for generating and validating ETags.
Implementation proposal I
- fetch the internal LDAP attribute
csnalong with the object data - generate an ETag based on the value of the
csnattribute by hashing it - return the ETag with the response to the REST client
- when receiving a
PUTorPATCHrequest, the client must return that ETag value - fetch the object again and generate the ETag using the newly fetched
csnagain - compare the ETag sent by the client and the generated one, break here if they do not match
- use LDAP Assertion Control when sending the edit request to the LDAP with the fetched
csnas assertion
Notes:
- advantage over proposal II: this can easily be extended to the case where a resource consists of multiple LDAP objects by concatenating the different
csnentries in a reproducible fashion
Implementation proposal II
- fetch the internal LDAP attribute
csnalong with the object data - generate an ETag based on the value of the
csnattribute by encrypting it (and probably apply base64 transformation) - return the ETag with the response to the REST client
- when receiving a
PUTorPATCHrequest, the client must return that ETag value - decrypt the provided ETag value to retrieve the
csnagain - use LDAP Assertion Control when sending the edit request to the LDAP with the fetched
csnas assertion
Notes:
- advantages: we hit the LDAP server less
- disadvantages: the length of the ETag depends directly on
csn. What happens if we have multiple LDAP objects for one resource? - the security implications of this proposal are unclear
