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. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ website-discuss mailing list [email protected]
