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.
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.
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.
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
Peter Tribble wrote:
On Mon, Aug 3, 2009 at 11:48 PM, Alan Burlison<[email protected]> wrote:
Peter Tribble wrote:
I'm after the data that's currently in poll. I know I can currently
get that from
poll, but my understanding is that's going away as a primary data source,
so where do the Contributor designations end up in auth?
As a normal user you can't see the Electorate information for other people
in Auth yet, just your own. If you want to see other people's information
you still have to use Poll. At the moment updates to Auth are written back
into the existing database thyat Poll uses, and you can then view the data
in Poll. When we migrate Poll to use Auth then Poll will obtain the
information directly from Auth.
So, are Contributor designations (the ones that go back to poll)
stored separately from the Contributor roles listed under Community
Groups. It looks to me like they are, because my own don't match.
(Note that what auth calls Contributors isn't what I'm looking for -
that includes
Leaders - I want the Contributors with the Leaders taken out.)
Not sure what that statement means - Contributor is a role in a Community
Group and Leader is a role in Projects, and Community Groups and Projects
are disjoint.
According to the Data Migration strategy:
3. Community Group Leaders in Tonic who were not identified as Core
Contributors in Step 1 will be CONTRIBUTORS of the relevant Community
Group in Auth.
Which is consistent with what I see. But those aren't Constitutional
Contributors, so I'm hoping that - just like there's a "foo electorate" shown
in auth with Members - you've got the Contributors from poll for that
foo electorate and we just can't see them as a separate item.
--
Derek Cicero
Program Manager
Solaris Kernel Group, Software Division
_______________________________________________
website-discuss mailing list
[email protected]
