Return-Path: X-Original-To: apmail-archiva-dev-archive@www.apache.org Delivered-To: apmail-archiva-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6D88BE47C for ; Mon, 3 Dec 2012 17:23:38 +0000 (UTC) Received: (qmail 84660 invoked by uid 500); 3 Dec 2012 17:23:38 -0000 Delivered-To: apmail-archiva-dev-archive@archiva.apache.org Received: (qmail 84610 invoked by uid 500); 3 Dec 2012 17:23:37 -0000 Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@archiva.apache.org Delivered-To: mailing list dev@archiva.apache.org Received: (qmail 84582 invoked by uid 99); 3 Dec 2012 17:23:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Dec 2012 17:23:36 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sascha.vogt@gmail.com designates 209.85.217.170 as permitted sender) Received: from [209.85.217.170] (HELO mail-lb0-f170.google.com) (209.85.217.170) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Dec 2012 17:23:26 +0000 Received: by mail-lb0-f170.google.com with SMTP id j14so2221640lbo.15 for ; Mon, 03 Dec 2012 09:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ScNI9bj7Wwzp4ltp0PxCNgBW7Lb7DRQgHDIGQnwrkq8=; b=D6CYp/NUqspsAItT+Y2Wn6OUOaH/B9SZLHs58gkXtiNb2NvvZqqIYGbjlZD1qAGLat UGJ98ZVKqn2HInANsmBIYyt3nDxqj63UXNJE08v//SorSRNysZ5/ikstIiIcni+pT64M BKqrFoUsGSJ/UQaCrclxrZy5emIEcjf74eyphU8GsNCengSs0pT/24t6S8PwvC+lAQ7N biSmhNS2UY/MeYH8uh5/yNf1v+n5qMytUvQKkdO6lU1jOXDhphQU+/I2sfsEXsrvVJTL 9on8cNXHFj3XLmVbu0C9oYmCWt1Y/drkef80PEI9qXrVSh9VSBdnAfeG9rGrP3NsXAlS S/iw== Received: by 10.112.8.37 with SMTP id o5mr4600662lba.135.1354555385618; Mon, 03 Dec 2012 09:23:05 -0800 (PST) Received: from [0.0.0.0] (static.88-198-121-125.clients.your-server.de. [88.198.121.125]) by mx.google.com with ESMTPS id ps11sm5638921lab.12.2012.12.03.09.23.03 (version=SSLv3 cipher=OTHER); Mon, 03 Dec 2012 09:23:04 -0800 (PST) Message-ID: <50BCDFF6.4020304@gmail.com> Date: Mon, 03 Dec 2012 18:23:02 +0100 From: Sascha Vogt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dev@archiva.apache.org Subject: Re: UserManager Impl choice via UI and ldap configuration References: <5EDDCDB7-07D8-4107-8F2D-05DCF5502925@apache.org> <50BC842D.9070505@gmail.com> <50BCCE22.8040300@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Am 03.12.2012 17:14, schrieb Olivier Lamy: >> I have the title a bit more concrete and a more general approach in the >> description. I think as in the title, having database being the backup >> of LDAP is a good first step, perfect would be to be able to chain >> various auth-modules (that way one could also have the database first, >> and second the LDAP, as a database lookup is much quicker than first >> waiting for an LDAP fail). > Some questions: > * what will be the content of the users screen (merge of n users > backend ? first id win ?) > * users backend (as ldap) can be read only so when a user is logged we > must which system he uses. but users can be in n systems. How do we > handle that ? Well, I think the easiest and most "transparent" way would be to only show the user from the first found auth-module. So if I configure LDAP to be the first, database second, and I have the same user in both, only the LDAP one is shown... I know this is not ideal, because if LDAP fails, the user would be looked up from the database and I wouldn't be able to add "rights" to that user, unless I first disable LDAP or shuffle the order of the auth-modules, though I find that tolerable. In generally one should keep the user-ids distinct otherwise everyone gets confused anyway, so I think this is a sensible restriction. If you want to be able to edit both accounts, just add that as a configuration "hiearachy", so first choose the auth-module, then show the users of that auth-module. If one wants to edit the other, one navigates up one level and selects the other module. But as I said, I think the hiding from above is perfectly tolerable. Though the second options has the advantage that from an admin point of view its always perfectly clear which user base I'm currently editing. By the way, these are just my thoughts, feel free to ignore them ;) I can even live without the auth-module chaining by now (we finally got a technical user added to our active directory and even got the damn password policy disabled for that one *g*) Greetings -Sascha-