Authentication with proxy and HTTP signature?

srosset81 · July 28, 2022, 3:06pm

The ActivityPub specs mentions the possibility to use a proxyUrl to make requests to remote servers:

proxyUrl
Endpoint URI so this actor’s clients may access remote ActivityStreams objects which require authentication to access. To use this endpoint, the client posts an x-www-form-urlencoded id parameter with the value being the id of the requested ActivityStreams object.

I’ve been using this for the ActivityPods project and it’s working fine. Basically, all requests to remote servers are done through this endpoint. The request is forwarded to the remote server, adding a HTTP signature which signs the message with a public/private keys mechanism, that the remote server can easily verify the WebACL rights on the resource (the actor’s public key being attached to the its profile)

I’m wondering if there are security concerns which prevent to use this everywhere ? Isn’t it a simple and elegant way to authentify users accross as many servers as we want ? I find the Solid-OIDC spec difficult to implement, while with this proxy solution, users can create POD accounts however they like, and still be recognized by remote servers.

The only thing missing in the above ActivityPub spec is the possibility to handle POST, PUT, PATCH and DELETE methods. But it’s possible to adapt it for such cases, it’s just an API. However I would like to make sure I’m not missing something before implementing this solution…

Thanks !

GuillaumeAV · September 2, 2022, 2:57pm

@bblfish what do you think about this solution ?

lecoqlibre · February 15, 2023, 2:54pm

It seems that some discussions are currently running on this topic in the authentication panel. We mentioned this during the community group call. Ping @elf-pavlik

github.com/solid/notifications

Notification Sender - authentication may require both identities client & agent (user)

opened 04:23AM - 15 Dec 22 UTC

elf-pavlik

Previous drafts were using `webid` in Subscription Response (Webhook, LDN). Rece…ntly we changed it to `sender`. Commonly solid authentication provides two identities: * client - the application (e.g. used by `acp:client` matcher) * agent - the end user (e.g. used by `acp:agent` matcher) I think having just single WebID as *sender* doesn't support case where access policy on the `target` should be based on two identities `client` and `agent`. We should consider supporting providing both identities for the sender.

github.com/solid/notifications

Authentication: exchanging public keys, signing messages

opened 01:16PM - 16 Jan 23 UTC

csarven

protocol

Copied from ldn-channel-2023 (currently PR: https://github.com/solid/notificatio…ns/pull/147 , Preview: https://htmlpreview.github.io/?https://github.com/solid/notifications/blob/eced5e10b2d25ffe013310f5b3f51102e04cb627/ldn-channel-2023.html#authentication ) --- Details need to be further specified. The [Security Vocabulary](https://w3id.org/security) (or [The Cert Ontology](https://www.w3.org/ns/auth/cert), [WOT](http://xmlns.com/wot/0.1/)) can be used. * Subscription Clients to share Notification Receiver's public key, where `sendTo` has a `controller` (which is the `receiver`). * Subscription Servers to share Notification Sender's public key, where `sender` describes the key. See Notification Channel Data Model ([preview](https://htmlpreview.github.io/?https://github.com/solid/notifications/blob/eced5e10b2d25ffe013310f5b3f51102e04cb627/ldn-channel-2023.html##notification-channel-data-model)) for example subscription requests and response including public keys. Subscription Client lets the Notification Receiver know about the Notification Sender and their public key. Notification Receiver sets Authorization rules for Notification Sender. Notification Sender can optionally use [HTTP Message Signatures](https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html).