Re: [FEATURE]: extend authz algorithm with roles and wildcards to define branch policies.

[David Anderson <da...@calixo.net>]

On Wednesday 28 December 2005 00:31, Lieven Govaerts wrote:
> as a result of the thread on the users list, and a discussion I had tonight
> on #svn-dev, I want to propose implementation of two new features.

Now that 1.3.0 is (finally!) out, I'd like to get back to this.

> Allow to assign read/write access in the authz algorithm for roles instead
> of groups, and on branch types instead of specific branches.
> Two changes ( extensions ) in the authz algorithm are needed:
> - add the concept of a role, and allow access rights to be given to a role
> instead of a group

I'm in favour of this, as I find it adds an interesting bonus capability to 
our authz system, while at the same time remaining perfectly backcompatible 
with existing stuff.

> - allow wildcard matching to match branch types instead of actual branches

This is a little more tricky.  On the concept I'm +1, because it adds the 
flexibility required to make roles work properly.  On the implementation I 
have a problem, because it makes all authz lookups have to crawl whole files 
to locate a glob matching section.

The pain will be eased though, by two things:
 - Having wildcards will (I reckon) massively decrease the size of the authz 
file in some common use cases, so the cost of crawling the file goes down to 
a bearable level.
 - The authz file gets crawled once when it is opened.  We could add tests 
that set a flag if glob patterns are found during this crawling, and only do 
glob-crawling if it is set.  That would restrict the performance impact to 
the users actually using the feature, which is fine by me.

So, all in all, I'm tentatively +1, because the performance impact will only 
happen to people using the feature, and should be fairly small.

Also, note that both features are completely independant: Role-based access 
control uses the repository name to check for role access, and wildcards only 
apply to paths inside repositories.  Both are required to completely solve 
Lieven's use case, but they aren't interdependent.

So, can we have other opinions on these two proposed features?
I've already told Lieven that I'm ready to implement these once their design 
has been reviewed and approved.  But as we've basically been both designing 
and thinking about this, we need untainted minds to look at the problem and 
tell us what's wrong with it.

- Dave.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [FEATURE]: extend authz algorithm with roles and wildcards to define branch policies.

[Brian Behlendorf <br...@collab.net>]

On Fri, 6 Jan 2006, Lieven Govaerts wrote:
> Maybe your remarks were outside the initial scope we intended for this
> discussion, let me clarify that first.

Yep, no doubt; and not worth holding up this proposal if others like it. 
My experience has been that this direction heads down a path of other 
desired features, where each step feels natural and easy, but after a 
dozen iterations ends up with something powerful but complicated.

> Do you think both paths can/should be followed in parallel? I'm willing to
> further discuss functionality of the LDAP authorization part. Maybe you can
> explain or give pointers to documents explaining how the CollabNet solution
> works?

It's not in a nicely documented form, really; the basic premise is that 
we've got three dimensions: users, projects (which each get a separate SVN 
repos, separate bug database, and other separate databases for other 
tools), and permissions.  Permissions are just functions that the tool 
tells the auth system it will watch for - "checkout", "commit", "tag", 
apply to SVN, for example, but not to bug tracking.  I can create groups 
along any of those three dimensions - user groups, project groups, and 
permission groups which are more simply known as "roles".  Then you grant 
a particular user or group of users a role on a single project or 
collection of projects.  "Domain" owners can create domain-wide roles and 
grant them across any project.  Project owners have the ability to create 
project-specific roles and grant those (or the domain-wide defined roles) 
roles for their own projects.  There's also inheritance, where one project 
is a subproject of another.  We don't yet have one role being a derivative 
of another or things like that.  Some permissions can be scoped based on a 
regular expression that applies to a path - for example, you could give 
"interns" the rights to commit to "/branches/experimental" across a group 
of projects, or even "documentation writers" the rights to commit to 
"*.html|*.doc|*.pdf".

Sounds like overkill, but it became clearly necessary once you started to 
talk about organizations with more than a couple dozen developers and more 
than one or two projects underway simultaneously.  We slid down a looong 
slope.  :)

We've hesitated to open this up partly on the assumption that eventually a 
standard would emerge for doing this kind of thing in a cross-tool way, 
something we could move to rather than push this as a proprietary thing. 
That hasn't yet happened and I wonder if, as David noted, it's because 
people always solve it specific to their application (I see some content 
management systems have it, for example) and not in a generic way the way 
LDAP works.

Part of it might be the heavy UI implied by all that flexibility and 
management... so any common system would necessarily imply applications to 
manage that data, and thus you get something PHP-specific, or 
Java-specific, or whatever.

Ours is implemented in Java and would require people to run a JavaVM in 
parallel with SVN; and its UI is rendered as servlets, etc etc. 
Streamlining our own system down to a separable module would be yet 
another hurdle before we could open it up.  But if there's the chance that 
others would use and contribute to it...

Thanks for the feedback,

 	Brian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [FEATURE]: extend authz algorithm with roles and wildcards to define branch policies.

[David Anderson <da...@calixo.net>]

On Friday 06 January 2006 03:22, Brian Behlendorf wrote:
> Are there any other standards out there for implementing role-based
> authorization in a tool that is not tool-specific?  In the same way that
> Unix user permissions are not tool-specific; perhaps a closer example is
> that it's nice that we have LDAP for doing user and group authn.

Well, honestly, I have no idea. Lieven proposed this solution based on some of 
his experiences on role-based access control in other systems (if I 
understood correctly), so I assumed that in his experience, there was nothing 
that could simply be dropped in and provide the magical solution.

After a quick google, I found 
http://www.uazone.org/demch/analytic/aaa-pmi-overview.html . According to it, 
there have apparently been several attempts at making a "single role-based 
authorization layer", but a lot of them seem geared to a specific software 
context, not as tool-agnostic as what SASL allows for client/server authn. 
Due to my inexperience with many of the technologies that document 
references, I don't really know what to make of it.  Someone?

> Perhaps there are role-based authz extensions to LDAP?  While something
> SVN-specific would be simple, for most users it would mean yet another
> place they need to worry about managing permissions and accounts in
> addition to wherever they do the same for other systems they use.

This is another project I've been kicking around somewhat.  A lot of people 
seem to be wanting tighter integration of authz and LDAP, most notably for 
the handling of authz groups. Now that authz code is within libsvn_repos, it 
is awkward to directly support LDAP there.  What I was considering was 
offering a callback interface to the caller (ie. currently svnserve or 
mod_authz_svn), to let him hook in his own behaviour for things like 
is_user_in_group.  That way, apache modules could hook into a lot of 
facilities Apache already provides, and the door is open to extend the 
possibilities for svnserve as well, if/when we add extended auth backend 
support. And no extra dependencies added to core svn libraries.

No direct relation to the feature proposal at hand, I'm just reacting to the 
"people want more out of authz management" with the thought that this feature 
should not directly be a full, complete solution to that problem.  However, I 
agree that if we can agree on a design that maps nicely onto commonly used 
role-based access control setups, that would be preferable.  This feature is 
imo on the path to wider external hooking of authz, but I'd like to get 
Lieven's two proposals implemented standalone before we start talking LDAP 
and the like.

But unless someone can come up with the Fabled Unified Role System that 
everyone's been doing behind everyone's backs, then by all means, let's use 
that.  Otherwise, I think the current proposal is as classic as it gets on 
the design level (users, groups and roles, with rules definable for any 
combination of the three), and that is serve's Subversion's purposes well 
enough.

> CollabNet didn't see one 5 years ago and had to build an in-house one that
> I'd love to open source but it's not as easy (yet) as just doing it.
> Besides, I'd rather not release something like that if there's something
> better already being worked on that is likely to set some sort of standard
> in the same way LDAP did for authn.  Someone mentioned WS-Security as
> solving the problem some day, but that feels like overkill...

Well, if CollabNet can release something we could base on to implement this 
extension, that would be nice of course (even better if it is released as a 
separate project and takes over the world :-) ).

- Dave.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [FEATURE]: extend authz algorithm with roles and wildcards to define branch policies.

[Brian Behlendorf <br...@collab.net>]

On Wed, 4 Jan 2006, David Anderson wrote:
> So, can we have other opinions on these two proposed features?

Are there any other standards out there for implementing role-based 
authorization in a tool that is not tool-specific?  In the same way that 
Unix user permissions are not tool-specific; perhaps a closer example is 
that it's nice that we have LDAP for doing user and group authn. 
Perhaps there are role-based authz extensions to LDAP?  While something 
SVN-specific would be simple, for most users it would mean yet another 
place they need to worry about managing permissions and accounts in 
addition to wherever they do the same for other systems they use.

CollabNet didn't see one 5 years ago and had to build an in-house one that 
I'd love to open source but it's not as easy (yet) as just doing it. 
Besides, I'd rather not release something like that if there's something 
better already being worked on that is likely to set some sort of standard 
in the same way LDAP did for authn.  Someone mentioned WS-Security as 
solving the problem some day, but that feels like overkill...

 	Brian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org