www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mason ...@jmason.org>
Subject Re: change Hudson to use LDAP for web auth
Date Tue, 07 Jul 2009 13:32:58 GMT
On Tue, Jul 7, 2009 at 14:16, Emmanuel Lécharny<elecharny@apache.org> wrote:
> Justin Mason wrote:
>>
>> On Tue, Jul 7, 2009 at 13:12, Emmanuel Lécharny<elecharny@apache.org>
>> wrote:
>>
>>>
>>> Justin Mason wrote:
>>>
>>>>
>>>> currently, Hudson.zones.apache.org has two user auth dbs:
>>>>
>>>> 1. a Tomcat tomcat-users.xml file to authenticate Hudson users over HTTP
>>>>
>>>> 2. /etc/passwd, to auth users logging in via SSH
>>>>
>>>> Now, #2 should probably not yet be changed to use the ASF's LDAP, as
>>>> we restrict Hudson changes to PMC members, rather than all committers.
>>>>  But #1 could be changed to do this, since there's an additional layer
>>>> of authorization imposed by the Hudson configuration.  it'd be great
>>>> to do this since it'd remove an entire set of user/passwords for us to
>>>> maintain.
>>>>
>>>> We could authenticate their logins via LDAP, but restrict changes to
>>>> the authorized list in that Hudson config.  Looking at
>>>> http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JNDIRealm ,
>>>> this looks pretty feasible.
>>>>
>>>> Infra - is this viable?  can we set this up?  has anyone got
>>>> experience using JNDIRealm with LDAP? does it work?
>>>>
>>>>
>>>
>>> You can have a look at :
>>> http://directory.apache.org/apacheds/1.0/42-apache-tomcat.html
>>>
>>> It explains how to use ApacheDS as a LDAP server, but this should be OK
>>> for
>>> any LDAP server.
>>>
>>> If any question, feel free to mail directory@a.o.
>>>
>>
>> cool, thanks for the tip Emmanuel!
>>
>> I've just realised, there's another possible issue.  Right now hudson
>> is not set up to use HTTPS, so passwords will be sent in the clear.
>> If the passwords in LDAP are not currently visible in the clear
>> elsewhere, we will probably need to get HTTPS running on Hudson first,
>> and ensure that the login form switches to HTTPS, before this is safe
>> to do.
>>
>
> Absolutely.
>
> What about using certificates at some point? Kerberos ?

eek!  let's walk before we run ;)

--j.

Mime
View raw message