archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James William Dumay <ja...@atlassian.com>
Subject Re: Authentication in Virtual Repositories
Date Wed, 14 May 2008 02:52:32 GMT
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?

Cheers,
James




Mime
View raw message