On Thursday 22 November 2001 03:35, [EMAIL PROTECTED] wrote: > Tavis Rudd <[EMAIL PROTECTED]> 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! > >Notes: > >* for authentification we only need to think in terms of users > > 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 'authenticated client'? > >* 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 javascript are totally out of the question for protecting static content. The only options I can see are: * cookies * 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: http://sec.ure.org/apache_auth.shtml http://www.ime.usp.br/~nelio/apache/ http://www.frogdot.org > >* 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 > information. Glad we agree on that ;) Now, how are they hashed? md5, crypt, or something else? > >* 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 > >semi-secure mechanism (e.g. md5 hashes via javascript) when SSL > > 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 > accessibility. > > >* 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 / DBSessionStore. > 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. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
