User Management via OpenID Connect

[martnst]

Hi,

in our project we use QIS as our image server, which the users upload images via REST from our React SPA. Currently the app authenticates via a single user which acts as a service account. I am wondering though, if it is possible to connect QIS to our IDM via OpenID Connect. [1]

Ultimately the user would have ownership about his images and we could implement access control bases on permissions managed via the IDM. The user's profile picture for example could be private for example, whereas images the of something like a blog post [2] would be visible to. any logged in user.

Bests,
Martin

[1] We use Keycloak as IDM.
[2] just an example

[qururoland]

We have successfully used ActiveDirectory, Red Hat IDM/389/OpenLDAP and cloud services like JumpCloud for authentication in QIS. We also spent quite a bit of time working on a solution to automatically secure images to one (or more) known users but that was a couple of years ago. This was for users to upload images of their high value works of art and to then control which other users they would let see the image.

I will have a hunt through the code and documentation to see what I can find of this work and will let you know.

[martnst]

As fair as I know Keycloak only has capabilities federate user from ActiveDirectory and LDAP, but does not acts as a source for other systems. Hence, my idea to use OpenID connect.

[qururoland]

Project lead coder fozcode has spent some time on OpenID Connect on another project. It's based on OAuth 2, the standard that one of the original designers resigned from because industry pressure made it too complicated to implement safely.

But the gist of it is that you authenticate with a 3rd party and the 3rd party gives you 3 tokens, one saying who you are, one saying what your application permissions are (defined on their side), and one for renewing the tokens before they expire.

QIS would need something like we already did here:
#27

Whereby if they're not authenticated we redirect away to the 3rd party login page, and that redirects back to QIS with the tokens. QIS would then need to check the 3rd party tokens for expiry as part of its middleware, and have a link between the 3rd party token and its own user database, e.g. with the username or email address embedded inside the token.

Is this the sort of thing that you are thinking about?

[martnst]

Hi Roland, yeah that sound about right to me.

The redirect flow would not be need in our case where our React frontend would only talk to the QIS REST API. Instead of getting a token from QIS the frontend would come with an OIDC auth token right away. However I could Imagine this would be needed you one would want to use a OPID Connect based IDM to kinda not use the QIS own user management at all.

Best, Martin