Hi René, My answers are inlined...
Best regard, Benoit On 22/01/2020 10:21, Rene Cordier wrote: > Hi guys, > > I would like to bring on the table some proposition to refactor our > session usage within James. > > # Context > [...] > Then I tried to use a `MailboxMapper` defined in the mailbox-store > module to be able to access to the mailbox containing that message > without having the mailbox id. However, we should not rely on this > outside of the mailbox modules, and rely more on the abstract API > defined in mailbox-api module. In my opinion we would need another architecture decision record on this consensual topic as this is the heart of our core APIs. Could you take care about it? I would add in the "context" that as part of an upcoming effort to port our current JMAP implementation to the lastest JMAP specification, we will have to support JMAP account delegation. Thus being able to audit/represent these concept efficiently when interacting with the mailbox store is also related to this work. > # Current API > [...] > > # What we need > > Well we can agree that the actual session is not enough to cover all the > cases that we have at the moment. I think we can have probably 4 types > of accesses within James to do operations on mailboxes : > > * User session : user is logged and authenticated explicitly, does > operations on mailboxes he has rights on. > * User delegation session : James is doing user-related operations > internally, it's more of an implicit user session (mailets, listeners, > ...?) I think you are mixing two concepts here... We have 'implicit' user actions, taken by the system on the behalf of the user (eg: listener, mailets). These system action originated from a user action. Which is different to 'delegation': Bob gives Alice the right to interact with Bob's mailbox as if she was Bob. - This can be revoked - We need to track that an action originated from Alice, and not from Bob (audit) > * Impersonation session : Admin is logged and authenticated, but has the > authorization to act on behalf of an other user > * System session : internal operations not directly related to a user (a > good example would be the recomputation of a jmap preview of a single > message) > > We would need then to refactor the code to ensure we have different > types of sessions regarding those cases and review the session usage to > not introduce security vulnerabilities. > > > # Proposed solution > > We could start by having a different session type for each of those > cases above, by also modifying the API in `SessionProvider` to have the > required methods achieved by this : > > * `login` => user session : TypeSession.User > * `loginAsOtherUser` => impersonation session : > TypeSession.ImpersonatedUser > * `createDelegatedUserSession` => user delegation session : > TypeSession.DelegatedUser > * `createSystemSession` => system session : TypeSession.System > > Those grained differentiations would also help better for auditing and > logging purposes. > > We need as well to be careful and refactor the code regarding those new > types of sessions and sets of rights : > > * `TypeSession.User` and `TypeSession.ImpersonatedUser` should have the > rights defined for the user > * `TypeSession.ImpersonatedUser` should have the rights of the user that > is being impersonated, not the logged in admin > * `TypeSession.System` should have bigger rights, to allow more global > operations on mailboxes in necessary cases (need to use carefully though) Define "(need to use carefully though)"... How would you achieve carefulness here? > We need to define what kind of session is suitable for which parts of > the code and also add/update tests suites accordingly. > > We probably should propose an ADR for this too... That, is necessary, yes. > > > What do you think of it? Any feedback / discussion is welcomed of course > ! Thank you for reading this. I believe MailboxSession need to cary along different information depending of the 'SessionType'. User type just need to cary along the username In case of delegation we need to have both users In case of a system session (as defined above) have the name of the service taking an action is more relevant than a username Maybe we could have an object representing the Entity using this session to interact with the mailbox store? > > Best regards, > Rene. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
