On Thursday 22 November 2001 03:35, paul@... wrote:
> Tavis Rudd <tavis@...> wrote:
> >Remember, this discussion is about a UserManagement system that
> > can be used for the various application ideas on the AppIdeas
> > wiki page. Most of those would fall into the 'large, complex'
> > category. We would really need to discuss the permissions system
> > in the context of each of those applications. But as none of
> > them exist let's focus on authentification for now.
> Yes, this is what I think we should be concentrating on - it
> doesn't matter how "rights" are managed until we know how people
> should be identified and recognised. Indeed, as I mention on the
> Wiki, there are classes of applications for which the users,
> groups, roles model is inappropriate. What we should do is define a
> framework for authentication and allow people to build "rights
> management" (to use a contentious term) on top.
Agreed. ... I quite like that term.
> >What are people using at the moment to do their authentication?
> An aside: can we not call it authentication? I think you're the
> first person I've ever seen to use "authentification".
Hmmm, I should use a spell checker more often!
> In more concrete terms, if a session identifier is used to
> associate a distinct but transient (temporary) identity, then a
> user is a persistent (permanent) identity which can be associated
> with one or many sessions at any given point in time.
> Through authentication, sessions become associated with users and,
> as a result, it should be possible to ask about the user who "owns"
> a session, although it is possible that no user owns a particular
> session because the session is only around to encapsulate the
> activities of a "client" (or "agent", "actor" or whatever we can
> call something which uses an application or service without
> actually being a registered user).
I guess we need to define this term as well. How about 'client' and
> >* I assume we are going to use sessions to store the
> > authentification info.
> As can be guessed from what I've just written, it makes sense to
> "extend" sessions to allow a user identity to be associated with
> them. But no more than that should be involved; certainly not what
> rights someone has.
Totally agreed. Someone's 'rights' should not be stored using
sessions. Although that's really up to the implementor of a
particular 'rights management' system.
> >Here's a summary of the important questions:
> >* At what stage in the request-response cycle does
> > authentification take place (Adapter, Application, or Servlet)?
> >Doing it at the Adapter level means we can use the same mechanism
> > to protect content that isn't served via WebKit. Doing it at the
> > Application level means that we can also protect static content
> > that is served via WebKit. Doing it at the Servlet level means
> > that we can only protect servlets.
> This is a good question, and it's great to see someone else
> wondering about this as well. ;-) I think it's important that if
> the Adapter, Web server or Application performs authentication,
> then the WebKit components should obviously be aware of the
> identities of users of the system, even though no WebKit component
> will necessarily be managing any part of the authentication
> process; this would permit any "rights" or "roles" systems to be
> implemented at other levels in an application architecture.
> >* Assuming that we use sessions to store the authentification
> >details, how do we make sessions work with/without cookies?
> > Extend this to protecting static content via WebKit.
> This question is really only an issue for the work on extending the
> existing session mechanisms and using modified paths or hidden form
> fields. Authentication shouldn't necessarily have a huge impact on
> this work.
Authentication clearly defines what is needed in this area so I think
it will have a 'huge impact'. For example, hidden form fields and
content. The only options I can see are:
* an IP or MAC address based system
* query strings
* modified paths (ala Clarks path-based sessions)
The last two would only work if this is happening through WebKit,
rather than at the adapter/webserver level.
Last time I checked there weren't any good apache modules for doing
non-HTTP authentication. Has this changed recently?
Here's some useful links I just found:
> >* How do we store authentification information in the user
> > session?
> >* How do we guard against session hijacking?
> I'm not really qualified to discuss these issues in depth, although
> the paper that someone referred to recently (I think it was Ian
> Bicking) is interesting for those interested in this area.
Anyone have a link to this?
> >* How are password's stored internally? plain or hashed?
> They should absolutely *not* be stored as plain (clear?) text. For
> those implementing Web services, I find it unacceptable that users'
> passwords would be stored in such a way. Whether or not users
> should invent a new password for each service they use, I suppose
> that many people do use passwords which are identical from service
> to service; by not protecting passwords, service or application
> providers could potentially leave their users open to damage which
> would not be limited to within their own services or applications.
> In short, it shows a disrespect for their users' sensitive
Glad we agree on that ;) Now, how are they hashed? md5, crypt, or
> >* How do we interface with arbitrary stores of user information
> > and passwords (flat-file, BSD-DB, ZODB, relational database,
> > LDAP, etc.)
> Provided a convenient plug-in architecture exists, this should
> satisfy most users. It would be nice to provide "out of the box"
> solutions for this and other parts of Webware, though.
> >* When Webware makes the shift to a multi-application framework,
> > does authentfication span applications?
> >* How do we make the authentification system fall-back to a
> > isn't available.
> I think we should keep the door open to as many authentication
> technologies as possible. The fact that WebKit only supports
> cookies as a session identifier "transport" is potentially a
> worrying enough factor demonstrating weaknesses in terms of
> >* Do we want to enable some sort of IP filtering or automatic
> >IP-userID mapping?
> >* Are we going to block brute-force dictionary attacks with a
> > failed login time-out mechanism?
> These things should be configurable by the developer.
We'd need to implement the hooks if we wanted to support them.
> >* Are we going to worry about multi-machine failover support?
> Well, I think we should worry about that *in general* for Webware
> first. ;-)
This is tied to session management and management of the user
database. mod_webkit (or was it just Terrel's modification of it)
already has round-robin support for multiple AppServers. If the
sessions and user database can be shared between machines then it
seems we've got fail-over support. Sessions can be shared via NFS
and the FileSessionStore or we can create a ZODBSessionStore /
> What I would like to emphasise is that authentication is something
> that has been done before many times and, more importantly,
> authentication frameworks have also been well-covered in the past.
> For example, the whole PAM system is supposedly oriented around
> letting people decide which mechanisms are best in their own cases.
> Therefore, it's important to design something which leaves the door
> open for flexibility, although "ready to roll" solutions would
> obviously be nice for the novice Webware developer.
True. Flexibility and 'ready to roll' should go together if we get
the design right.