archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Atkinson <>
Subject Re: authentication against LDAP
Date Tue, 15 Feb 2011 17:07:07 GMT
Comments are in-line.

On Tue, Feb 15, 2011 at 11:03 AM, Qian, Yi <> 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
> 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" <> 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
> >
> >- 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
> >> 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
> >
> >
> >
> >
> >
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message