mirror of
https://github.com/anonaddy/anonaddy.git
synced 2026-04-25 14:15:53 +03:00
[GH-ISSUE #248] [Feature Request] SSO / User Provisioning with SAML based IDP like Azure AD #780
Labels
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/anonaddy#780
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @timomayer on GitHub (Jan 4, 2022).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/248
To use the service also in an corporate environment this would be a highly needed feature
@ccorneli commented on GitHub (Jan 4, 2022):
I'm curious where you see this being useful in a corporate environment. I can't think of a use case.
@willbrowningme commented on GitHub (Jan 11, 2022):
I'm afraid I do not currently have any plans to add this so I'm closing this issue for now.
@Queuecumber commented on GitHub (Nov 18, 2022):
@ccorneli this is important for a corporate environment because any service that's being hosted by a company for its employees generally has a hard requirement for how they can authenticate and what username/password/2-factor they can use.
@willbrowningme would you accept a PR for login/provisioning via an authenticating proxy (like oauth2-proxy) which sets the
X-Auth-Request-Emailheader? This way the actual oauth logic is outsourced to the proxy and anonaddy only needs to check for the header@Queuecumber commented on GitHub (Jan 28, 2023):
Hi @willbrowningme I just wanted to ping again and ask if you'd accept a PR that integrates with oauth2-proxy
I'm more than happy to do the work for this and the change should be quite minimal but I want to know if you're idealogically opposed to it first
@willbrowningme commented on GitHub (Jan 30, 2023):
Yes I would likely accept a PR for this. Are you able to explain exactly how such an integration would work with AnonAddy?
Since I'm not familiar with this I wouldn't want to accept any future maintenance overhead for updates etc.
@Queuecumber commented on GitHub (Jan 30, 2023):
The cool thing about going this route is that the change would be quite minimal and you get support for basically all oauth providers
What will happen in such a setup is that oauth2-proxy will sit in front of anonaddy. When a user visits anonaddy they will first hit the oauth2-proxy login page which will allow them to login however that admin configured it, oauth2-proxy will then set the
X-Auth-Request-Emailheader when forwarding requests to anonaddy.The modification to anonaddy is just to check for that header and skip the built in login flow if it is present, reading off the header value for the username. Onboarding can also be modified to work with this (e.g. if the
X-Auth-Request-Emailisn't present in the DB then provision a new account for them)This needs to be gated behind some kind of flag so that people don't enable it by accident as it should only be used if the appropriate proxy is in place.
@willbrowningme commented on GitHub (Jan 30, 2023):
Okay, sounds good to me.
Yes that would be great, perhaps an option to add to the
.envfile.@Queuecumber commented on GitHub (Jan 30, 2023):
OK great, I'll start scoping it out then