[Zope3-dev] Re: principals vs. users

[Martijn Faassen]

Guido van Rossum wrote:
> > I've lost the context of Jim's message but I agree that it would be
> > confusing to talk about a set of principals as separate users.  One of
> > the points of talking about a principal is to avoid all the confusion
> > that occurs when you talk about users.
> 
> Really?  Can you give an example of this confusion that wouldn't be
> solved by using "username" instead of "user"?

I think 'username' would become dangerously overloaded. 'account' instead
'principal' might work better, and I think is used in Unix terminology
as well. If indeed it's equivalent, as..

[http connection to Guido versus https connection to Guido]
> Are we calling these two different principals?  Or are they the same
> principal with different strengths of authentication?  I think the
> point is that they are the same principal, but that our level of trust
> differs depending on how they authenticated themselves (and on how
> much we trust the security of the connection).
> 
> > Now you're mixing role and group again :-).
> > 
> > I think groups are an abstraction that helps manage assignment of
> > roles.
> 
> Yes.  Zope2 lets the sysadmin assign roles directly to users in the
> user management form, which suggests that (originally) the Zope2
> designers thought of roles as subsuming the functionality of groups.
> But I think we've learned that it's better to have both.

Definitely; using Zope2 roles as groups basically sucks. They're quite
separate in my mind now that I discovered I really need groups. :)
The fundamental difference is indeed that groups are global while roles
can be local to objects. A group can have roles, just like any other um,
account, principal (username?).

[snip]
> >   >> o Risks of client-side trojan attacks will be partly mitigated.
> > 
> >   GvR> How?
> > 
> > If you log in using your "sys admin" role, you may not have permission
> > to edit documents that requires your "editor" role.  And vice versa.
> > It limits your vulnerability to a single role's permissions rather
> > than all of them.
> 
> Hm, but if log in with an editor role, I still have view permissions
> on other pages that might contain a client-side trojan.  I don't see
> how it solves the problem, although it may reduce it somewhat.

I don't see this 'user is required to switch roles' thing at all yet --
would this mean that if I go from viewing pages to actually editing them I
need to switch roles from 'viewer' to 'author'? Or logically you'd assume
the author role has 'view' permission as well, but if this is the case then
one also wonders if the trojan issue is really resolved by requiring this..

Plus, it is rather nice now that you can detect a user has a certain role and
display more options accordingly. Would this go away? Would the user
have to reauthenticate to switch roles? If not, what's more secure about it?

Regards,

Martijn