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 05:59:50 GMT
On Wed, May 14, 2008 at 12:55 PM, Brett Porter <brett@apache.org> wrote:

>
> On 14/05/2008, at 1:31 PM, Brett Porter wrote:
>
>
> > On 14/05/2008, at 12:52 PM, James William Dumay wrote:
> >
> >
> > > 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?
> > >
> >
> > It looks ok to me. I'm not 100% sure if the step in (3) will work, but
> > if not surely the request can be embedded inside the existing request in
> > some way.
> >
> > These are the additional use cases I think we need tests for:
> > - index writer directory listing when not all repositories have read
> > access should only list available items (same for webdav listing)
> > - should be unable to write to a group / webdav share for a group should
> > be readonly
> >
>
> I took a closer look - and I think the flow can be adjusted.
>
> Here is what I understand the flow to be at present:
>
> 1) attach session
>  1a) check authn
>  1b) check repository permission
> 2) create resource
>  2a) proxy resource if necessary
> 3) check precondition (returns true)
> 4) execute DAV request
>
> The precondition is the bit that is meant to do the authz - but we do it
> earlier to prevent proxying something they might not even have access to.
>
> If we were to have resource level authz, or as we go to add groups, we
> don't know up front the authz rules.
>
> How about:
>
> 1) attach session
>  1a) just add credentials we have to the request, don't require authn or
> authz
> 2) create resource
>  2a) proxy resource if necessary. Require authn if we haven't to this
> point. if the user has permission to both read the repo and proxy the
> resource (when we later add MRM-579). If no permission, pretend it's not
> there


By pretend it's not there meaning send a 'Resource does not exist' error
instead of 'Unauthorized' error?


>
> 3) check precondition
>  3a) check for read (or write) access to the resource. Require authn if we
> haven't to this point.
> 4) execute DAV request
>
> This does mean we are checking the read permission twice, but it should be
> cached. This also lays some ground work for resource based permissions
> later.
>
> Now, as we add the repository groups - this is really a read only-view
> that sits on top of the whole thing:
> - for a non-collection request, this gets added to the resource factory as
> it is now
> - for a collection request, we actually need a whole new DavResource
> derivative that can handle the virtualised nature of it (and check security
> on each resource it attempts to list)


This is for the browse right?


>
>
> Thoughts?


Looks good to me :-)


>
> - Brett
>
>

Thanks,
Deng

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