Auth: Add support for single sign-on via OpenID Connect (OIDC)

[francescocarzaniga]

It seems that multi-user instances are on your radar, so I would like to suggest implementing OIDC for the login flow. OIDC is becoming the de-facto standard and there are tons and tons of projects (Open Source and not) using it now. It could be used together with LDAP with an IdP like Keycloak, so it would cover all the bases there and not require you to implement other Directory services.
I would personally suggest looking at Owncloud for inspiration (also for the Open Source/commercial side).

---

Related Issues:

• Account: Add Support for 2-Factor Authentication #808
• API: Add support for OAuth2 Client Credentials and Access Tokens #3943
• Auth: Add authorize API endpoint to implement the authorization code flow #4368
• Auth: Add userinfo API endpoint to get information about the logged in user #4369
• Multi-User Photo Gallery with private and shared photos/albums #98

Documentation:

• https://docs.photoprism.app/getting-started/advanced/openid-connect/
• https://docs.photoprism.app/developer-guide/api/oidc/

[bnounours]

+1
For now either the collection is public (which is not ok for personal photos) either the admin account need to be connected (which is not ok to give admin account to all users)

[butonic]

For OCIS we integrated konnectd from kopano as an OpenID Identity Provider. It can use an LDAP server to provide users. A minimal version could use glauth as the user backend. Personally, I'd love to see a reusable minimal set of services to provide users for open source projects that want to embrace OpenID Connect. It sucks to implement user authentication. Small deployments don't need a full blown keycloak server but should be able to embed a small scale solution. We did it with ownCloud and we did it again for ocis. It should be possible to flesh out something that can be reused by all. Konnectd and glauth are written in go and with ocis we tried to go for a microservice architecture. Maybe we could add Photoprism as one of the services? Happy to discuss ways forward. Ping me on https://talk.owncloud.com.

Cheers and Happy New year!

[Nicarim]

Hey - got a question regarding this issue. Is this something you're considering implementing to the project? I might want to contribute the code to repository but I'd like to know how would you prefer to do it.

My initial idea (and reason) for adding SSO (or OpenID, or whatever) was to initially support reverse proxy functionality authentication middle like for example in Traefik authentication middlewares.

Good example of such configuration can be found here for authelia SSO.

I'd like to gate access to my private cloud through SSO solution like Authelia. They provide a way to inject HTTP header called Remote-User or whatever name you give it - so that application receiving request can trust that header and that user is authorized and their name is what is in that header. Example implementation of it with Jira out of their documentation.

Getting to the point - would you accept contribution to get Remote-User header be a way to authorize the user?

Perhaps initially could that be whatever is in that header is treated as admin user, but if there is no such header then you're prompted to log in?

Example Flow Unauthorized:

• User enters example.com/photoprism
• Traefik sees user is not authenticated by asking Authelia if their credentials in cookies / session are correct
• User is redirected to independent flow of authentication provided by Authelia
• Authelia completes authentication, redirects back to example.com/photoprism and injects header Remote-User: youruserfromSSO
• PhotoPrism sees that header and automatically authenticates user as admin

Of course assumption is that this header is dropped if provided from the internet and it is only injected by trusted middleware.

Just to be sure - You can achieve this functionality right now by setting the photoprism instance to public, but that removes authentication for other endpoints like WebDAV endpoint which makes it impossible to have public instance with authorization on that endpoint. I had an idea of making exception for WebDAV endpoint that it would accept PhotoPrism native credentials, and that visiting through browser normally would use SSO. For that to happen - above idea needs to be somehow implemented.

Tell me your thoughts about it :)

Not sure if I should post it under OpenID or separate issue, so if you want me to create new issue I can do that.

[lastzero]

Already working on it.

[Nicarim]

Full OpenID authenication or just the trusted header option?

[moximoti]

Hi, We’re currently implementing user management and OpenID Connect Client (RP) in PhotoPrism. This does not include trusted headers. I suggest to wait until user management and OIDC are properly implemented before aiming for a third authentication method, as we need to integrate all this with our current session management.

Btw, Authelia also supports OIDC. So there’s actually no need to implement trusted headers for your use case once we have OIDC ;)

[Nicarim]

That's correct - OIDC will work just as well if there is OIDC.

I just thought that if you wouldn't want to waste too much time on that trusted headers could be a good compromise - after all it would be just some IF somewhere granting unconditional access instead of checking password.

Just a question then - what about the WebDAV scenario where I still want to be able to use PhotoPrism native credentials? Or do you have some other solution to that problem? if OIDC will be used then the application would need to be able to get the authentication somehow through OIDC - and none of the apps like photosync would support that I guess.

[lastzero]

We should provide app passwords / tokens for that.

[lastzero]

Our development preview build has been updated to include all the latest changes and improvements - since there are currently no more known issues, this is a release candidate! 🎉

[lastzero]

The additional changes implemented yesterday allow existing users to keep their login password when changing the authentication provider from "default" or "local" to "oidc" (now also in combination with 2FA if enabled for the account).

Our documentation has been updated accordingly:

• https://docs.photoprism.app/getting-started/advanced/openid-connect/#existing-accounts
• https://docs.photoprism.app/known-issues/#openid-connect-oidc

Also note that admins cannot change the authentication provider of their own account through the Admin UI, so that they don't accidentally lock themselves out e.g. by setting it to "none".

Our own tests have been successful. However, we will give you some more time to test the preview build before tagging the new release. Many thanks to everyone who contributed, especially @moximoti who got things rolling and did much of the necessary work! 🌈