Tying auth/session to webhook callback

Mobile
1

We are prototyping out a CBL + SG with CB server as an edge service which will then feed back to our main backend servers.

I’ve got most of the replication stuff working, but the main issue I am struggling with is passing in auth. I have implemented implicit auth with OpenID connect and that’s all working, however the webhook doesn’t seem to have any sort of identifying info such as session, that we can tie back to authentication. We need the correct auth for the user that did the modification.

Is there any way to get the session from the document? Anything from the revisionId for example?

Is there a better method of listening to changes that will give me what I need?

2

You could leverage our eventing service but that’s Enterprise Edition only

Couple of thoughts that come to mind

  • You can’t get the session from document - that’s associated with the replication (and besides sessionId wouldn’t necessarily be meaningful outside context of the sync gateway) .
  • include username in the document itself and send that username to your backend server that should then authenticate against the OIDC provider (which is the main identity provider for your system). That keeps separation of concerns - the original token authorizes the user to update document on Couchbase Server and the second authentication from backend server authorizes if that user is eligible to update backend server.
  • Not sure if it would work for your use case but have you considered creating a “Sync Gateway user” and invoking the remote URL under the context of sync gateway user ? Given that the sync gateway has already authenticated the user who has updated the document, is there a reason your backend servers care about the users who are updating the document versus the fact that the update document notification is from a trusted source (i.e. sync gateway).
3

Thanks Priya,

  • Our edge service proxies the authentication so we can tie auth to session fairly easily, I saw it as the simplest way to tie an update to authentication. I can see why that’s not how things work though.
  • This is similar what I am prototyping currently, however it feels clunky and error prone so far. I am a bit worried about how something like this will play with our architecture.
  • We need to use the correctly authenticated user for auditing and permission purposes, so an API user isn’t viable.

The eventing service isn’t something we’ve come across before. I’ll have a look into it!

4

So reading through the documentation for the eventing service, I can’t see much indicating how we’d use this to see who made the change… is there more in-depth documentation? To me, it just looks like it just provides an inbuilt way of processing data without needing a webhook + external service + couchbase SDK?

is there more available in the function that would help us link to the user who committed the change?

Do any of the connectors provide more data… for instance the Kafka Connector?

5

@priya.rajagopal are you able to expand on this ^

We are almost certainly going down the Enterprise route if we go with Couchbase so any solutions in that space is fine.

6

You are right - The eventing service would be a cleaner and more scalable and performant alternative to the web hook option (takes load off of sync gateway - dedicated external service ) . Would recommend that option . That said, your understanding is right in that It wouldn’t solve the authentication issue (Eventing service isn’t privy to the sync gateway users and does not have knowledge of who updated the document ) - I can’t think of options other than the ones suggested earlier

Tagging @adamf for additional suggestions in case I am missing something.

7

There isn’t any information persisted by Sync Gateway (or Couchbase Server) about the user that last modified a given document.

That type of information is typically stored by the application as a property in the document itself. Validation of this property (to avoid identity spoofing) can be performed in the Sync Function using the requireUser() built-in function.

8

Hi Ben, If you use the Eventing service on a SGW enabled bucket you will need to suppress a duplicate mutation via the crc64( ) function (for details goto this link and search for: Sync Gateway)

Also if you want to have Eventing directly update the source bucket if SGW is enabled on that bucket there is a more involved workaround (just reach out to me and I will be happy to provide it).