We have integrated Speckle with AAD and the AAD authentication appears to be working. In that we get the AAD login see below then if we are off the company network we subsequently get the usual 3rd party multi factor authentication however it then returns us back to the original page effectively not logging onto the Speckle dashboard see second screen shot
When viewing the Speckle server pod logs it would appear there is an issue inserting a null value into the table “api_tokens” for the column “owner”. Please see error in screen shot below. We have enabled ID tokens for the AAD Application Registration under authentication. Any ideas what this might be? Does this mean the user needs to be registered before attempting to login? If so how will this work. I feel there is something missing
Good to hear that you are progressing with the AAD setup; it is a tedious process.
With an SSO login, the initial login flow will register the user if it’s not yet registered on the server. So you do not need to do anything about that.
Are you, by any chance, using a SAML SSO app instead of an OIDC one? We’ve recently noticed that our setup steps don’t include the strict requirement of OIDC for the AAD flow to work.
If that is not the issue, a longer snapshot of your logs would be needed to know what is happening. Probably the user creation step is not successful, so there is no user record to attach the frontend API token to.
Hi Gergo, I’ve just had a reply from our AAD administrators and we use OIDC. From your last post it would appear your setup steps do not support OIDC. Are there any plans to support this? If not what is the work around if any? I will see if its acceptable for us to change the App registration to use SAML
Hi @gergo SAML is acceptable however I need basic SAML configuration, some are optional however others are not in particular the Reply URL (Assertion Consumer Service URL). Obviously the root (https://root.com) is specific to our installation its the extension bits we don’t know. Do you know what it is?
The others that are option are
Sign on URL
Relay State
Logout Url
These also might also be relevant
Thank you for your help
Hi @gergo, Can we work backwards from the above error? The insert statement where the column owner is null for the api_tokens table? It would be useful to know where Speckle get’s owner from? Hi @AlexHofbeck looping you into this post, I can see from a previous post that you also tried AAD, you may have experienced the same issue?
I just did the step-by-step by Azure. At that time I had issues with the Azure AD auth on the Speckle side and switched to OpenID in the configuration (of my Docker-Compose YAML). By taking a look at your screenshot you are using still Azure AD Auth mode.
I can also offer you a step-by-step comparison beginning of next week, in case the above does not help you. I’m far away from being an expert in it though … maybe we still can figure it out together.
Hi @AlexHofbeck thank you for your response, that is not good news we need to use AAD
Hi @gergo@iainsproat please let me know what would be our next steps? I’m happy to share/help with getting this issue resolved
I used OpenID via Azure AD … which uses the Microsoft 365 account Token based via authorization.
For Speckle I switched the method to open ID connect … But it is basically the same procedure.
Thank you for the clarification we are currently using OIDC in AAD, which is the same as Open ID Connect. As was the case in my original post. We haven’t switched to any other method. This is still AAD Authentication, right?..just a flavour of it? I would be interested to know what you did to get this working
With Kubernetes it should look like that see helm chart
Enter the Azure Open ID Data and Link for the Endpoint. Worked in my configuration with Docker Compose. Speckle Uses the Microsoft Endpoint and access authorization happens token based via Microsoft Login page.
Hope this helps … if not let me know and we can go for a session next week!
After Speckle Con talk prepping when I have some capacity in my mental CPU, I also need to get into this Kubernetes stuff
Hi @AlexHofbeck it certainly did help because we were focused on the server.auth.azure_ad we changed this to server.auth.oidc. We still get an error but different see below. When looking at the console the only possible issue I can see is the “response was blocked by corb”, please see the 2nd screen shot. Not sure if this is genuinely the problem
The server said undefined bindings etc makes me think that, while the handshake might be ok, the returned user identity object does not include their email.
I’ve had this happen in the past (read: 2 years ago, so all this is vaguely remembered stuff). Reasons were:
incorrectly parsing the return object (they vary, email is sometimes in user.email, sometimes in primary_email, or primaryEmail, you get it). this could be tested with a console log of the userInfo object.
incorrectly defined scopes (e.g., i was not requesting the email of the user, or the identity service was not configured to allow the user’s email to be returned).
some combinations of the above, resulting in endless screaming into the void
Hi @AlexHofbeck, thank you for your message, unfortunately it hasn’t worked. Our AAD admin added an API permission to the application registration to allow it to read the email address but this made no difference. There are other settings however Security do not like turning these on unless we can justify these and I might not even be able to get these through. Hence please can Speckle @gergo , @dimitrie, @jonathon let me know their identity/authentication requirements. Thank you
Hi @shiangoli - there’s no specific requirements from our end besides being able to return from the oauth flow an email and a user’s name (or name and surname).
We’re now internally trying to find some time to get on a screenshare call with you and whoever else is relevant - ideally we’d press buttons together and figure things out on the spot. Let us know by email some times that would work for you and your team in the coming weeks!
Also, NB: we’re quite stretched until Speckle Con, but will do our best!