[ogb-discuss] Community Simplification

[Alan Burlison]

John Plocher wrote:

>  From a "security" perspective, the second case is fraught with
> authorization holes.

Umm, that's seems like a bit of a sweeping statement.  The user 
management application doesn't really say anything directly about 
authorisation.  It authenticates users (do we have a registration for 
that username and does the password match) and it also allows 
participating applications to enquire which roles an authenticated user 
has.  It doesn't map those onto rights, that's left to the individual 
applications, which are best suited to interpret the roles in their 
particular context.  It may be the case that there is a direct mapping, 
e.g. for the poll application Members may map directly onto people who 
get a vote, but it would be the responsibility of the poll application 
to know about that association - and that's more or less the way things 
work in the existing system.

> Code review or ARC authority or web editing privs based on the existance of
> attributes intended to be used for community voting/membership status means
> that there is no way to say things like "is an ARC member but is not a
> website editor".

That would clearly be a bad thing, but that's not how the new 
application works.  The model used by the auth application is 
significantly richer than I think you are assuming it is.

In your original document you had a list of roles, some of which were 
fairly general ('CONTRIBUTOR'), some of which were more specific 
('EDITOR').  You didn't explicitly spell out the context in which those 
roles were valid, although if I read the descriptions the contexts are 
in there, for example GATEKEEPER clearly only makes sense in a context 
where there are gates, and EDITOR only makes sense in a context where 
there are web pages to be edited.  That's exactly the way the auth 
schema is structured - roles are tied to collective types, so as in your 
example above it is perfectly possible to have someone who has one role 
in a collective focused on website content and a different role in a 
collective that is focused on code contributions.

> This seems like a hardcoded assumption rather than a configurable policy,
> and feels shortsighted.

That seems perhaps a trifle harsh. As I've already said, I think you are 
making assumptions about the application that aren't valid.

> Rather, since you already intend to have the
> confederation of affiliated sites be controlled and limited, you could
> easily include a mechanism (aka LDAP...) whereby each system defined a
> set of roles that would indeed be added (as a relation?) to your user/auth
> schema.

That's the way the current system is set up, and frankly it is a mess. 
We've ended up with a database where five different applications are all 
wedging their data into a single schema.  As a result it is difficult to 
decide who 'owns' what pieces of data, there is widespread duplication 
and some substantial issues related to data integrity between the 
applications. It also makes it very difficult to migrate applications 
away from the central core, as everything is strongly interlinked.  That 
makes responding to the needs of the community as it evolves a slower 
and more painful process than we'd like.

In the case of the current setup, the structure we have was more-or-less 
forced on us by the constraints imposed by the current portal 
application.  One of the primary reasons for doing the auth application 
was to fix that problem, and that means imposing proper separation of 
concerns.  We don't intend to provide a central repository for 
applications to store all their authorisation data in, because that 
leads to a level of coupling that makes it difficult to achieve our goal 
of producing a flexible, distributed set of cooperating applications to 
run both opensolaris.org as well as other external applications which 
want participate.

 > Thus, the website would add "role=editor", the poll system would add
 > "role=voter", the ARC system would add "role=member, intern", etc...
 > and the affiliated sites could ask you to associate a person with one
 > of their roles (but not with some other site's roles...).

I think that approach perhaps focuses too heavily on implementation 
details and not enough on the roles people are playing in the wider 
opensolaris community.  There are several issues - firstly the word 
'editor' can be used in different contexts to mean different things and 
I'm not clear if you are suggesting that 'editor' should always mean 
'web page editor' or if other applications could use the same word to 
describe a different task.

Secondly it means that each new application which is added requires a 
large amount of work (and duplication of information) to add it to the 
system.  To go back to my earlier example, if we add a code review 
system it would make perfect sense to give anyone who has commit rights 
access to it, as the two tasks of code reviewing and code contribution 
are strongly linked.  Sure, there may be cases where we are adding a new 
facility that's not covered by any of the existing roles, and in that 
case we would add new collectives, roles and associations as necessary. 
  However requiring that each application has it's own largely disjoint 
set of information in the database isn't the best approach, as we've 
already seen from the existing system.

I don't think your suggestions are really all that at odds with what we 
are building.  However I'd like to suggest that we put this discussion 
to one side for the moment, as I suspect it might become a distraction 
from the primary issue which is community structure, not infrastructure 
implementation.  My reason for poking my head above the parapet was just 
to remind people that there has already been work going on in this area, 
and that whatever community structures are decided on need eventually to 
be mapped onto the infrastructure of OSO.  However, I think I've 
achieved that and don't want to divert the conversation any further from 
the much more important issue at hand - the OSO community.

-- 
Alan Burlison
--