User Handling Proj

Project Summary

Design and implement a flexible framework for handling user authentication and authorization in Webware applications.

Project Moderator

TavisRudd?

Project Members

Current Status

Problem

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.

Solution

... see the design notes and discussion below.

Risks

Delivery Target

Webware 0.7 (??)

Design Notes (in DocumentMode)

It should provide the following layers:

Background Reading (in DocumentMode)

General Discussion (in ThreadMode)

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:

Here's a summary of the important questions:

-- 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

-- MikeOrr - 22 Nov 2001

One of the sites I used also did this:

-- 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