[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: David Anderson <david.anderson_at_calixo.net>
Date: 2006-01-06 12:59:07 CET

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
Received on Fri Jan 6 12:59:49 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.