Design and implement a flexible framework for handling user authentication and authorization in Webware applications.
TavisRudd
TavisRudd
RayLeyva
DarrylVanDorp
for the moment.
23 Nov 2001 -- formal Webware SubProject created
20 Nov 2001 -- discussion starts on WebwareDiscuss and WebwareUserManager topic created
Oct 2001 -- listed as an idea on the AppIdeas page
A flexible and seamless framework for handling authentication and authorization is essential for all the ideas listed on the AppIdeas page. It will also benefit users creating their own applications and serve as the foundation for the WebwareUserManager application.
... see the design notes and discussion below.
performance overhead
overdesign
Webware 0.7 (??)
It should provide the following layers:
authentication:
secure authentication mechanism; preferably works with or without cookies, and will fall back to semi-secure mechanisms when SSL and/or Javascript is not available.
can reject non-secure authentication for all users, or only a class of users (e.g., people with admin privileges)
keeps track of failed attempts to prevent dictionary attacks -- also uses TarPit to hinder such attacks (as well as DoS?)
flexible time-outs
allows IP-based restrictions / filtering (for example root might only be allowed to login from localhost)
auto-forwarding (a non-authenticated user tries to access something restricted, is sent to the login page, and then back to whatever they were trying to access)
works with both dynamic and static content
authorization (aka permissions, access-control)
concept of both users and groups (completely separate from the OS! -- plus hooks to tie it with OS if wanted)
ability for one user to belong to multiple groups
ability for a group to belong to other groups
flexible, action based, permissions ... eg. members of group X are allowed to view resource Y, but not edit/delete/etc. it. In the context of web publishing, actions can include the following: view, edit, delete, rollback, publish, hide, etc.
an 'anonymous' or 'public' user for non-authentificated users
a catch-all group that includes all defined users (like 'everybody' on NT)
a root user and root group
multiple users and groups can have permissions to a particular resource, unlike Unix permissions.
concept of 'ownership' is distinct from that of 'permissions'.
management interfaces (as part of the WebwareUserManager application):
a user-info interface that allows individual users to do change passwds, personal data, etc.
a 'registration' interface that lets the user choose a username and requires an e-mail address and password
a mechanism to help those who have lost their password. Specific password-recovery mechanisms are discussed below.
web-based and command-line management interfaces that allows the 'root' user or other authorized users and groups to quickly drill-down on users/groups and add/update/suspend/delete those users/groups.
Users must re-enter their passwords before being able to change it or their email address.
In general, the system should:
have support for multiple data stores(flat file, BDB, various relational databases, etc.)
have the ability to tie into existing databases without needing to migrate data (i.e. soft-code the names of the fields used)
support passwords stored in multiple forms -- plaintext, crypt (as traditional in Unix /etc/passwd), md5, SHA1, or homogenous (as in .htpasswd for Apache)
have a clean separation between the backend and the user-interface that permits quick customization of the UI.
have interfaces that are seperate from Webware itself, as components of this may need to be implemented seperately from any Web environment (for instance, in a Tk interface, over XmlRPC by a non-Python application, etc).
The key concepts are:
user
group -- comprised of 'users' and/or other 'groups'
resource - an abstract concept of something in Webware (e.g. a page, a servlet, a wiki topic, etc.) that a user might use.
action (e.g. view, edit, delete, publish, hide, rollback, etc.)
permission -- is a 'user', or one of the 'groups' they belong to, allowed to perform an 'action' on a 'resource'.
authentication -- the process of logging in
authorization -- the process of checking to see if a 'user' has 'permission' to perform an 'action' on a 'resource'.
ownership -- who is allowed to change the permissions of particular resource.
Important questions about the Authentication layer*: (please answer them in the discussion below)
At what stage in the request-response cycle does authentication 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.
Are we going to use an identifier in the session or a separate authentication cookie as is suggested in the two papers listed below?
Assuming that we use sessions to store the authentication details, how do we make sessions work with/without cookies? Extend this to protecting static content via WebKit.
How do we store authentication information in the user session?
How do we guard against session hijacking?
How are password's stored internally? plain or hashed?
How do we interface with arbitrary stores of user information and passwords (flat-file, BSD-DB, ZODB, relational database, LDAP, etc.)
When Webware makes the shift to a multi-application framework, does authentfication span applications?
How do we make the authentication system fall-back to a semi-secure mechanism (e.g. md5 hashes via javascript) when SSL isn't available.
How are we going to implement IP filtering or automatic IP-userID mapping?
How are we going to block brute-force dictionary attacks?
http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf -- a must read!
http://www.skyhunter.com/marcs/ewalnut.html#SEC41 -- E, a capabilities language: relates to capabilities as a permission system (something to implement in Python? Not according to E -- but maybe in a casual manner)
http://www.eros-os.org/essays/00Essays.html -- EROS: The Extremely Reliable Operating System, also uses capabilities. What *is* a Capability, Anyway? and Comparing ACLs and Capabilities address the ACL vs. Capability question, with a decidedly mathemathical bend. Makes the argument that the two are not orthogonal (i.e., basically the same).
I think permissions should be considered something of a different issue -- ACLs being traditional at this point, but not always appropriate. They are closely tied to the system's notion of a an object and the granularity of permissions.
I myself have been thinking about a more OO way of doing permissions -- most of the ways seem to be based on static data structures with explicit algorithms: it's not possible, for instance, to say "anyone can do action X if someone with permission Y requested that they do it" -- you can make the request also grant the permission, but the algorithm itself is external to the security system. You can't, for instance, retroactively change those permissions around, because the actions (the request) have already passed.
Anyway, I'm not sure where I'm going with that idea, but it might only be to say that figuring out permissions is distinct from managing users and their roles/groups, and probably more complicated.
-- IanBicking - 20 Nov 2001
Zope has a robust but (for some applications) overly complex security system: http://www.zope.org/Documentation/ZDG/Security.stx .
We're leaving out the Zope term "role" because it ambiguously overlaps with our term "group". We're also leaving out Zope's "Proxy Roles" (analagous to Set-UID programs, or allowing a user to acquire extra permissions in certain circumstances.)
Our "ownership" is different than Zope's. What Zope calls ownership was added to Zope in 2000 to plug a security hole related to through-the-web editing and proxy roles. For us, 'owner' means the user(s) who may reassign the permissions of a particular resource.
As far as user interface, Zope uses one screen with a table of permisions down the left and roles along the top, another screen for linking groups to roles, and the user screen for assigning users to groups.
-- MikeOrr - 22 Nov 2001
Let's scrap the term 'role' completely, and only use the terms of users, groups, actions and permissions. Where 'actions' are things like view, edit, etc. and permissions are the authorization for particular users and groups to be able to perform those actions on an object. An application designer should be able to define custom actions. 'roles' implies a strict connection between 'groups' and particular 'actions', which is not desirable. The permissions system in Windows NT and Novell Netware are good models.
-- TavisRudd - 20 Nov 2001
I don't know what Novell uses -- it seemed very fine-grained -- but I don't particularly like NT. The way permissions combined seemed very strange -- for instance, if you have Everyone: Deny All, then other more permissive permissions would be meaningless. This seems backwards, and overall very confusing. If you want to look at a particular ACL implementation -- ACLs are hardly novel, after all -- I think it should be possible to find something better than NT.
-- IanBicking - 20 Nov 2001
Novell uses a modified version of LDAP to power it's NDS authentication system. Couldn't we utilize OpenLDAP as a basis?
-- RayLeyva - 20 Nov 2001
With all this talk of users, groups, roles and so on, it's important not to forget applications where the concept of a user might be interesting, but where the relationships between users and actions are completely different (they could be determined by their position in an organisation, for example) and are irrelevant to the ownership of Webware resources (being relevant instead to the data manipulated by such resources).
I have been thinking a bit about authentication and access in some recent experiments and I think it would be nice if one could have a layer where access checks are implemented separately from normal servlet code. In XmlForms I would consider adding an access section to each definition which can validate a user's credentials according to an arbitrary validation function, and should the validation fail, the user would be directed to another resource either to get authenticated or to be told what went wrong.
These validation functions might well use a lot of application-specific logic, but they could benefit from simple, generic user support in Webware. One of the things about Zope which seemed either badly explained or badly designed was the tight binding between users and what Zope wanted users for. Clearly, Zope supports user sessions for itself, but then people mention that it doesn't support user sessions for Zope-based applications without add-on products being present to provide such sessions.
-- PaulBoddie - 21 Nov 2001
Here are examples of group structures appropriate to different applications:
(A) Unprivileged user, logged-in user, content manager. The last may be factored out if the app doesn't allow through-the-web managing. The first may be factored out if user identification isn't necessary for these actions: simply put an if-anonymous-user branch in each servlet. If you're left with only one group (logged-in user), maybe you won't use most of this kit/package.
(B) Unprivileged user (may read some content and post to forums), privileged user (may read all content and post to forums), content manager (may add/edit articles; e.g., "pages"), app manager (may change the app's look or do more programmingish stuff). All this is separate from the anonymous user, which has his own default permissions.
Only some sites will have a web management interface. Even fewer will allow non-managers to modify editorial content ("articles", as opposed to forum postings or user-submitted entries) through the web. WebwareUserManager should scale down to these sites and not require unnecessary complexity. Complexity should be added only at the point it's needed.
-- MikeOrr - 22 Nov 2001
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 authentication for now.
What are people using at the moment to do their authentication?
Note:
for authentication we only need to think in terms of users
Here's a summary of the important questions:
At what stage in the request-response cycle does authentication 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.
are we going to use an identifier in the session or a separate authentication cookie as is suggested in the two papers I listed below?
Assuming that we use sessions to store the authentication details, how do we make sessions work with/without cookies? Extend this to protecting static content via WebKit.
How do we store authentication information in the user session?
How do we guard against session hijacking?
How are password's stored internally? plain or hashed?
How do we interface with arbitrary stores of user information and passwords (flat-file, BSD-DB, ZODB, relational database, LDAP, etc.)
When Webware makes the shift to a multi-application framework, does authentfication span applications?
How do we make the authentication system fall-back to a semi-secure mechanism (e.g. md5 hashes via javascript) when SSL isn't available.
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?
Are we going to worry about multi-machine failover support?
-- TavisRudd - 21 Nov 2001
Here's some excellent overviews of the issues involved and the schemes available: * http://www.wwnet.net/~janc/auth.html * http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf
-- TavisRudd - 22 Nov 2001
Tavis said WebwareUserManager (WUM) is meant for complex apps such as those on the AppIdeas page. But it would be better to have a system that scales up to those applications and also down to simpler applications that don't need all its features. Because even the simplest application (with one group) may want some features, such as a registration screen and password-recovery screen. And maybe this simple application will one day become more complex and require some features it didn't previously. Then you can simply activate the features rather than porting the application to WUM.
One of the goals mentioned above was seamless reauthentication. That is, when the user hits an unauthorized page, the system prompts him to login, then retries the original request. Zope does this through an Unauthorized exception, which Zope automatically catches and does the login prompting and retrying.
-- MikeOrr - 23 Nov 2001
PasswordRecovery
Lost-password recovery mechanisms:*
"mail me my password" button (to my registered address).
"mail me a new password" button.
challenge question and answer, preselected during registration. We can offer a single question, a choice of questions, or a user-provided question. To reassure paranoid users, the question should not relate to any info that could be (mis)used to identify the user or place them in a marketing category. "Pet's name" is safe; "favorite sports team" is questionable; "birthdate" and "mother's maiden name" is unacceptable. (Disadvantage: user may not want to come up with and memorize a question/answer.)
mail user a randomized URL, valid only for 30 minutes, where she can choose a new password. (Tavis prefers this, and Mike thinks it may offer a fair compromise between security and convenience.) -- I am absolutely against mailing passwords. -- TavisRudd - 23 Nov 2001
-- MikeOrr - 22 Nov 2001
One of the sites I used also did this:
send a new, generated password by postal mail to the user. Unfortunately, despite attempting to select "send by e-mail", the application decided to use postal mail instead, but I did get a letter a few days later with the password in it. :-) Is this a justification for the establishment of a PostKit component? ;-)
-- PaulBoddie - 23 Nov 2001
Something which I just realised: I have been following this page's progress using the WebChanges page, but the categorisation and naming of what is being discussed seems wrong. As one of the AppIdeas which discusses a WebwareUserManager, it seems to suggest an application which provides easy administration of user details, rather than a framework for the identification and authentication of users. Shouldn't we set up a WishList entry concerning sessions and users, or at least refer to this as "WebwareUserHandling"?
-- PaulBoddie - 23 Nov 2001
Paul, you're right. This core of this is a system component rather than an application. However, I'd like to build an application for managing users on top of the framework.
-- TavisRudd - 23 Nov 2001
I think this is a new *Kit idea -- which isn't an application, but isn't part of WebKit, or even necessarily Webware. There should be a KitIdeas.
-- IanBicking - 25 Nov 2001
Here's a good architectural doc from Sun: http://java.sun.com/security/jaas/doc/pam.html
-- TavisRudd - 14 Jan 2002
Something more appropriate for Webware, at least in terms of how much effort we would want to put into this, is the "realm-based" security that you can get in various Java Servlet containers. For example, one can declare various realms in the configuration of a Servlet container (application server) which states where the user database is, or how the username and password details are validated. Then, and this is the bit we should change a little, one can declare which "roles" are required to access specific Web resources.
Now, I personally don't believe that this Web-resource-based authorisation is the beginning and end of authorisation, since (as I note above) it can be meaningless for various kinds of application, and one may well end up checking roles or user identities in the application itself, so we could just specify an API which lets applications discover the roles associated with a user, or even just the user identity (both are found in the request object in the Java Servlet API). Whether or not we introduce a Web-resource-based access policies is an open question which hasn't really been answered above.
The interesting part of the J2EE standard, though, is the way that one can either use the standard "pop-up dialogue window" or a "form-based" page to prompt for the user details in a Web application, should the user attempt to access a service which requires authentication. With this feature in Servlet containers, it's possible for authentication to occur transparently to the application - the user doesn't come close to a resource that is protected until he/she has the appropriate role(s).
Anyway, perhaps this would be a start.
-- PaulBoddie - 05 Jun 2002