Return-Path: 
 <users-return-3031-apmail-archiva-users-archive=archiva.apache.org@archiva.apache.org>
Delivered-To: apmail-archiva-users-archive@www.apache.org
Received: (qmail 62949 invoked from network); 15 Feb 2011 19:48:59 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 15 Feb 2011 19:48:59 -0000
Received: (qmail 44385 invoked by uid 500); 15 Feb 2011 19:48:58 -0000
Delivered-To: apmail-archiva-users-archive@archiva.apache.org
Received: (qmail 44147 invoked by uid 500); 15 Feb 2011 19:48:56 -0000
Mailing-List: contact users-help@archiva.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@archiva.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@archiva.apache.org>
List-Post: <mailto:users@archiva.apache.org>
List-Id: <users.archiva.apache.org>
Reply-To: users@archiva.apache.org
Delivered-To: mailing list users@archiva.apache.org
Received: (qmail 44139 invoked by uid 99); 15 Feb 2011 19:48:55 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Feb 2011 19:48:55 +0000
X-ASF-Spam-Status: No, hits=-1997.8 required=5.0
	tests=ALL_TRUSTED,HTML_MESSAGE,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9)
    by apache.org (qpsmtpd/0.29) with SMTP; Tue, 15 Feb 2011 19:48:54 +0000
Received: (qmail 62915 invoked by uid 99); 15 Feb 2011 19:48:33 -0000
Received: from localhost.apache.org (HELO mail-iw0-f170.google.com)
 (127.0.0.1)
  (smtp-auth username batkinson, mechanism plain)
  by minotaur.apache.org (qpsmtpd/0.29) with ESMTP;
 Tue, 15 Feb 2011 19:48:33 +0000
Received: by iwn6 with SMTP id 6so616516iwn.15
        for <users@archiva.apache.org>; Tue, 15 Feb 2011 11:48:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.171.138 with SMTP id j10mr7268691icz.0.1297799313017; Tue,
 15 Feb 2011 11:48:33 -0800 (PST)
Received: by 10.42.140.198 with HTTP; Tue, 15 Feb 2011 11:48:32 -0800 (PST)
In-Reply-To: <C9802CE1.7CE6%yqian@ku.edu>
References: <AANLkTinWSGOEK8nG6fOpH0EfeGZWnpYxYE7DXa3r=Wyy@mail.gmail.com>
	<C9802CE1.7CE6%yqian@ku.edu>
Date: Tue, 15 Feb 2011 14:48:32 -0500
Message-ID: <AANLkTik+xyX0GzU2GSgwJYP8kZx__66UX1X-CA2PGK2R@mail.gmail.com>
Subject: Re: authentication against LDAP
From: Brent Atkinson <batkinson@apache.org>
To: users <users@archiva.apache.org>
Content-Type: multipart/alternative; boundary=90e6ba6e884c0acd43049c577311

--90e6ba6e884c0acd43049c577311
Content-Type: text/plain; charset=ISO-8859-1

Responses in-line.

On Tue, Feb 15, 2011 at 2:28 PM, Qian, Yi <yqian@ku.edu> wrote:

> Hello, Brent
>
> 1. I will try the patch
> 2. I am not going to mess with the LDAP entries, my intention is to query
> the isMemberOf attribute, so the redback authentication can redirect user
> based on query result.
>

Depending on how much control you want over the permissions granted to
archiva users with the LDAP groups, this could obviate the need for a
moderately complex mapping tool so you can say LDAP group X grants
permissions A, B and C. Redback assumes management of permissions at the
application level, not the directory level. Trying to invert that may be
more tricky than you might expect. Are you trying to actually manage
permissions in Archiva using LDAP membership, or are you just looking to
limit the users allowed to access archiva? You may be able to do the latter
with configuration.


> 3. Following is my settings.xml in ~/.m2/ folder, which has my login
> credential in it, my question is I would like to avoid put even encrypted
> credential in a file, there is a way to force user login when using
> archiva, but also keep the login alive for some time period?
>
> <settings>
>        <mirrors>
>        <mirror>
>                <id>internal</id>
>             <name>Team maven repository</name>
>                <url>http://host:8080/archiva/repository/internal/</url>
>                <mirrorOf>*</mirrorOf>
>        </mirror>
>        </mirrors>
>
>
>        <servers>
>        <server>
>                <id>internal</id>
>                <username>name</username>
>                <password>password</password>
>        </server>
>        <server>
>                <id>release</id>
>                <username>name</username>
>                <password>password</password>
>        </server>
>        <server>
>                <id>snapshots</id>
>                <username>name</username>
>                <password>password</password>
>        </server>
>        </servers>
> </settings>
>
>
> Regards,
>
> Yi
>
> On 2/15/11 11:07 AM, "Brent Atkinson" <batkinson@apache.org> wrote:
>
> >Comments are in-line.
> >
> >On Tue, Feb 15, 2011 at 11:03 AM, Qian, Yi <yqian@ku.edu> wrote:
> >
> >> Hello, Brett and Brent
> >>
> >> Thanks for your reply. I deployed archiva as stand-alone with jetty
> >> bundle. I do not have admin user configured in LDAP. So I changed
> >> redback.default.admin to my ID and it works.
> >
> >
> >
> >> I still have some questions about the authentication
> >> 1. Do I have to set up redback.default.admin property? Seems to me the
> >> answer is yes because even after I commented out this property in
> >> security.properties file, archiva still redirected me to addadmin page.
> >> But If this is true, we have to create an admin account in LDAP only for
> >> archiva.
> >>
> >
> >An admin user is required to exist in whatever authentication source
> >you've
> >configured. If there isn't such a user, archiva will ask you to create
> >one.
> >Setting it to your account satisfies this admin user check. I developed a
> >patch for redback that allows you to create hardwired utility accounts
> >when
> >you can't or don't want to pollute the LDAP tree. It hasn't been
> >integrated
> >yet, mostly because I wanted to get feedback on it and because it affects
> >both archiva and continuum configurations. The issue is REDBACK-266 if
> >you're interested in trying it out. Any feedback you can give will be
> >appreciated. Just comment on the issue.
> >
> >
> >> 2. In our LDAP, user entry has multi-valued attributes isMemberOf, can
> >>we
> >> set up redback to check this attribute, so if user is not belong to
> >> certain group, archiva will redirect the user to unauthorized page. If
> >> this feature does not exist yet, please point me the direction and I am
> >> willing to do the customized code change.
> >>
> >
> >AFAIK, redback doesn't use membership attributes in LDAP for
> >authorization.
> >One reason is that there are multiple ways that membership is handled in
> >various LDAP implementations/schemas. Due to the complexity of trying to
> >safely manage LDAP directories, redback doesn't manipulate the directory.
> >It
> >only reads from them. This allows users to authenticate with consistent
> >logins, and management of permissions happens at the application level
> >(not
> >the directory level).
> >
> >
> >> 3. There is settings.xml file in my local ~/.m2/ folder, this
> >>settings.xml
> >> include my login credential, can we skip the credential and force user
> >>to
> >> login when he trying to use archiva and keep a session so he can use the
> >> archiva without login again if the session is alive?
> >>
> >> And again, if any above feature does not exist, I am willing to add it.
> >>
> >
> >Not sure what you're asking about here. The settings.xml file is primarily
> >used by maven plugins to authenticate. Are you suggesting that the http
> >session be shared across your maven builds and your web browser?
> >
> >
> >> Regards,
> >>
> >> Yi
> >>
> >>
> >> On 2/14/11 11:34 PM, "Brett Porter" <brett@apache.org> wrote:
> >>
> >> >Did you go ahead with that screen and then check what "User Management"
> >> >showed for available users?
> >> >
> >> >Did you configure a linked admin account in LDAP in
> >>security.properties?
> >> >
> >> >- Brett
> >> >
> >> >On 15/02/2011, at 10:10 AM, Qian, Yi wrote:
> >> >
> >> >> Hello, experts
> >> >>
> >> >> I am trying to set up archiva 1.3.3 to authenticate against LDAP
> >> >>server. I
> >> >> followed the instrution of LDAP Integration on Redback website.
> >> >> Uncommented components element of  LDAP connection factory and user
> >> >>mapper
> >> >> in application.xml located in /WEB-INF/classes/META-INF/plexus. Added
> >> >> connection information and attributes mapping in security.properties
> >> >> located in /WEB-INF/classes/org/apache/maven/archiva. I started
> >>archiva,
> >> >> accessing http://localhost:8080/archiva brings me to
> >> >> security/addadmin.action page. Could you tell me what I missed?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Yi
> >> >>
> >> >
> >> >--
> >> >Brett Porter
> >> >brett@apache.org
> >> >http://brettporter.wordpress.com/
> >> >http://au.linkedin.com/in/brettporter
> >> >
> >> >
> >> >
> >> >
> >>
> >>
>
>

--90e6ba6e884c0acd43049c577311--