You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Olivier Lamy <ol...@apache.org> on 2012/11/24 18:54:07 UTC
UserManager Impl choice via UI and ldap configuration
Hi Folks,
I have recently changed some stuff to be able to dynamically change
userManager impl used tru the UI (jdo or ldap) (see [1]). (and it
works :-) ).
Note this means user.manager.impl property from security.properties is
not used anymore.
I wonder if this property if here must win ?
Furthermore, I'd like to improve a bit ldap configuration and add
screens to configure dynamically (ldap server host/port, basedn
etc...) (maybe ldap mapper too).
In fact all content detailled here [2] must be configurable with the UI.
Makes sense ?
BTW more generally I wonder if we must continue read configuration
from security.properties ? (too ease my hack I would say no :-) )
WDYT ?
Thanks,
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
[1] http://archiva.apache.org/docs/1.4-M4-SNAPSHOT/adminguide/runtime-configuration.html
[2]http://archiva.apache.org/redback/integration/ldap.html
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
2012/11/25 Maria Odea Ching-Mallete <od...@gmail.com>:
> On Sun, Nov 25, 2012 at 1:54 AM, Olivier Lamy <ol...@apache.org> wrote:
>
>> Hi Folks,
>> I have recently changed some stuff to be able to dynamically change
>> userManager impl used tru the UI (jdo or ldap) (see [1]). (and it
>> works :-) ).
>>
>
> Cool, I'll give it a spin :)
>
>
>>
>> Note this means user.manager.impl property from security.properties is
>> not used anymore.
>> I wonder if this property if here must win ?
>>
>> Furthermore, I'd like to improve a bit ldap configuration and add
>> screens to configure dynamically (ldap server host/port, basedn
>> etc...) (maybe ldap mapper too).
>> In fact all content detailled here [2] must be configurable with the UI.
>>
>> Makes sense ?
>>
>
> If the user switches the user manager impl during runtime, is the user
> required to restart Archiva? Or will it be reloaded automatically?
no restart needed !
>
>
>> BTW more generally I wonder if we must continue read configuration
>> from security.properties ? (too ease my hack I would say no :-) )
>>
>> WDYT ?
>>
>
> I think if the user manager impl will be configurable via UI now, it would
> make more sense if the configuration for it are also set from the UI (maybe
> store/set them directly in the application context?)
>
>
>> Thanks,
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> [1]
>> http://archiva.apache.org/docs/1.4-M4-SNAPSHOT/adminguide/runtime-configuration.html
>> [2]http://archiva.apache.org/redback/integration/ldap.html
>>
>
>
> Thanks,
> Deng
>
> --
> Maria Odea Ching-Mallete | oching@apache.org |
> http://www.linkedin.com/in/mariaodeaching
Re: UserManager Impl choice via UI and ldap configuration
Posted by Maria Odea Ching-Mallete <od...@gmail.com>.
On Sun, Nov 25, 2012 at 1:54 AM, Olivier Lamy <ol...@apache.org> wrote:
> Hi Folks,
> I have recently changed some stuff to be able to dynamically change
> userManager impl used tru the UI (jdo or ldap) (see [1]). (and it
> works :-) ).
>
Cool, I'll give it a spin :)
>
> Note this means user.manager.impl property from security.properties is
> not used anymore.
> I wonder if this property if here must win ?
>
> Furthermore, I'd like to improve a bit ldap configuration and add
> screens to configure dynamically (ldap server host/port, basedn
> etc...) (maybe ldap mapper too).
> In fact all content detailled here [2] must be configurable with the UI.
>
> Makes sense ?
>
If the user switches the user manager impl during runtime, is the user
required to restart Archiva? Or will it be reloaded automatically?
> BTW more generally I wonder if we must continue read configuration
> from security.properties ? (too ease my hack I would say no :-) )
>
> WDYT ?
>
I think if the user manager impl will be configurable via UI now, it would
make more sense if the configuration for it are also set from the UI (maybe
store/set them directly in the application context?)
> Thanks,
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
> [1]
> http://archiva.apache.org/docs/1.4-M4-SNAPSHOT/adminguide/runtime-configuration.html
> [2]http://archiva.apache.org/redback/integration/ldap.html
>
Thanks,
Deng
--
Maria Odea Ching-Mallete | oching@apache.org |
http://www.linkedin.com/in/mariaodeaching
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/14 Olivier Lamy <ol...@apache.org>:
> 2012/12/14 Olivier Lamy <ol...@apache.org>:
>> 2012/12/14 Sascha Vogt <sa...@gmail.com>:
>>> Hi Olivier,
>>>
>>> Am 13.12.2012 10:02, schrieb Olivier Lamy:
>>>> fixed.
>>>> You can test builds from here:
>>>> https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
>>>> build >= #1749
>>>>
>>>> I still need some ui magnify to add but it works :-)
>>>
>>> thanks a lot. A gave it a try yesterday evening and it already looks
>>> really nice. I noticed a little thing: The ldap.config.bind.dn isn't
>>> exposed in the GUI
>> uhm sure ? :-)
> Ok I see I will fix that !
> Thanks for reporting !
fixed will be here
https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
build >= #1762
>>
>> BTW I started documentation on the new feature here:
>> http://archiva.apache.org/docs/1.4-M4-SNAPSHOT/adminguide/redback-runtime-configuration.html
>>
>>>
>>> Additionally I think the contextFactory could be filled by default with
>>> "com.sun.jndi.ldap.LdapCtxFactory" (Is there even another possible value
>>> in case of LDAP?)
>>>
>>> Thx again for the nice addition.
>>>
>>> Greetings
>>> -Sascha-
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/14 Olivier Lamy <ol...@apache.org>:
> 2012/12/14 Sascha Vogt <sa...@gmail.com>:
>> Hi Olivier,
>>
>> Am 13.12.2012 10:02, schrieb Olivier Lamy:
>>> fixed.
>>> You can test builds from here:
>>> https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
>>> build >= #1749
>>>
>>> I still need some ui magnify to add but it works :-)
>>
>> thanks a lot. A gave it a try yesterday evening and it already looks
>> really nice. I noticed a little thing: The ldap.config.bind.dn isn't
>> exposed in the GUI
> uhm sure ? :-)
Ok I see I will fix that !
Thanks for reporting !
>
> BTW I started documentation on the new feature here:
> http://archiva.apache.org/docs/1.4-M4-SNAPSHOT/adminguide/redback-runtime-configuration.html
>
>>
>> Additionally I think the contextFactory could be filled by default with
>> "com.sun.jndi.ldap.LdapCtxFactory" (Is there even another possible value
>> in case of LDAP?)
>>
>> Thx again for the nice addition.
>>
>> Greetings
>> -Sascha-
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/14 Sascha Vogt <sa...@gmail.com>:
> Hi Olivier,
>
> Am 13.12.2012 10:02, schrieb Olivier Lamy:
>> fixed.
>> You can test builds from here:
>> https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
>> build >= #1749
>>
>> I still need some ui magnify to add but it works :-)
>
> thanks a lot. A gave it a try yesterday evening and it already looks
> really nice. I noticed a little thing: The ldap.config.bind.dn isn't
> exposed in the GUI
uhm sure ? :-)
BTW I started documentation on the new feature here:
http://archiva.apache.org/docs/1.4-M4-SNAPSHOT/adminguide/redback-runtime-configuration.html
>
> Additionally I think the contextFactory could be filled by default with
> "com.sun.jndi.ldap.LdapCtxFactory" (Is there even another possible value
> in case of LDAP?)
>
> Thx again for the nice addition.
>
> Greetings
> -Sascha-
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Sascha Vogt <sa...@gmail.com>.
Hi Olivier,
Am 13.12.2012 10:02, schrieb Olivier Lamy:
> fixed.
> You can test builds from here:
> https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
> build >= #1749
>
> I still need some ui magnify to add but it works :-)
thanks a lot. A gave it a try yesterday evening and it already looks
really nice. I noticed a little thing: The ldap.config.bind.dn isn't
exposed in the GUI
Additionally I think the contextFactory could be filled by default with
"com.sun.jndi.ldap.LdapCtxFactory" (Is there even another possible value
in case of LDAP?)
Thx again for the nice addition.
Greetings
-Sascha-
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
fixed.
You can test builds from here:
https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
build >= #1749
I still need some ui magnify to add but it works :-)
2012/12/11 Olivier Lamy <ol...@apache.org>:
> Note: one case doesn't work yet.
> The same userid is in both ldap and jdo with different paswords.
> If try to log with the wrong password with the first impl, the login
> is rejected.
> I will try to fix that tomorrow.
>
> 2012/12/10 Olivier Lamy <ol...@apache.org>:
>> So mostly implemented, you can choose more than one userManager (jdo
>> and/or ldap) and specify the order.
>> Feel free to try a snapshot build from here:
>> https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
>> I need to add some UI improvements (magnify :-)) and verify various ui
>> part (users tables, modifying a user)
>> It's possible to configure ldap server too.
>>
>> @Brett note security.properties is checked first and then imported in
>> archiva.xml.
>> So must cover your use case :-)
>>
>>
>>
>> 2012/12/4 Olivier Lamy <ol...@apache.org>:
>>> 2012/12/3 Sascha Vogt <sa...@gmail.com>:
>>>> 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.
>>>>
>>> Sounds good and similar to what I have in mind :-)
>>>> By the way, these are just my thoughts, feel free to ignore them ;) I
>>> No you are probably using/managing more archiva instances than I do :-)
>>>> 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-
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
Note: one case doesn't work yet.
The same userid is in both ldap and jdo with different paswords.
If try to log with the wrong password with the first impl, the login
is rejected.
I will try to fix that tomorrow.
2012/12/10 Olivier Lamy <ol...@apache.org>:
> So mostly implemented, you can choose more than one userManager (jdo
> and/or ldap) and specify the order.
> Feel free to try a snapshot build from here:
> https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
> I need to add some UI improvements (magnify :-)) and verify various ui
> part (users tables, modifying a user)
> It's possible to configure ldap server too.
>
> @Brett note security.properties is checked first and then imported in
> archiva.xml.
> So must cover your use case :-)
>
>
>
> 2012/12/4 Olivier Lamy <ol...@apache.org>:
>> 2012/12/3 Sascha Vogt <sa...@gmail.com>:
>>> 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.
>>>
>> Sounds good and similar to what I have in mind :-)
>>> By the way, these are just my thoughts, feel free to ignore them ;) I
>> No you are probably using/managing more archiva instances than I do :-)
>>> 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-
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
So mostly implemented, you can choose more than one userManager (jdo
and/or ldap) and specify the order.
Feel free to try a snapshot build from here:
https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/
I need to add some UI improvements (magnify :-)) and verify various ui
part (users tables, modifying a user)
It's possible to configure ldap server too.
@Brett note security.properties is checked first and then imported in
archiva.xml.
So must cover your use case :-)
2012/12/4 Olivier Lamy <ol...@apache.org>:
> 2012/12/3 Sascha Vogt <sa...@gmail.com>:
>> 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.
>>
> Sounds good and similar to what I have in mind :-)
>> By the way, these are just my thoughts, feel free to ignore them ;) I
> No you are probably using/managing more archiva instances than I do :-)
>> 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-
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/3 Sascha Vogt <sa...@gmail.com>:
> 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.
>
Sounds good and similar to what I have in mind :-)
> By the way, these are just my thoughts, feel free to ignore them ;) I
No you are probably using/managing more archiva instances than I do :-)
> 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-
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Sascha Vogt <sa...@gmail.com>.
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-
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/3 Sascha Vogt <sa...@gmail.com>:
> Hi,
>
> Am 03.12.2012 12:01, schrieb Olivier Lamy:
>> 2012/12/3 Sascha Vogt <sa...@gmail.com>:
>>> I'm not sure if this falls into the same parts you're working on, but
>>> any chance that JDO could be the "fallback" auth, if LDAP doesn't work?
>>> The main use-case here is to have some "technical" users which are not
>>> in LDAP (e.g. a Jenkins) and one "last-resort" admin, to log in, if you
>>> mess up your LDAP ;)
>>
>> oh I have this idea too :-)
>> But this need *a lot of changes*
>> I can start with this dynamic change first.
>> Then have a look at this other feature. (can you raise a jira for that ?)
>
> Jira: http://jira.codehaus.org/browse/MRM-1721
Thanks.
>
> 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 ?
>
> Greetings
> -Sascha-
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Sascha Vogt <sa...@gmail.com>.
Hi,
Am 03.12.2012 12:01, schrieb Olivier Lamy:
> 2012/12/3 Sascha Vogt <sa...@gmail.com>:
>> I'm not sure if this falls into the same parts you're working on, but
>> any chance that JDO could be the "fallback" auth, if LDAP doesn't work?
>> The main use-case here is to have some "technical" users which are not
>> in LDAP (e.g. a Jenkins) and one "last-resort" admin, to log in, if you
>> mess up your LDAP ;)
>
> oh I have this idea too :-)
> But this need *a lot of changes*
> I can start with this dynamic change first.
> Then have a look at this other feature. (can you raise a jira for that ?)
Jira: http://jira.codehaus.org/browse/MRM-1721
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).
Greetings
-Sascha-
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/3 Sascha Vogt <sa...@gmail.com>:
> Hi Olivier,
>
> I'm not sure if this falls into the same parts you're working on, but
> any chance that JDO could be the "fallback" auth, if LDAP doesn't work?
> The main use-case here is to have some "technical" users which are not
> in LDAP (e.g. a Jenkins) and one "last-resort" admin, to log in, if you
> mess up your LDAP ;)
oh I have this idea too :-)
But this need *a lot of changes*
I can start with this dynamic change first.
Then have a look at this other feature. (can you raise a jira for that ?)
>
> Otherwise: Very much looking forward to this.
>
> Greetings
> -Sascha-
>
>
> Am 25.11.2012 08:57, schrieb Olivier Lamy:
>> 2012/11/25 Brett Porter <br...@apache.org>:
>>>
>>> On 25/11/2012, at 4:54 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>
>>>> Hi Folks,
>>>> I have recently changed some stuff to be able to dynamically change
>>>> userManager impl used tru the UI (jdo or ldap) (see [1]). (and it
>>>> works :-) ).
>>>
>>> Cool!
>>>
>>>>
>>>> Note this means user.manager.impl property from security.properties is
>>>> not used anymore.
>>>> I wonder if this property if here must win ?
>>>
>>> If you're storing it in a different configuration file, I think you should read the old config and populate the new (which wins after that) for easier upgrades.
>>>
>>>>
>>>> Furthermore, I'd like to improve a bit ldap configuration and add
>>>> screens to configure dynamically (ldap server host/port, basedn
>>>> etc...) (maybe ldap mapper too).
>>>> In fact all content detailled here [2] must be configurable with the UI.
>>>>
>>>> Makes sense ?
>>>> BTW more generally I wonder if we must continue read configuration
>>>> from security.properties ? (too ease my hack I would say no :-) )
>>>
>>> As above - please retain it, or at least migrate it to the new location; and make sure everything can be configured somewhere without the UI. I use that to lay down a fully functional Archiva without having to configure it by hand:
>>> https://github.com/maestrodev/puppet-archiva/blob/master/templates/security.properties.erb
>>>
>>
>> Yup make sense for such use case !
>> I will do that (if security.properties exists migrate that to new model)
>>
>>
>>> Cheers,
>>> Brett
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Sascha Vogt <sa...@gmail.com>.
Hi Olivier,
I'm not sure if this falls into the same parts you're working on, but
any chance that JDO could be the "fallback" auth, if LDAP doesn't work?
The main use-case here is to have some "technical" users which are not
in LDAP (e.g. a Jenkins) and one "last-resort" admin, to log in, if you
mess up your LDAP ;)
Otherwise: Very much looking forward to this.
Greetings
-Sascha-
Am 25.11.2012 08:57, schrieb Olivier Lamy:
> 2012/11/25 Brett Porter <br...@apache.org>:
>>
>> On 25/11/2012, at 4:54 AM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> Hi Folks,
>>> I have recently changed some stuff to be able to dynamically change
>>> userManager impl used tru the UI (jdo or ldap) (see [1]). (and it
>>> works :-) ).
>>
>> Cool!
>>
>>>
>>> Note this means user.manager.impl property from security.properties is
>>> not used anymore.
>>> I wonder if this property if here must win ?
>>
>> If you're storing it in a different configuration file, I think you should read the old config and populate the new (which wins after that) for easier upgrades.
>>
>>>
>>> Furthermore, I'd like to improve a bit ldap configuration and add
>>> screens to configure dynamically (ldap server host/port, basedn
>>> etc...) (maybe ldap mapper too).
>>> In fact all content detailled here [2] must be configurable with the UI.
>>>
>>> Makes sense ?
>>> BTW more generally I wonder if we must continue read configuration
>>> from security.properties ? (too ease my hack I would say no :-) )
>>
>> As above - please retain it, or at least migrate it to the new location; and make sure everything can be configured somewhere without the UI. I use that to lay down a fully functional Archiva without having to configure it by hand:
>> https://github.com/maestrodev/puppet-archiva/blob/master/templates/security.properties.erb
>>
>
> Yup make sense for such use case !
> I will do that (if security.properties exists migrate that to new model)
>
>
>> Cheers,
>> Brett
Re: UserManager Impl choice via UI and ldap configuration
Posted by Olivier Lamy <ol...@apache.org>.
2012/11/25 Brett Porter <br...@apache.org>:
>
> On 25/11/2012, at 4:54 AM, Olivier Lamy <ol...@apache.org> wrote:
>
>> Hi Folks,
>> I have recently changed some stuff to be able to dynamically change
>> userManager impl used tru the UI (jdo or ldap) (see [1]). (and it
>> works :-) ).
>
> Cool!
>
>>
>> Note this means user.manager.impl property from security.properties is
>> not used anymore.
>> I wonder if this property if here must win ?
>
> If you're storing it in a different configuration file, I think you should read the old config and populate the new (which wins after that) for easier upgrades.
>
>>
>> Furthermore, I'd like to improve a bit ldap configuration and add
>> screens to configure dynamically (ldap server host/port, basedn
>> etc...) (maybe ldap mapper too).
>> In fact all content detailled here [2] must be configurable with the UI.
>>
>> Makes sense ?
>> BTW more generally I wonder if we must continue read configuration
>> from security.properties ? (too ease my hack I would say no :-) )
>
> As above - please retain it, or at least migrate it to the new location; and make sure everything can be configured somewhere without the UI. I use that to lay down a fully functional Archiva without having to configure it by hand:
> https://github.com/maestrodev/puppet-archiva/blob/master/templates/security.properties.erb
>
Yup make sense for such use case !
I will do that (if security.properties exists migrate that to new model)
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: UserManager Impl choice via UI and ldap configuration
Posted by Brett Porter <br...@apache.org>.
On 25/11/2012, at 4:54 AM, Olivier Lamy <ol...@apache.org> wrote:
> Hi Folks,
> I have recently changed some stuff to be able to dynamically change
> userManager impl used tru the UI (jdo or ldap) (see [1]). (and it
> works :-) ).
Cool!
>
> Note this means user.manager.impl property from security.properties is
> not used anymore.
> I wonder if this property if here must win ?
If you're storing it in a different configuration file, I think you should read the old config and populate the new (which wins after that) for easier upgrades.
>
> Furthermore, I'd like to improve a bit ldap configuration and add
> screens to configure dynamically (ldap server host/port, basedn
> etc...) (maybe ldap mapper too).
> In fact all content detailled here [2] must be configurable with the UI.
>
> Makes sense ?
> BTW more generally I wonder if we must continue read configuration
> from security.properties ? (too ease my hack I would say no :-) )
As above - please retain it, or at least migrate it to the new location; and make sure everything can be configured somewhere without the UI. I use that to lay down a fully functional Archiva without having to configure it by hand:
https://github.com/maestrodev/puppet-archiva/blob/master/templates/security.properties.erb
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter