archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maria Odea Ching" <och...@apache.org>
Subject Re: Authentication in Virtual Repositories
Date Wed, 14 May 2008 03:22:06 GMT
On Wed, May 14, 2008 at 10:52 AM, James William Dumay <james@atlassian.com>
wrote:

> Deng,
>
> On Tue, 2008-05-13 at 17:37 +0800, Maria Odea Ching wrote:
> > Hi,
> >
> > I've applied the patches for the virtual repositories (MRM-694), and
> we're
> > still missing authentication. I was looking at
> > how we'll implement the authentication & authorization checks for this
> > feature, and stumbled upon a couple of things.
> > The setup of our authentication for a resource request (request to a
> > specific repo, not group) is as follows:
> >
> > 1. A client makes a repo request to the RepositoryServlet.
> > 2. RepositoryServlet calls ArchivaDavSessionProvider for authentication
> &
> > authorization checks.
> > 3. ArchivaDavSessionProvider returns true if request is allowed and
> false if
> > not to RepositoryServlet,
> > 4. RepositoryServlet then calls ArchivaDavResourceFactory to get the
> > resource.
> > 5. ArchivaDavResourceFactory looks for the resource in the repo and
> returns
> > it if found.
>
> That looks right :)
>
> > Now, given the implementation of the virtual repositories (or repository
> > grouping), the implementation of the authentication
> > for the requests needs to be changed. Brett and I discussed two options
> for
> > this in IRC:
> >
> > 1. Remove the ArchivaDavSessionProvider and have the authentication &
> > authorization checks inside ArchivaDavResourceFactory. But
> >     we're not sure if the session provider is required or is being used
> > elsewhere.
>
> I'm hesitant to rip this out of Archiva. The session provider is an
> integral part of the Jackrabbit WebDAV servlet which allows you to
> attach DavSession objects to the request. (These are used for level 2
> locking, among other things).
>
> >
> > 2. Add a dependency to ArchivaConfiguration in ArchivaDavSessionProvider
> in
> > order to get the repositories if the request was
> >    for a repo group. Iterate through each of the repositories and do
> > authentication & authorization checks. The problem here though is
> >    that if the user has permission for the first repo and the resource
> > requested was actually in the second repo.. then the user
> >    would still be able to get in. Another thing that we're hesitant to
> do is
> > having the ArchivaConfiguration in the ArchivaDavSessionProvider.
> >    It doesn't seem to belong there.
> >
> > Option #1 is better, but I'm not certain if the
> ArchivaDavSessionProvider is
> > being used elsewhere or what the impact would be if it is removed. (I
> think
> > James can answer this :-)
> >
> > Thoughts? :-)
> >
>
> As discussed on IRC, we could probably forward the request to the
> appropriate managed repository.
>
> That would work a little like this:
> 1) Request on a virtual artifact is made
> - /repository/myvirtual/artifact/artifact/1.0/artifact-1.0.pom
>
> 2) The resource factory looks this artifact up in the repositories
> mapped by the virtual.
>
> 3) If it has been found, we forward it to the appropriate dav repository
> (/repository/mymanaged/´╗┐artifact/artifact/1.0/artifact-1.0.pom)
>
> The advantage is that we use the existing repository security for
> fetching artifacts from the virtual repository.
>
> Does this look ok?
>

I guess this is a cleaner implementation :-) So the changes now will be
concentrated
in the RepositoryServlet?


>
> Cheers,
> James
>

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