Skip to content

Testing with ms entra#2

Open
davidpcls wants to merge 7 commits intoauth_updates_from_tiledfrom
testing_with_ms_entra
Open

Testing with ms entra#2
davidpcls wants to merge 7 commits intoauth_updates_from_tiledfrom
testing_with_ms_entra

Conversation

@davidpcls
Copy link
Owner

@davidpcls davidpcls commented Feb 17, 2026

Description

This includes the changes needed to get this working with MS Entra. These changes would have been necessary regardless of the authenticator and much of the code closely resembles what exists in tiled's authentication.py file.

This will support both client credential flow and device auth flows.

Motivation and Context

We wanted support for Entra.

Summary of Changes for Release Notes

Added endpoints required to properly support OIDC authentication flows.

Fixed

Added

Added endpoints required to properly support OIDC authentication flows.

Changed

Removed

How Has This Been Tested?

Tested using MS entra and an authorized application setup in Azure. The application was configured
with the following redirect URLS:

And then the following config setup for the HTTPserver:

authentication:
  providers:
    - provider: entra
      authenticator: bluesky_httpserver.authenticators:OIDCAuthenticator
      args:
        audience: <from Azure application registration>
        client_id: <from Azure application registration>
        client_secret: ${ENTRA_SECRET}
        well_known_uri: https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration
        confirmation_message: "You have logged in successfully."

api_access:
  policy: bluesky_httpserver.authorization:DictionaryAPIAccessControl
  args:
    users:
      <an entra user>:
        roles:
          - admin
          - expert

Then it was possible to login using this endpoint

http POST http://localhost:60610/api/auth/provider/entra/authorize

and also with the latest queueserver-api changes to support external auth.

This is working okay, although it doens't really work smoothly for the
API based login and the http command based login isn't great, as it
requires the user to copy and past token around. Compared to ldap
which just logs the user in.

So still some work to do here to smooth out the user experience.
This solves the problem that what was implemented was actually
authenticating the application and not the user like expected. It worked
but it required that the user input a code. This solves that problem so
that when you click the login link, if you are already logged in with
you SSO provider you'll just automatically log in to the HTTP Server.
Likewise if you use the bluesky queueserver api, when you call RM.Login
you'll automatically be logged in, no user interaction required.
These should correct some of the problems in the last CI workflow.

I moved the LDAP and docker image into the continuous_integration folder
so it matches tiled.
@davidpcls
Copy link
Owner Author

The last run of the unit tests showed what appeared to be a unit test design issue and not something related to the tests I added. I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant