migrating or onboarding existing users using LDAP and groups based ACLs

Todd Morgan toddlmorgan at gmail.com
Wed May 27 09:21:21 EDT 2015


Hi everyone,
   I'm not having much luck in migrating my existing Hg repositories and
uerss to Kallithea. My final final stumbling block is making the transition
seamless to my users. We have LDAP/CROWD based authentication for all of
the infrastructure and this needs to be used for Kallithea.

I can authenticate my users using LDAP - with the account being
created/linked in Kallithea at the point in time at which a user logs in
for the first time.

The problem is there are a large number of repositories which we are
currently managed by groups. Groups are not imported.

I have tried to use the LDAP group modification as detailed here
https://bitbucket.org/jfbeaumont/kallithea/commits/6cc72bef379ce1df856ed5f8b6f4b966#comment-1843342
but it didn't work with my LDAP - I tried contacting the original author
(no response) and this mailing list ...

So I wrote my own manual sync using the REST API (as per another
suggestion from this mailing list)... at which point I discovered that
wouldn't help me either.

   - I can't create accounts ahead of time that are authenticated using
   LDAP - they are all marked as "internal" - so they are in addition to the
   LDAP credentials - not merely delegating to them.
   - I can't create all the required user groups in advance and associate
   the existing accounts from the LDAP. Ie pre-create the user groups as the
   users can't be added as they don't exist in advance (ie so that the users
   are automatically associated with the correct group based access when their
   LDAP account is eventually added).

So is there something else I can consider to try and make this process
transparent and automagic to my users? I considered having a regular
scheduled manual sync process occurring such that every hour (or whenever)
I'd query the LDAP for all of the existing users in Kallithea and add the
associated user groups to Kallithea and add the user to them ... but that
won't enable users to transparently cut-over on day-one with their existing
repos ... they'd have to first fail to get access to their repository.

How have others approached this situation?

Thanks

    Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20150527/87b86914/attachment.html>


More information about the kallithea-general mailing list