Re: [Freedombox-discuss] LDAP
On Fri, 2013-12-27 at 20:39 -0600, Nick Daly wrote: Simo s...@ssimo.org writes: On Fri, 2013-12-27 at 19:08 -0600, Nick Daly wrote: Time to do a lot of LDAP (or Kerberos, or...) learning. Do yourself a favor, nix their auth system and use apache modules, mediawiki has a module to understand REMOTE_USER, so should other services like that. Once you find one that understand REMOTE_USER you can defer authentication compeltely to apache and not have to learn/implement/tweak each single service in a different way. Could you clarify or point to an example of where this is used well? I am not sure what you mean, but you can bet all cases where a x509 cert is used for example, the auth is done in apache by mod_ssl or mod_nss and the application trusts the REMOTE_USER environment variable. There're lots of results, but there's also a lot of chaff in those results. Anything you want to know better ? Seems like ikiwiki's httpauth [0] respects REMOTE_USER, which seems ideal for the wiki service. Now as long as everything else does the same... Yeah, this I remembered which is why I suggested you to use REMOTE_USER, it's at the same time a very low common denominator but also very flexbile because all you need to change is the apache configuration and not each single application, too bad modern time web developers forgot about it and went full steam exclusively with form based authentication, which shouldn't be nixed to be clear. At the momoent I am actually working on an Identity provider project that will be able to delegate to the Ido the actual authentication and then using an apache module (unless you want to talk SAML directly) perform actual auth for applications and fill in REMOTE_USER and potentially other variables. Once it has some better UI I will send you a link to it. Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Bdale Garbee bd...@gag.com writes: Jonas Smedegaard d...@jones.dk writes: Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. ...Clearly not critical path, but this is another possible task for someone out there reading who would like a modest project that could help us out in the long term. What I think we can effectively use LDAP for is to manage the information associated with identities. Users, what access rights they should have, etc, in an application-neutral way that we can potentially wrap some plinth UI goodness around eventually. It should also be possible to use these sorts of ACLs to create application-specific data-stores (among other things, to keep applications from snooping on one another's data). Keeping data separated is a related, but different, issue from the problem of separating processes (the LXC/VM issue). So, does anybody know any good LDAP-enabled services we can use? I tried to move a wiki service into Plinth (ikiwiki, via [0]), but immediately ran into the problem that ikiwiki knows nothing about authentication mechanisms other than its own. I'm checking on the ikiwiki IRC channel and their forums, but very few wiki services (other than MediaWiki, which feels like overkill) are aware of LDAP. Time to do a lot of LDAP (or Kerberos, or...) learning. Thanks, Nick 0: https://bitbucket.org/nickdaly/plugserver/src/tip/setup/wiki/ pgpQB7pDKTFn8.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Quoting Nick Daly (2013-12-28 02:08:39) Bdale Garbee bd...@gag.com writes: Jonas Smedegaard d...@jones.dk writes: Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. ...Clearly not critical path, but this is another possible task for someone out there reading who would like a modest project that could help us out in the long term. What I think we can effectively use LDAP for is to manage the information associated with identities. Users, what access rights they should have, etc, in an application-neutral way that we can potentially wrap some plinth UI goodness around eventually. It should also be possible to use these sorts of ACLs to create application-specific data-stores (among other things, to keep applications from snooping on one another's data). Keeping data separated is a related, but different, issue from the problem of separating processes (the LXC/VM issue). Which applications do you have in mind which stores their data in LDAP? Or do you envision (even more!) applications written from scratch specific for FreedomBox? So, does anybody know any good LDAP-enabled services we can use? I tried to move a wiki service into Plinth (ikiwiki, via [0]), but immediately ran into the problem that ikiwiki knows nothing about authentication mechanisms other than its own. I'm checking on the ikiwiki IRC channel and their forums, but very few wiki services (other than MediaWiki, which feels like overkill) are aware of LDAP. Not sure what you mean by knows nothing [...] other than its own. Here's a list of auth plugins: https://ikiwiki.info/plugins/type/auth/ I have not played with it myself, but believe you should be able to use either httpauth plugin + libapache module or unixauth + PAM module. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
On Fri, 2013-12-27 at 19:08 -0600, Nick Daly wrote: Bdale Garbee bd...@gag.com writes: Jonas Smedegaard d...@jones.dk writes: Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. ...Clearly not critical path, but this is another possible task for someone out there reading who would like a modest project that could help us out in the long term. What I think we can effectively use LDAP for is to manage the information associated with identities. Users, what access rights they should have, etc, in an application-neutral way that we can potentially wrap some plinth UI goodness around eventually. It should also be possible to use these sorts of ACLs to create application-specific data-stores (among other things, to keep applications from snooping on one another's data). Keeping data separated is a related, but different, issue from the problem of separating processes (the LXC/VM issue). So, does anybody know any good LDAP-enabled services we can use? I tried to move a wiki service into Plinth (ikiwiki, via [0]), but immediately ran into the problem that ikiwiki knows nothing about authentication mechanisms other than its own. I'm checking on the ikiwiki IRC channel and their forums, but very few wiki services (other than MediaWiki, which feels like overkill) are aware of LDAP. Time to do a lot of LDAP (or Kerberos, or...) learning. Do yourself a favor, nix their auth system and use apache modules, mediawiki has a module to understand REMOTE_USER, so should other services like that. Once you find one that understand REMOTE_USER you can defer authentication compeltely to apache and not have to learn/implement/tweak each single service in a different way. Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Jonas Smedegaard d...@jones.dk writes: Which applications do you have in mind which stores their data in LDAP? Or do you envision (even more!) applications written from scratch specific for FreedomBox? I was imagining using LDAP as the ACL for application data, not as a data store itself, though I suppose it could be used that way, sorry if I was unclear. I really don't want more things from scratch. I want glue. Were webmin packaged (or if someone would suggest similar already packaged administration tools), this'd be easier. Here's a list of auth plugins: https://ikiwiki.info/plugins/type/auth/ I have not played with it myself, but believe you should be able to use either httpauth plugin + libapache module or unixauth + PAM module. Thanks, I missed httpauth earlier. I saw unixauth, saw that it seemed like it'd do the trick, and then realized that it wasn't packaged in Debian, or even in ikiwiki. Seems like httpauth and mod_authnz_ldap [0] could do the trick. I should be able to bang out a simple authentication PoC quickly. I'll put that on the TODO list, though anyone with the time is welcome to beat me to it or point to an existing example/tutorial. Thanks, Nick 0: https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html pgpzuenXdNxlx.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Simo s...@ssimo.org writes: On Fri, 2013-12-27 at 19:08 -0600, Nick Daly wrote: Time to do a lot of LDAP (or Kerberos, or...) learning. Do yourself a favor, nix their auth system and use apache modules, mediawiki has a module to understand REMOTE_USER, so should other services like that. Once you find one that understand REMOTE_USER you can defer authentication compeltely to apache and not have to learn/implement/tweak each single service in a different way. Could you clarify or point to an example of where this is used well? There're lots of results, but there's also a lot of chaff in those results. Seems like ikiwiki's httpauth [0] respects REMOTE_USER, which seems ideal for the wiki service. Now as long as everything else does the same... Nick 0: http://ikiwiki.info/plugins/httpauth/ pgpheTdGzCMRJ.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Jonas Smedegaard d...@jones.dk writes: Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. It probably isn't, but I don't know of anything better. Note that I traded emails in Feb with Howard Chu about using LDAP in this local-only way, and he strongly suggested we create an optimized build of openldap with a smaller footprint than the Debian standard build. Clearly not critical path, but this is another possible task for someone out there reading who would like a modest project that could help us out in the long term. It is of *big* importance to me that we do *not* move storage from /etc to a database: It may seem tempting to use that approach when needing a setup different from what the corresponding package maintainer offers, but since we have *no* administrator on our systems, our setup *must* be supported by package maintainers. I agree. What I think we can effectively use LDAP for is to manage the information associated with identities. Users, what access rights they should have, etc, in an application-neutral way that we can potentially wrap some plinth UI goodness around eventually. Bdale pgpGUezg64yP4.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
[Lorenzo] For these reasons I think it's not necessary to put LDAP in the freedombox. Maybe I'm overlooking something (maybe some critical daemon is incompatible with SASL?). I hope what I wrote can be of help in the design, I'm curious to hear what are the other opinions on this topic. The reason I believe it is a good idea to have LDAP on the freedombox, is that it reduces the number of user databases on the system. Some web service systems, like owncloud and ejabberd, have their own user databases while also supporting LDAP as their user database backend. Several, or perhaps most, do not use /etc/passwd as their user database. So we can either maintain several user databases specific to a lot of the services we want to set up in the Freedombox, or we can maintain one in LDAP and hook the services up to LDAP to use one common user database instead. I prefer the latter. In addition, we get a central and structured place to store configuration for at least some of the services, but that is of less importance to me. -- Happy hacking Petter Reinholdtsen ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Quoting Petter Reinholdtsen (2013-11-03 09:49:24) [Lorenzo] For these reasons I think it's not necessary to put LDAP in the freedombox. Maybe I'm overlooking something (maybe some critical daemon is incompatible with SASL?). I hope what I wrote can be of help in the design, I'm curious to hear what are the other opinions on this topic. The reason I believe it is a good idea to have LDAP on the freedombox, is that it reduces the number of user databases on the system. Some web service systems, like owncloud and ejabberd, have their own user databases while also supporting LDAP as their user database backend. Several, or perhaps most, do not use /etc/passwd as their user database. So we can either maintain several user databases specific to a lot of the services we want to set up in the Freedombox, or we can maintain one in LDAP and hook the services up to LDAP to use one common user database instead. I prefer the latter. Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. Beware that simply supports LDAP may not tell the full story: Some applications integrate with LDAP only by optional lookups of LDAP records, while maintaining its user data in a custom database anyway (i.e. not writing back to LDAP). If LDAP is used only for readonly user/group data, not for sharing other user data and not updated from the applications, then it might be safer to write a script exporting POSIX info to those applications needing a custom format (e.g. as a cron job or added as hooks to e.g. change of password. Ejabberd, specifically, _does_ support POSIX getent. That's the very reason I suggested to use that daemon: I have experience using it in production, because it fits my requirements of using that simple shared auth mechanism. Hint for someone wanting to help: Above has to potentially low hanging fruits: * collect concrete data on which applications support which shared mechanisms for user/group management, and whether the support is readonly or read/write. * document how to make prosody use getent. In addition, we get a central and structured place to store configuration for at least some of the services, but that is of less importance to me. It is of *big* importance to me that we do *not* move storage from /etc to a database: It may seem tempting to use that approach when needing a setup different from what the corresponding package maintainer offers, but since we have *no* administrator on our systems, our setup *must* be supported by package maintainers. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote: Quoting Petter Reinholdtsen (2013-11-03 09:49:24) [Lorenzo] For these reasons I think it's not necessary to put LDAP in the freedombox. Maybe I'm overlooking something (maybe some critical daemon is incompatible with SASL?). I hope what I wrote can be of help in the design, I'm curious to hear what are the other opinions on this topic. The reason I believe it is a good idea to have LDAP on the freedombox, is that it reduces the number of user databases on the system. Some web service systems, like owncloud and ejabberd, have their own user databases while also supporting LDAP as their user database backend. Several, or perhaps most, do not use /etc/passwd as their user database. So we can either maintain several user databases specific to a lot of the services we want to set up in the Freedombox, or we can maintain one in LDAP and hook the services up to LDAP to use one common user database instead. I prefer the latter. Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. Beware that simply supports LDAP may not tell the full story: Some applications integrate with LDAP only by optional lookups of LDAP records, while maintaining its user data in a custom database anyway (i.e. not writing back to LDAP). If LDAP is used only for readonly user/group data, not for sharing other user data and not updated from the applications, then it might be safer to write a script exporting POSIX info to those applications needing a custom format (e.g. as a cron job or added as hooks to e.g. change of password. Ejabberd, specifically, _does_ support POSIX getent. That's the very reason I suggested to use that daemon: I have experience using it in production, because it fits my requirements of using that simple shared auth mechanism. It would help to avoid confusing identity store with authentication or authorization mechanisms. Hint for someone wanting to help: Above has to potentially low hanging fruits: * collect concrete data on which applications support which shared mechanisms for user/group management, and whether the support is readonly or read/write. Read Only is the most sensible, you do not want random apps to be able to write to an identity store, or you open up your flank for privileges escalations. * document how to make prosody use getent. the nsswitch interface (which is what you refer to with getent) is pluggable, so LDAP would fit in quite easily, there are a number of tools that provide plugins for all sort of identity stores. In addition, we get a central and structured place to store configuration for at least some of the services, but that is of less importance to me. It is of *big* importance to me that we do *not* move storage from /etc to a database: It may seem tempting to use that approach when needing a setup different from what the corresponding package maintainer offers, but since we have *no* administrator on our systems, our setup *must* be supported by package maintainers. I am not sure what this means, package maintainers normally call adduser/addgroup or similar, how is that a problem ? Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Quoting Simo (2013-11-03 18:02:56) On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote: Quoting Petter Reinholdtsen (2013-11-03 09:49:24) [Lorenzo] For these reasons I think it's not necessary to put LDAP in the freedombox. Maybe I'm overlooking something (maybe some critical daemon is incompatible with SASL?). I hope what I wrote can be of help in the design, I'm curious to hear what are the other opinions on this topic. The reason I believe it is a good idea to have LDAP on the freedombox, is that it reduces the number of user databases on the system. Some web service systems, like owncloud and ejabberd, have their own user databases while also supporting LDAP as their user database backend. Several, or perhaps most, do not use /etc/passwd as their user database. So we can either maintain several user databases specific to a lot of the services we want to set up in the Freedombox, or we can maintain one in LDAP and hook the services up to LDAP to use one common user database instead. I prefer the latter. Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. Beware that simply supports LDAP may not tell the full story: Some applications integrate with LDAP only by optional lookups of LDAP records, while maintaining its user data in a custom database anyway (i.e. not writing back to LDAP). If LDAP is used only for readonly user/group data, not for sharing other user data and not updated from the applications, then it might be safer to write a script exporting POSIX info to those applications needing a custom format (e.g. as a cron job or added as hooks to e.g. change of password. Ejabberd, specifically, _does_ support POSIX getent. That's the very reason I suggested to use that daemon: I have experience using it in production, because it fits my requirements of using that simple shared auth mechanism. It would help to avoid confusing identity store with authentication or authorization mechanisms. Please elaborate on the differences. Hint for someone wanting to help: Above has to potentially low hanging fruits: * collect concrete data on which applications support which shared mechanisms for user/group management, and whether the support is readonly or read/write. Read Only is the most sensible, you do not want random apps to be able to write to an identity store, or you open up your flank for privileges escalations. * document how to make prosody use getent. the nsswitch interface (which is what you refer to with getent) is pluggable, so LDAP would fit in quite easily, there are a number of tools that provide plugins for all sort of identity stores. Petter suggests that FreedomBox use LDAP. I suggest to try keep it simpler. Yes, LDAP supports nsswitch, but that does not help keep the actual software stack simpler. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
On Sun, 2013-11-03 at 18:40 +0100, Jonas Smedegaard wrote: Quoting Simo (2013-11-03 18:02:56) On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote: Quoting Petter Reinholdtsen (2013-11-03 09:49:24) [Lorenzo] For these reasons I think it's not necessary to put LDAP in the freedombox. Maybe I'm overlooking something (maybe some critical daemon is incompatible with SASL?). I hope what I wrote can be of help in the design, I'm curious to hear what are the other opinions on this topic. The reason I believe it is a good idea to have LDAP on the freedombox, is that it reduces the number of user databases on the system. Some web service systems, like owncloud and ejabberd, have their own user databases while also supporting LDAP as their user database backend. Several, or perhaps most, do not use /etc/passwd as their user database. So we can either maintain several user databases specific to a lot of the services we want to set up in the Freedombox, or we can maintain one in LDAP and hook the services up to LDAP to use one common user database instead. I prefer the latter. Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. Beware that simply supports LDAP may not tell the full story: Some applications integrate with LDAP only by optional lookups of LDAP records, while maintaining its user data in a custom database anyway (i.e. not writing back to LDAP). If LDAP is used only for readonly user/group data, not for sharing other user data and not updated from the applications, then it might be safer to write a script exporting POSIX info to those applications needing a custom format (e.g. as a cron job or added as hooks to e.g. change of password. Ejabberd, specifically, _does_ support POSIX getent. That's the very reason I suggested to use that daemon: I have experience using it in production, because it fits my requirements of using that simple shared auth mechanism. It would help to avoid confusing identity store with authentication or authorization mechanisms. Please elaborate on the differences. You seemed to mix authenticating against an LDAP server and using it as an identity store. Although both functions are supported by LDAP servers it is not always the case that both are used by a system. For example many enterprise systems use an LDAP directory to hold user information but then use Kerberos for authentication and authorization is enforced on clients based on policies pushed via files or other methods. I was just cautioning that trying to lump all uses together was not productive for the discussion. Hint for someone wanting to help: Above has to potentially low hanging fruits: * collect concrete data on which applications support which shared mechanisms for user/group management, and whether the support is readonly or read/write. Read Only is the most sensible, you do not want random apps to be able to write to an identity store, or you open up your flank for privileges escalations. * document how to make prosody use getent. the nsswitch interface (which is what you refer to with getent) is pluggable, so LDAP would fit in quite easily, there are a number of tools that provide plugins for all sort of identity stores. Petter suggests that FreedomBox use LDAP. I suggest to try keep it simpler. Yes, LDAP supports nsswitch, but that does not help keep the actual software stack simpler. I tend to agree, given the freedombox is a simple standalone machine by nature, it makes little sense to use something complex like LDAP, one more thing that can break and cause issues, and I said this as a fervent LDAP proponent in the enterprise and everyday user and developer :) Simo. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Quoting Lorenzo (2013-10-09 11:41:56) I was checking the TODO list prepared Nick Daly and I see some references to integrating LDAP in the FB. I tried to find more about it but I could not find anything in the mailing list archives nor on the wiki. I'm writing this email because I spent some time thinking about the need of LDAP in isolated hosts some time ago and I wanted to share my findinings. 1) Centralized user authentication [...] 2) Centralized [access-controlled] configuration [...] 3) Read only directory of users of the box [...] Any Debian system already has [...] /etc/passwd [extendable with SASL, PAM, Plinth, CardDAV and XMPP]. For these reasons I think it's not necessary to put LDAP in the freedombox. Maybe I'm overlooking something (maybe some critical daemon is incompatible with SASL?). I hope what I wrote can be of help in the design, I'm curious to hear what are the other opinions on this topic. Thanks for these reflections. I look forward to some clarification for that too, as it isn't obvious to me either: Personally I haven't needed LDAP for any of the single-host systems I have ever maintained. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
