You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by Dave McLoughlin <Da...@openlogic.com> on 2009/03/10 22:08:00 UTC

"fine-grained entitlements" within Archiva

We are using Archive to manage a set of repositories and we've hit a
snag.  We allow teams to store "commercial" artifacts into one of the
repositories but we are concerned about possible licensing implications.
If the product equires a separate license key, there is no problem.  But
if the ommercial binaries do not have that ability, then we are
wondering if here is a way to implement "fine-grained entitlements"
within Archiva. We have not seen anything in the user management space
other than "coarse-grained roles".

The only way that we have found to do this would be to create a separate
repository for each group that has a set of commercial binaries that
they need to build against.  We'd rather not take this approach because
(1) it reduces the reuse of maven and really defeats the purpose of
having shared binaries and (2) we are concerned that it will not scale
to 500-2000 repositories.

Any thoughts or advice would be appreciated,

 


Dave McLoughlin 

 


Re: "fine-grained entitlements" within Archiva

Posted by James William Dumay <ja...@atlassian.com>.
Hey Dave,

Dave McLoughlin wrote:
> We are using Archive to manage a set of repositories and we've hit a
> snag.  We allow teams to store "commercial" artifacts into one of the
> repositories but we are concerned about possible licensing implications.
> If the product equires a separate license key, there is no problem.  But
> if the ommercial binaries do not have that ability, then we are
> wondering if here is a way to implement "fine-grained entitlements"
> within Archiva. We have not seen anything in the user management space
> other than "coarse-grained roles".
>    
This is something I need soon as well. Your right - we only have 
coarse-grained access (per repository).
> The only way that we have found to do this would be to create a separate
> repository for each group that has a set of commercial binaries that
> they need to build against.  We'd rather not take this approach because
> (1) it reduces the reuse of maven and really defeats the purpose of
> having shared binaries and (2) we are concerned that it will not scale
> to 500-2000 repositories.
>
> Any thoughts or advice would be appreciated,
>    
We really need to review our security system post 1.2 release. If you 
could document your needs and requirements on our wiki 
(http://cwiki.apache.org/confluence/display/ARCHIVA/Index) it would go a 
long way to help us understand what improvements we need to make in 1.3 
(or a future version).

If you have time, we could really use help in this area :)

Thanks
James

Re: "fine-grained entitlements" within Archiva

Posted by Brett Porter <br...@apache.org>.
Hi Dave,

Sorry, this feature isn't included yet. You can vote/watch MRM-270 if  
you like.

Cheers,
Brett

On 11/03/2009, at 8:08 AM, Dave McLoughlin wrote:

> We are using Archive to manage a set of repositories and we've hit a
> snag.  We allow teams to store "commercial" artifacts into one of the
> repositories but we are concerned about possible licensing  
> implications.
> If the product equires a separate license key, there is no problem.   
> But
> if the ommercial binaries do not have that ability, then we are
> wondering if here is a way to implement "fine-grained entitlements"
> within Archiva. We have not seen anything in the user management space
> other than "coarse-grained roles".
>
> The only way that we have found to do this would be to create a  
> separate
> repository for each group that has a set of commercial binaries that
> they need to build against.  We'd rather not take this approach  
> because
> (1) it reduces the reuse of maven and really defeats the purpose of
> having shared binaries and (2) we are concerned that it will not scale
> to 500-2000 repositories.
>
> Any thoughts or advice would be appreciated,
>
>
>
>
> Dave McLoughlin
>
>
>

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


Re: "fine-grained entitlements" within Archiva

Posted by Wendy Smoak <ws...@gmail.com>.
On Tue, Mar 10, 2009 at 2:08 PM, Dave McLoughlin
<Da...@openlogic.com> wrote:

> The only way that we have found to do this would be to create a separate
> repository for each group that has a set of commercial binaries that
> they need to build against.  We'd rather not take this approach because
> (1) it reduces the reuse of maven and really defeats the purpose of
> having shared binaries and (2) we are concerned that it will not scale
> to 500-2000 repositories.

At what level would you need to control authorization?  Would groupId
work, or would you need it all the way down to the artifact level, or
even down to the version?

I'm not sure what you mean by "it reduces the reuse of maven and
defeats the purpose of having shared binaries" ?  They're still
shared... you're just restricting who can see them.

Here's an idea [untested] ... set up a separate managed repository for
each set of commercial binaries, and grant the repository observer
roles to the appropriate users.

Then create a repository group, and put all of your repositories in
it.  The authorization rules *should* apply to the repos behind the
group, so that everyone retrieves all of their artifacts from
http://repo.mycompany.com/archiva/repository/all, but each user can
only "see" the artifacts he or she should.

You'd need to make sure to keep local repos and credentials separate
if you're using a shared build server.  Once something gets into the
local repo, it will be visible to all builds from then on.

I do share your concerns about scaling this to 2000 repos, I'm not
sure how the virtual repository group would perform with that many
managed repos behind it.

This is a hard problem to solve, it's really the same one others have
written about wrt governance of who is allowed to use which open
source artifacts.  In the environment I work in, artifacts are
approved for use in building certain projects, it's not done at the
user level.  And worse, it's time sensitive since an approval may
expire.

-- 
Wendy