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. >What are people using at the moment to do their authentification? An aside: can we not call it authentication? I think you're the first person I've ever seen to use "authentification". >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 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. >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. >* 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. >* 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. >* 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. >* Are we going to worry about multi-machine failover support? Well, I think we should worry about that *in general* for Webware first. ;-) 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. Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
