AAD Integration with Speckle running in Azure K8s

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
image

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 :slight_smile:

2 Likes

Hey @shiangoli

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.

1 Like

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

1 Like

Hi @gjedlicska 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

1 Like

Hey @shiangoli ,

Actually it’s the other way around, we fully support and embrace OIDC. It’s SAML that we do not support.

It gives me less clues why your set-up is not working though.

1 Like

Hi @gjedlicska That’s not good news :frowning: . You mentioned a longer snapshot of our logs would be useful. Which logs are you referring to?

1 Like

Hi @gjedlicska, 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?

1 Like

Hi @shiangoli,

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.

image
image

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.

1 Like

Hi @AlexHofbeck thank you for your response, that is not good news :frowning: we need to use AAD
Hi @gjedlicska @iainsproat please let me know what would be our next steps? I’m happy to share/help with getting this issue resolved

1 Like

Maybe I need to describe it more precise …

Azure offers:

  • OAUTH2
  • OpenID Connect
  • SAML

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.

1 Like

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

1 Like

In my Docker Compose file I have used this setting:

      STRATEGY_OIDC: "true"
      OIDC_NAME: "Bollinger+Grohmann Account"
      OIDC_DISCOVERY_URL: "https://login.microsoftonline.com/YOUR TENANT ID/v2.0/.well-known/openid-configuration"
      OIDC_CLIENT_ID: "Client ID"
      OIDC_CLIENT_SECRET: "Client Secret"

This one I had initially … which stopped working at least in my configuration

      STRATEGY_AZURE_AD: “true”
      AZURE_AD_ORG_NAME: “Bollinger+Grohmann”
      AZURE_AD_IDENTITY_METADATA: “https://login.microsoftonline.com/YOUR TENANT ID/v2.0/.well-known/openid-configuration”
      AZURE_AD_ISSUER: “Bollinger+Grohmann”
      AZURE_AD_CLIENT_ID: “Client ID"
      AZURE_AD_CLIENT_SECRET: “Client Secret”

With Kubernetes it should look like that see helm chart
image

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 :exploding_head::exploding_head::exploding_head:

1 Like

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

1 Like

Just a stupid idea …
With other user names too? Or only yours? Can you delete your account out of the database? Or reset the Postgres?

1 Like

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

Maybe these flashbacks are useful, maybe not :slight_smile:

1 Like

I tried a new user that has never logged into that particular instance and we got the same error

1 Like

I will check with our AAD admin and see if this is blocked

Did it work for you? This stuff is super sensitive …

I had to change something in our configuration today and messed up the whole authentication, thankfully got it to work again

2 Likes

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 @gjedlicska , @dimitrie, @jonathon let me know their identity/authentication requirements. Thank you

1 Like

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!

1 Like