[Zope] newbie auth advice.

[Jim Penny]

On Thu, Jun 20, 2002 at 03:11:13PM -0400, Nathan Valentine wrote:
> > here is the $64,000 question.  Say you have users from BigCo.  Who will
> > be administering these users.  Are you going to do it?  If so, I would
> > strongly consider exUserFolder.
> > 
> > Does a untrusted administrator at BigCo administer their users?  Or worse,
> > does BigCo make all or part of their content available to LittleCo?
> > Do alliances shift like Afghani politics?  In that case, none of the
> > stock folders will do it for you.
> 
> Several BigCo employees will have free run over the entire site
> including all BigCo client 'portal data'. The client portal data is
> pretty much just push-mode. They(clients) shouldn't really be able to
> make any changes. It's just there for them to look at. Down the road,
> perhaps it would be nice to be able to delegate to a person at each
> BigCo client the authority to create new users within their client
> portal, but that's not currently a major design consideration. Oh, and
> of course a BigCo client can view only their own portal. 

That's your main problem -- the down the road problem.  If it is truly
not a major concern, go with exUserFolder.  More mature, battle tested,
etc.

exUserFolder will let the administrator(s) attach arbitrary data to 
users.  You could certainly attach a company property.  This would seem
sufficient unto your present needs.

The main difference(s) between my user folder (deUserFolder) and exUserFolder are:

  1)  I have tested only a postgres backend, exUserFolder has multiple
  backends.
  2)  deUserFolder has a notion of "affiliation list", which may be
  "unrestricted", or a finite list of names.  An administrator can
  belong to one or more affiliations.  He may then administer users who
  have a subset of his affiliations.  I am not doing content management;
  this is purely to get me out of the overhead of administering _many_
  users, and the potential legal problems of inadvertant disclosure.  
  (Suppose an employee quits and goes to work for a competitor, but is
  able to access his previous employee's data, and this causes harm.
  Who is responsible?)

Really, the primary difference in strategy between deUserFolder and
exUserFolder is the experiment of creating limited user administrators.
Content administration is a different problem, and I have not thought
about that enough to tell you if the deUserFolder approach is even
remotely useful.  I suspect permitting remote content administration
would NOT be covered well by what I have done.

Also, note:  there is yet another approach.  You can use ANY user
folder if BigCo's userfolder is contained within BigCo's portal.
That is, if you have a BigCo folder, and a BigCo userfolder within
it, you know by virtue of his URL that he has been authenticated
against a BigCo userfolder.  Have your actual programs in yet another
folder, and use a portable hole in the BigCo folder pointing to the real
(shared) programs.  If you are worried about fewer than a couple
hundred BigCo's, and bigCo's don't want transitive access; this can 
be quite compelling.

Jim


> 
> My intention is that the client name will determine the database and/or
> tables that the portal data is pulled from and the username and password
> will be used to authorize access to the data in the database/tables. 
>  
> -- 
> ---
> Nathan Valentine - nathan@nathanvalentine.org
> Jabber: NRVesKY AIM: NRVesKY ICQ: 39023424