Hi, I would like to implement a custom authentication using oAuth2 code grant workflow with a single client Id and multiple Speckle instances
I was looking into the code, and I noticed that it would be barely easy, as just creating another auth/mycustom/index
So I’ve done a PoC, however, I do have some questions.
Correct me if I’m wrong, but it seems that the token returned by any kind of authentication is discarded and a new JWT token is created on Speckle side, on a code line like this one:
My planned custom workflow will be something like this:
Speckle A
Speckle B
SpeckleAdmin
The SpeckleAdmin can connect to both Spceckle instances (A or B), the user should authenticate using an Azure AD backend, but with the same oAuth client for both, the Speckle Server is responsible for authorizing the user (checking if the User X has access to the Speckle instance).
Another solution that I thought was using a single Speckle Server instance, with multiple projects, and assign the user permissions for each of those projects, this one seems simple, but I’m afraid about how scalable it is.
Simply using AD existent backend doesn’t work because we would need to whitelist every callback url and doesn’t check specific permissions for each instance, which is not practical and has some restrictions on our use cases.
What do you think? Is there any other solution that I’m missing here?
In the next iteration of the server, we’re going to handle this much better and allow for app registrations with their own redirect urls on the server. The current situation is a stop gap solution mostly; a refactor towards properly supporting OAuth flows is in the works.
Your use case is cool - i’m curious where it’s coming from! @teocomi and me brainstormed a bit just recently on how to handle authentication across multiple speckle servers, and there’s no direct easy way.
If your usecase is one server per “project”, that is, in my experience an overkill. Hestia, the public one, has upwards of >130k streams and >35 million objects, all from various users. I do appreciate though that the current web interface, etc. does not lend itself easily to setting proper access control.
At Arup, I helped deploy several regional speckle server instances, and they’re all tied in the same AD app; basically you log in with a single account into all of those instances. Would this be a better way?
Sorry for the ramble - my reply is all over the place - i’m trying to wrap my head around what you’re trying to do!
Thanks for the detailed reply.
The problem I see with the single AD app is for the authorization, how a server would decide whether it should grant access or not?
What do you think about setting up a quick call, so we can discuss further about this workflow and the alternatives? Are you available?
Hi, I was really eager to read the promissed answer
I was thinking in same direction for creating a “multi-tenant” approach using multiple projects and assign the user permissions for each.
I would really like to be able to authenticate/authorize using our existing Azure AD
Hi @henkon! I’m afraid we’re quite behind on the multi-tenancy front, though it’s been a super hot request since a while Authentication using azure AD is already possible though on a per-server basis - if you dig through the .env-example you should see the required vars you need to pass in (standard stuff from an azure app registration).