Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: pass (athena.apache.org: domain of oching@exist.com designates
 74.125.46.28 as permitted sender)
Message-ID: <1a57a2980805132259p67364a2eyab4099c0690a6df3@mail.gmail.com>
Date: Wed, 14 May 2008 13:59:50 +0800
From: "Maria Odea Ching" <oching@apache.org>
Sender: oching@exist.com
To: dev@archiva.apache.org
Subject: Re: Authentication in Virtual Repositories
In-Reply-To: <5E5D4CAD-ADE5-4A09-A478-ED62B8878539@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2313_6670170.1210744790374"
References: <1a57a2980805130237v5c2f592cge584aed52a11838a@mail.gmail.com>
	 <1210733552.19788.32.camel@heck>
	 <0B975658-3FEC-49B7-AB8E-65F7A3305120@apache.org>
	 <5E5D4CAD-ADE5-4A09-A478-ED62B8878539@apache.org>

------=_Part_2313_6670170.1210744790374
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_2313_6670170.1210744790374--