Account: Add Support for OpenID Connect (OIDC)
francescocarzaniga opened this issue · comments
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).
+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)
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!
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/photoprismand injects headerRemote-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.
Already working on it.
Full OpenID authenication or just the trusted header option?
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 ;)
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.
We should provide app passwords / tokens for that.
Any updates on when to expect OIDC support to land? I've noticed that there's been some additional work going on in the feature/oidc-v2 branch, but these changes haven't been referenced here – are they connected?
Hopefully in a few weeks. We do our best, but are limited by the constraints of physics. Check out the list of changes in our upcoming release: https://docs.photoprism.org/release-notes/
This is one feature I'm quite excited for. Everything I have is behind pomerium (OpenID-protected reverse proxy), so this would fit in very nicely.
I'll keep my eyes peeled, thanks for the update.
Really keen for this, I've deployed PhotoPrism and had a play. It looks fantastic but without SSO support, I find apps/services I add don't get used very much as users don't want to register. If they can click through and login with the same username and have an account autoprovisioned it's a whole different story!
Hoping I can ditch Synology photos when this/multi-user is live!
As you can see in our Release Notes and on the public Roadmap, we've decided not to release additional multi-user features before Christmas:
- This is partly because unexpected security vulnerabilities in Go and Log4j surfaced this month and we have a zero bug policy.
- In addition to providing support and fixing bugs discovered in the stable release, multi-user support is currently a top priority.
- Features are not released until we deem them safe and bug free. This is in the best interest of all users, part of our culture, and can't be debated.
- Users can do their part and become a sponsor to get their favorite features as soon as possible. At least until the funding goal is reached, please do not ask for deadlines.
Is OpenID available for testing in the preview build? Would like to test this feature with Authentik
- We received a lot of support requests and other questions over the holidays and in the last few days. More than our team can handle, and there have been very few community members who jumped in.
- As a result, our priority was to expand the Troubleshooting Guide and divide it into subsections to make it easier for users to find common issues and fix them on their own. Many other parts of our docs were improved as well, for example Connecting via WebDAV.
- We felt that this made more sense than adding more and more features as quickly as possible.
I just want to chime in and +1 trusted headers. All my services are behind traefik with traefik-forward-auth and use the X-Forwarded-User header.
We have a zero bug policy and do our best to help users when they need support or have other questions.
This comes at a price, as we can't give exact deadlines for new features. Also keep in mind that epics like multi-user support can't be delivered in a single update. Working on big features is a continuous process that can take months to years until all use cases are covered.
Having said that, funding really has the highest impact. So users can do their part and become a sponsor to get their favorite features as soon as possible.
This feature is a must-have for anything I expose to the public internet. 👍 👍
Regarding OpenID authentication, when will the feature be added in the main branch ?
Can we use OpenID authentication currently ?
Thank you for your answers guys
We have a zero-bug policy and are currently working on the next stable release, which we don't want to delay any further. Our priorities are generally as follows:
https://www.photoprism.app/oss/faq#priorities
If you need this for your business and purchase a commercial license with support, we can assign a higher priority to this issue.
Since people now seem to be starting to create forks of our software to monetize it, we will be implementing OpenID Connect support as part of PhotoPrism Plus. The code will then be in a separate repo, but our official builds and Docker images can be downloaded and used by anyone, including app store providers. You also don't need a membership to use OpenID Connect. However, our Plus license includes limitations to ensure that our work is not unfairly monetized by entrepreneurs, SaaS providers, and venture capital-backed startups:
https://www.photoprism.app/plus/license
We think this is a pragmatic compromise that ensures that most of our code remains open source and much of the functionality remains available for free. In a perfect world, of course, it would not be necessary to use different licenses (or even the AGPL instead of a permissive license like BSD or MIT).
It's sad that this is required these days. I love OSS, but I also see that such steps are required to protect projects from "parasitic use" (looking at #995). I also don't see how this feature is something that is required for home users anyway so this is a good and very understandable candidate for being part of the commercial editions.
It's sad that this is required these days. I love OSS, but I also see that such steps are required to protect projects from "parasitic use" (looking at #995). I also don't see how this feature is something that is required for home users anyway so this is a good and very understandable candidate for being part of the commercial editions.
Just a quick 2 cents from me, the use case I had for OIDC in Photoprism (and Home Assistant) is that I maintain a homelab and rely on Azure AD for SSO authentication.
This allows people (parents) who are not technical to use things that require authentication in a secure, passwordless way as the device is registered and uses device authentication.
OIDC does sound like a commercial feature; however, it can have a good use at home in big family setups where it's too much work to maintain multiple users and their accounts. Perhaps OIDC could make it's way into the free tier, with a user count limitation or into the essentials tier with the same limitation.
If I had to pay for Photoprism as is now, I'd not be able to. I am not satisfied with the performance of the object categorization feature (tried to make an improvement there in my PR but this will need further discussion and rearchitecting potentially for tflite) and the other arguments are that there are no native Android apps so I never ended up adopting Photoprism into as much use as I wanted.
If I was able to put a bounty on a feature, I'd definitely pay for OIDC and improvement of the AI features because Photoprism is a really cool solution.
Just a quick 2 cents from me, the use case I had for OIDC in Photoprism (and Home Assistant) is that I maintain a homelab and rely on Azure AD for SSO authentication.
We understand that this is a dual-use technology, just as some enthusiasts run complete enterprise stacks at home. However, the majority of home users probably won't need it, while all businesses will need either OpenID Connect or LDAP/AD.
Perhaps OIDC could make it's way into the free tier, with a user count limitation or into the essentials tier with the same limitation.
As mentioned in my comment above, you don't need a membership to use OpenID Connect. However, we will not include the code in the main repository under the AGPL license. If you want to distribute this code or software based on it, you will need to ask for permission, which we don't think should cause any problems for private users.
If I had to pay for Photoprism as is now, I'd not be able to. I am not satisfied with the performance [...]
If you want us to develop more features or improve the performance, it seems like a good idea to support us more, not less? The Essentials tier is less than 2 Euros per month. That shouldn't stop anyone from signing up.
Since people now seem to be starting to create forks of our software to monetize it, we will be implementing OpenID Connect support as part of PhotoPrism Plus.
With all due respect, if the PhotoPrism developers did not want their project used for commercial purposes, why was a licence that allows this chosen?
If you want us to develop more features or improve the performance, it seems like a good idea to support us more, not less?
Therein lies the difference between asking people to pay for a product, and to pay for further development of said product.
It's hard for me to imagine that a company would consider SSO as the primary reason for purchasing a license.
In most cases, a business needs technical support, because stable work is cost a lot of money.
*another one enthusiasts developer with complete enterprise stacks at home k8s cluster
With all due respect [...]
As mentioned in our Code of Conduct, we kindly ask that you do not use GitHub Issues or other development tools to start general discussions or express personal opinions.
If the PhotoPrism developers did not want their project used for commercial purposes, why was a licence that allows this chosen?
We stand by our license and do not "forbid" something that was previously allowed. In fact, I have said from the beginning that this will not be a free enterprise solution:
This is why we use a different license for certain upcoming features. The entitlement of some users and the way people talk to us now confirm this decision.
It's hard for me to imagine that a company would consider SSO as the primary reason for purchasing a license.
If you read carefully, you'll see that my original comment wasn't about licensing to potential business customers, but about an entrepreneur who publicly announced that he was considering working against us so that he could better monetize our software with the least amount of work.
*another one enthusiasts developer with complete enterprise stacks at home k8s cluster
Again, the OpenID Connect feature will be free, like in free beer.
As you can see from the priority label, this feature has priority and will also be free. Note that abusing GitHub Issues for general discussion distracts us from getting the next stable version ready for release, which is why comments are closed now.
See issue #808 for an update regarding the implementation of 2FA, OpenID Connect and Passkey support:
I was just reevaluating PhotoPrism for sharing family pictures between family members. I like a lot of what I see, and might go ahead and use it. But I'd really like to have some kind of SSO available, because I have a Keycloak instance that I use to help make managing accounts easier.. Which is why I found this issue. :)
I'm commenting because I want to mention that I hope you don't lock the feature up in your paid version like the account UI is locked.
As an avid believer in self-hosting, it's been painful to see how many open source projects lock SSO support up as "enterprise" when SSO is really not an enterprise level tool anymore. Maybe 5 or 10 years ago, but in 2024, SSO (and MFA) are essential to any level of webapp.
As an avid believer in self-hosting […]
This is a double-edged sword: You believe in self-hosting, including OSS, but want all of it for free without contributing or support the creators in any way? This thinking is the reason why problems like the xz backdoor happen and OSS dies step-by-step. The PhotoPrism team has gone the, kind of risky, way of trying to make a living from an OSS project while also still providing so many features for free. Everyone could simply go ahead and implement it on their own since the code is available, but instead everyone waits until the spoon reaches the mouth without any effort on their own.
Maybe 5 or 10 years ago, but in 2024, SSO (and MFA) are essential to any level of webapp […]
Let's take this into the real world… why don't you ask the cashier to give you the groceries for free since production can be easily automated these days with all of the modern machinery. While we're at it, let's also get a new car since fully automated robots in production lines also replaced many humans so a cars are also "essentials to any level of industrialized countries".
It's sad that nowadays you always have to make it clear to people that they don't even have the slightest right to make demands on free resources.
I hope you see where this goes and my comment is extra sarcastic since this exploiting behavior of "I have demands for everything I get for free" has been successfully placed by large companies into the minds of the younger generation and as a maintainer this keeps sucking the motivating energy out of anyone who enjoys creating something.
Here's some context to help you understand what @svengreb was referring to, in case you haven't heard about it (yet):
We plan to make OIDC part of our Community Edition, and have communicated this publicly on several occasions, for example:
At the same time, it's true that demands for free features (or for us to work faster) usually come from people we've never heard of and who don't actively contribute to the project by either helping out or becoming a member. I also have to agree that this kind of communication sucks the motivation out of you as a maintainer, especially when you put in so much work mostly for free.
On a side note, it would be great if end users did not use this issue tracker for discussions. Instead, you are welcome to use GitHub Discussions for that, as mentioned in our README.md file and throughout the documentation:
We plan to make OIDC part of our Community Edition ...
My searches on the topic did not turn up the info about making the feature part of the community edition. I'm glad to hear that you are doing so. :D Thanks!
On a side note, it would be great if end users did not use this issue tracker for discussions...
I commented here on the issue because my comment is directly relevant to how the feature is implemented. So, in this case, I thought the it was fine for the issue queue and didn't go looking very hard elsewhere.
Side node: I will say that one of the more frustrating things about Open Source is how many different places you can go to communicate. I've spent a significant amount of time over the years just trying to make sure I post in the correct place. It is very frustrating to do your best and then be told off for putting something in the wrong place.
In this case, I wasn't even trying to discuss anything, so I figured the the developers would just see the comment and go, "ok, we'll keep that in mind", then move on.
As for, #782 (comment) I was not demanding anything. I was making a request. I did my best to use non-demanding language. Heck, I didn't even say anything like "do this" or "don't do this". I just said "I hope you don't". I do see how my last paragraph could give the comment the impression of making a demand, though. So I'm sorry about that.
I'm out of time, so I'll just say that I really appreciate the work open source developers do, but I also believe that figuring out how to deal with the bad "customers" is part of the job. Even though you are not being paid for it. That comment was the wrong way to deal with someone. Either respond politely, or don't respond at all. If any of the projects I've pushed out as open source gain any users, that is how I'm planning on dealing with them.
Anyway, I don't plan on continuing this discussion, but if I do, I'll post something in the forum instead of here.
If it is possible, maybe just break these comments off and move them into Discussions? Is that even possible?