On Sat, Aug 15, 2009 at 1:10 AM, Derek Cicero<[email protected]> wrote:
In yesterday's website migration conference call, there were a number of
questions stemming from this email thread that many folks felt were left
unresolved, so I wanted to try and clarify some of the questions so we can
make sure they are being addressed by the right group(s). In addition, I
want to make sure that folks are clear on how the current site changes will
impact the relationship between the new user database (Auth) and the
existing third party applications within the os.org domain (CR, XWiki,
Source Juicer, etc).
1) Auth's role in application development
As Alan has mentioned previously, Auth is meant to be the central management
system for all registered OpenSolaris users and is implemented using the
roles as defined in the current Constitution, with additional roles added
to compensate for gaps in the current Constitution. Auth will provide access
to any approved application needing to authenticate users or verify a user's
role/status within the OpenSolaris community. Auth was not developed with
the intention of ever storing application-specific data.
Understood.
So, auth has a list of roles and simply defines whether a user has that role.
So, what is the complete list of roles stored in auth? It has
constitutional roles
and additional roles, but as a starting point it would be useful to know what
the list is.
(And before anybody asks, this isn't clear and obvious from the documentation,
nor has an answer been given on this thread. We're still trying to get
to the bottom
if this.)
2) Access and rights for applications
Applications within the opensolaris.org domain* will use the Auth system
for user verification, as mentioned above. Those applications may
assign privileges related to the applications to the role names provided
via Auth. The Auth system doesn't dictate how applications operate. They
may also choose to implement the basic user authentication provided in
Auth (Active: Y/N) and implement a role-based control model of their
own. We will not dictate how the individual applications choose to
operate, except to say that Auth will not be modified in the future to
store any application-level data.
* And potentially applications outside of the infrastructure as well.
That's fine; all applications need to implement their own extensions.
3) Specific access rights for XWiki
XWiki has chosen to utilize the existing roles as provided in Auth and
map those roles the editing rights in its application. I believe this is
the fundamental issue that some folks are questioning. This has no
direct relationship to the architecture for Auth, but is rather an
integration decision on the XWiki side, one which will need to be made
by any developer that authenticates via Auth, of which XWiki just so
happens to be the first.
While I understand that not everyone agrees with how XWiki is assigning
privileges to role names, I believe it's been shown that the assignments
have been thoughtfully made. For example, if someone is given Core
Contributor status within a Community Group, it seems logical that they
are in a leadership role and therefore should have leadership privileges
across the associated sub-systems on the site. The alternate possibility
of being made a Core Contributor and then having to request, and be
assigned, specific privileges similar to that role, within each
application, would not seem to scale from a management perspective.
Historically, participants have been given core contributor status to give
them the right to vote in community elections. Eliminating that discrepancy
was a prime mover behind the new constitution. Unfortunately that didn't
make it, and we're still in the situation where Core Contributor means they
can vote and any other meaning is accidental.
Besides, at least one community has come back and said that they do not
wish leadership to map to editing rights, even in the new model.
4) Making changes to the roles in Auth
Given that the Community Group role names in Auth are those defined in
the existing Constitution, any changes to the Constitution will result
in changes to Auth. However, that will not change the role of Auth as
the central provider of roles/status or the basic architecture of Auth,
which precludes storing application-specific data.
While I realize this may not address all the questions and concerns
raised in the earlier thread, or on yesterday's call, I want to separate the
various issues so we can focus discussion in the right areas and move it
forward.
Thanks Derek.
Let me reiterate the problem:
The constitution defines two roles - Contributor and Core Contributor - and
assigns specific attributes to those roles. Auth also defines two roles, for
Community Groups, namely Contributor and Core Contributor, and assigns
specific attributes to those roles. The question is the relationship between
Question 1: are the constitutional roles stored in auth?
I believe that the constitutional role of Core Contributor is there, under the
electorate collective associated with each CG.
I am not sure about the constitutional role of Contributor. The FAQ says
the contributor designations are present in the electorate collective data.
Looking at auth, they're currently not shown. The roles and collectives
document says a community's Contributors and Core Contributors are
assigned by the OGB secretary, yet in auth they're managed by the
existing core contributors. The data migration document does not mention
the constitutional role of contributor as being populated, and what it calls
a contributor is obviously not the constitutional role.
Question 2: are the constitutional roles used for access control?
In the case of Core Contributor, I believe not. The constitutional role
is in the electorate collective, which I believe to be separate.
In the case of Contributor, I have no idea. I don't think so, because I can't
see the constitutional role being present at all.
Question 3: what's the connection between the constitutional roles
and the roles of the same names defined in auth for Community Groups?
Let's take an example, from auth. I'm a core contributor for the
sysadmin collective. I'm also listed as a Member of the sysadmin
electorate collective. So the two are separate, right? What's the
connection?
(And I mean the permanent connection - I understand that the transition
to auth has meant that they start out being the same. The question is how
they're connected in the future.)
Question 4: are the community group roles in auth really the constitutional
roles?
This isn't a different question; it's the same question turned around. But
looking at it that way ought to make it clearer.
So, if I, as a Core Contributor for sysadmin, go into auth and make Joe
a Core Contributor for sysadmin, and make Bob a Contributor, what does
that mean? Does that give them the rights as defined by the constitution?
There are two answers to this:
If yes, then we've violated the constitution, because it specifies the process
for how to do this and I haven't followed it. Not only that, but auth allows me
just to go in and remove those rights, which isn't allowed in the constitution.
If no, then we're fine, but it's horribly confusing because we've used the
constitutional terminology in a non-constitutional context.
(I note in passing that the use of "Member" in the electorate collective
is also incorrect use of terminology.)
Question 5: where do we go from here?
I suspect that it's nothing more than a terminology issue. Getting some
answers to the above questions would help confirm that.
In that case, then the simplest way forward would be simply to change
the electorate collective terminology from the current Member to Core
Contributor, and add (or expose) the Contributor data in the electorate
Collectives. And then change Core Contributor and Contributor in
the Community Group collectives to terms that aren't defined in the
constitution.
