Any chance for LDAP auth and SSO? about tabby HOT 11 CLOSED

I don't personally need a feature like that, but depending on the workload I could consider it. What I'm not too clear on, are you looking for authentication through an LDAP backend (so where a bind is performed with the supplied login details to check a user and then get the necessary attributes of the bind succeeds) or with an SSO through OAuth or SAML. I have experience with integrating LDAP binds as well as Shibboleth, so those would be easy, but I'm not exactly sure what your expectation is.

Currently it's also the case that besides the accounts, each user has their own list of friends they track debt for. These are usually added through the interface. I'm not sure what your expectations are there. Is it fine as it is, would you like a global list of friends from LDAP besides the user-specific database, or just data from LDAP, and if LDAP is required to some extend, is "nice to have" or a strict requirement?

from tabby.

Wow, thank you for your interest in extending it! I'm using Authelia as my SSO provider. No SAML with that, just Forward Auth for Traefik for Docker containers. So really I just need a header to be accepted from Traefik for auth, with it pulling user data from LDAP for stuff like email addresses. I would only have users in LDAP, not their contacts.

To be completely honest, I haven't installed yet, since I run everything in Docker and the last image posted is fairly old. I'd be happy to help with that, along with anything else.

from tabby.

Since I haven't used Authelia or Treafik before, I reached out to some friends to find someone more familiar with this kind of deployment. If I understand it correctly, the idea is an application is aware of existing accounts through LDAP (so either because lots of information is available through an anonymous bind, or the application has an LDAP account that has a very broad ACL), and then simply accepts a specific header to decide which account it should presume is being used. Such a feature I should be able to add relatively easily.

There are however two important questions that remain:

1. Are you willing to test out development versions on your own infrastructure, so I can verify my code and changes work (in general and especially in your use case).
2. Have you had time to test out the software? If Tabby turns out not to offer the features or experience you're looking for, it seems silly to make all these changes aimed mostly at your use case.

When it comes to Docker, I'm personally not very interested in maintaining an image. A friend of mine used to maintain one, but I found the required changes made installing without docker quite difficult. I think it would make more sense to keep the necessary information for a docker image in a separate repository, which could be maintained by someone else. There's also the question whether you want to use MySQL or PostgreSQL, and whether the database is on a separate docker instance or not.

from tabby.

I spun up a VM and installed it, but haven't got a chance to really play with it yet. Was hoping to do that this weekend.

I haven't maintained a public docker image before, but I've been wanting a reason to learn more about CI pipelines, so if it's what I'm looking for, I'd be game to work on that. The database would be in a separate container, but I'd provide a compose file with it.

Now that I think of it, you can also get the email address from the headers, so yeah, there shouldn't be a need to implement LDAP directly, just create accounts based on authenticating and pulling that info from the headers.

Thanks for your time!

from tabby.

Let me know how your trial run goes this weekend!

Based on some googling, it seems like a compose file would indeed make sense. Feel free to create a docker image/repo I can link to

For an account, I basically need a (full) name, email address and IBAN. If those three are all available from headers that would make it much easier, though I expect IBAN isn't available in headers nor LDAP, so that might prove a challenge.

from tabby.

I tried to play around with it, but the problem I ran into was it requiring the IBAN you mentioned. The only references I could find for that appear to be a European standard banking number. I don't have one, as I'm in the US. If I've missed the mark and it's something completely different, please let me know.

from tabby.

I initially made Tabby for myself, since my friends and I kept forgetting to let each other repay pizza or groceries when we had dinner together. It was (and still to some extend is) therefore a bit EU and Belgium centric. The IBAN is the number required within Europe to perform a wire transfer (the bank account number, basically), which is how most people repay each other. While initially a European standard, it's quite international now (adaptation of IBAN has grown much beyond Europe). The application also presumes Euro. I could add an installation option to change terms like that. Replacing Euro with dollar is easy, but I'm not sure whether repaying friends is done by wire transfer in the US as well, and what kind of number is used for that (and what term to refer to it). Could you maybe give me a quick overview of what's popular and what terms are used? Don't forget to include some examples of so I'm aware of length and format.

from tabby.

@hutch0 I haven't heard back from you. I still don't mind looking into the necessary changes to make Tabby work for you, but I would need some more information for that first. Of course, if you've found another tool or noticed that Tabby isn't what you expected, then please let me know.

from tabby.

Closing, since reporter isn't responding any more. If anyone is willing to offer further information to implement and test this, then I can re-open it.

from tabby.

Here in the US we don't have IBAN numbers, we have ABA routing numbers. But no one uses those here in the States for anything outside of old, kermudgeony programs and what not...

Most of us are using apps like Chime, Cash.app, Zelle, and other app-based payment transfer services...

So, having an option that here in the US we could either simply list our payment usernames or if you have the time and what not, to have your service pull in the app's corresponding information for that account. (Like, Cash.app uses a QR code that our friends can scan to send money)

So, with this IBAN requirement, I'm completely unable to even use this service, which i'm really interested in trying out.

from tabby.

Here in the US we don't have IBAN numbers, we have ABA routing numbers. But no one uses those here in the States for anything outside of old, kermudgeony programs and what not...

Most of us are using apps like Chime, Cash.app, Zelle, and other app-based payment transfer services...

So, having an option that here in the US we could either simply list our payment usernames or if you have the time and what not, to have your service pull in the app's corresponding information for that account. (Like, Cash.app uses a QR code that our friends can scan to send money)

So, with this IBAN requirement, I'm completely unable to even use this service, which i'm really interested in trying out.

@jpartain89 In the spirit of not reviving dead issues, especially since this one is primarily about LDAP/SSO auth, could you please create a new issue? I don't want to spam hutch0 unnecessarily. I hope you don't mind, but I think we can probably figure something out.

from tabby.