Federation Security: Authorisation

Related: #236

As a trusted sender, I can send URLids belonging to other servers (including the recipient), saying for example "hey Paris! This user from Nantes left your circle", when they did not

mentioned in issue management/core-team#3

changed title from Federation Security: sender is not checked against objects to Federation Security: Authorisation

mentioned in issue infra/security#32 (closed)

mentioned in issue #372

There's going to be a usability conflict here: What if I don't give the federated server permission ?

• they will either undo the change which they requested, having already told the user 200 or 201!
• or they will leave it and the federation's data will be out of sync

We could ask for permission from the remote server before I effectuate the object, meaning that I don't respond 200 to the user until I have an OK from them. However this would be doubling the latency on a request for each subsequent save on an external resource, and will be binding my own responsiveness to all of those dependents

We could ask for permission from the remote server before I effectuate the object, meaning that I don't respond 200 to the user until I have an OK from them.

I fear that it is the only reasonable option if we wish to get explicit authorisation before taking any actions.

yeah ping @jbpasquier this will be relevant to #332

some more thoughts about this:

• with #236 but without #372 this "isn't an issue" because I'll have total permissions on the server or none
• with #372 then the issue only comes into play when my permissions contradict the permissions on the remote server (e.g. I allow my admins to add external users to the circle but the IdP doesn't allow anyone else to add their users to things)

they will either undo the change which they requested, having already told the user 200 or 201!

For this eventuality maybe there's some kind of hook we can add into the client:

OOPS! Sorry we lied to you

We could ask for permission from the remote server before I effectuate the object, meaning that I don't respond 200 to the user until I have an OK from them.

I fear that it is the only reasonable option if we wish to get explicit authorisation before taking any actions.

I do disagree, if I add to my own server "I'm president of the United Tarts of Americas", then I claim it. I'll send a backlink to United Tarts, they can reject it if they don't see the legitimacy of my claim, but their action give them no permission to remove my claim on my own server.

or they will leave it and the federation's data will be out of sync

This sounds like a fatality.

I guess that we can have things working differently and let the client application create the backlink instead and thus resolving those conflict. But that's another approach. Maybe this approach is more friendly with our front-end federation concept.

Getting the client to manage the backlinks is an interesting approach and I think it's promising as a solution, maybe also resolves our headaches on #372, since the user is being the agent directly, not by proxy

• does the client need to know the backend's schema to do this? (it could maybe get the footprint/shape to figure out where the backlinks need to go, or it could work in tandem with the server)
• could a malicious client purposefully put a federation out-of-sync?
• how does Mastodon work? (we can reach out to SocialHub)

mentioned in issue #236

mentioned in issue management/core-team#16

This is another one which will benefit from research into Mastodon. I wonder if they centrally agreed to their permissions system

the issue only comes into play when my permissions contradict the permissions on the remote server (e.g. I allow my admins to add external users to the circle but the IdP doesn't allow anyone else to add their users to things)

Maybe the data-access-grants work will budge this

mentioned in issue infra/prosody-modules#17