Authentication in Virtual Repositories

[Deng Ching-2]

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.

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.

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? :-)


Thanks,
Deng

[James William Dumay]

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

[Deng Ching-2]

On Wed, May 14, 2008 at 10:52 AM, James William Dumay <james@...>
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

[brettporter]

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

Cheers,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[brettporter]

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
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)

Thoughts?

- Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[Deng Ching-2]

On Wed, May 14, 2008 at 12:55 PM, Brett Porter <brett@...> 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

[brettporter]

On 14/05/2008, at 3:59 PM, Maria Odea Ching wrote:

>>
>> 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?

Sorry, I got ahead of myself. It should be unauthorized... the  
"pretend it's not there" is the behaviour for looping that we have now  
where it should just continue to the next (and return unauth at the  
end).

>> - 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?

It's the webdav browse (not the archiva browse), and also the webdav  
collection request (for getting file listings in a share).

Cheers,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/