Access control for time-pondersource-com

[michielbdejong]

Data about each Worker can be read by all users, but written by only one user, namely:

• For worker ismoil -> user ismoil
• For worker michiel -> user michiel
• For worker angus -> user m-ld
• For worker george -> user m-ld
• For worker victor -> user evoludata
• For worker yvo -> user muze

This data should be stored in a database table, and checked when a write command comes in.

But the use of "users" here is a bit weird. It's OK when the user is for one worker (like 'ismoil' and 'michiel'). It's also still OK if there is one-way sync, for instance in the case of yvo / muze.
But for the other three, we also want data to be forwarded.

For instance, if George decides to start using Mite, his data would reach time-pondersource-com through the evoludata user. We can do such switches in the demo presentation.

[mcalligator]

Having now digested the above in the context of the proposed presentation, there are some subtleties to identity management and access control we need to tease out. I think each of our federated systems needs to differentiate between user identities in timesheet data received from other systems and credentials required to use each of those systems. For example, as user angus in timeld, I would enter timesheet data, which would then find their way to both PreJournal and Tiki. But I might have been issued credentials specific to PreJournal in order to read data in that system - in PreJournal's case, the same ones as those used by timeld itself to send data to or receive data from PreJournal, namely m-ld (with password). The access control implication is that PreJournal therefore needs to associate certain worker identifiers (angus and george) with an identity (m-ld) to enforce it. This then makes it much harder for PreJournal to support receiving data indirectly from timeld - i.e. via Tiki - since the credentials used to supply those data won't be associated with those two worker identifiers, and thus establishes a hard-coded link between timeld and PreJournal.

What I'd suggest as an alternative is to create user identities for those worker identifiers separate from the m-ld system identity. Then you don't have to worry about enforcing write access control on that basis: instead, you can use the external identifiers for any data received for those two workers to write to PreJournal - whether they're new entries or updates to existing ones, and whether they're received directly from timeld or indirectly via Tiki.

You then have the non-obligatory option, should you choose, to implement write access control for anyone using PreJournal with credentials associated with the m-ld organisation, i.e. to support read-write access by the user identity angus to data relating to the worker of that name that also originate from timeld. If you decide against supporting write access for data originating elsewhere, then there's nothing more to do there: all external data will then be read-only, except when being updated by the system identity for either timeld or Tiki as described above.

[michielbdejong]

receiving data indirectly from timeld - i.e. via Tiki

indeed. that is also what i tried to draw in federatedbookkeeping/timesheets#51
data travels along a "call tree", so it never reaches you from an unexpected direction.

create user identities

the identitifiers exist (there is one components for each worker in PreJournal), there are just no credentials associated with them.

We have the claim-component command which allows e.g. the m-ld user to "claim" the angus component.
After that, the m-ld user will be allowed to send timesheet entries for the angus worker component.

We currently have a uniqueness constraint on the database, which will prevent the evoludata user from then also claiming the angus worker component.

But we could redesign that so that users are not allowed to claim components themselves, but instead the sysadmin determines which (multiple) users are allowed to send writes for each component.

Do you think that is better? Is that what timeld does?

I'll reopen this issue so we can track this discussion.

[michielbdejong]

Ah, just noticed the new discussion on federatedbookkeeping/timesheets#51 - let's wait for a decision there about what the desired behaviour of the network as a whole is, an then this issue can be about changes required in prejournal to make it so.