stoney core: ETag Mapping (REST - LDAP)

From stoney cloud
Jump to: navigation, search

Overview

The idea of the ETag is that one can edit/update resources without overwriting the changes made by somebody else.

The ETag is therefore some kind of state representation which can be checked on the server when a change is requested from the client to see whether the state on the server is still the same as the client assumes it to be.

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 entrycsn along with the object data
  • generate an ETag based on the value of the entrycsn attribute by hashing it
  • return the ETag with the response to the REST client
  • when receiving a PUT or PATCH request, the client must return that ETag value
  • fetch the object again and generate the ETag using the newly fetched entrycsn again
  • 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 entrycsn as 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 entrycsn entries in a reproducible fashion
  • disadvantage over proposal I: we have to read from the LDAP again before we can write
  • instead of the entrycsn one could use the modifyTimestamp instead, but it seems that this attribute has a lower resolution while entrycsn features microsecond resolution and is also used for replication and it can therefore be assumed to be unique.

Implementation proposal II

  • fetch the internal LDAP attribute entrycsn along with the object data
  • generate an ETag based on the value of the entrycsn attribute by encrypting it (and probably apply base64 transformation)
  • return the ETag with the response to the REST client
  • when receiving a PUT or PATCH request, the client must return that ETag value
  • decrypt the provided ETag value to retrieve the entrycsn again
  • use LDAP Assertion Control when sending the edit request to the LDAP with the fetched entrycsn as assertion

Notes:

  • advantage over proposal I: we hit the LDAP server less
  • disadvantages over proposal I: the length of the ETag depends directly on entrycsn. What happens if we have multiple LDAP objects for one resource?
  • the security implications of this proposal are unclear
  • instead of the entrycsn one could use the modifyTimestamp instead, but it seems that this attribute has a lower resolution while entrycsn features microsecond resolution and is also used for replication and it can therefore be assumed to be unique.

Links

Retrieved from "http://wiki.stoney-cloud.org/mediawiki/index.php?title=stoney_core:_ETag_Mapping_(REST_-_LDAP)&oldid=3680"